รีลีสขนาด 127 คอมมิตจริง ๆ แล้วคืออะไร

มีบล็อกโพสต์นี้อยู่อีกเวอร์ชันหนึ่งที่แค่ไล่ลิสต์ทุกอย่างใน GeekBye v1.7.0 — หน้าจอหลักที่ออกแบบใหม่ ฟลว์การคาลิเบรต แถบข้างที่ยุบได้ การตั้งค่าใหม่ ๆ และอื่น ๆ อีกมากมาย มันจะถูกต้องและมันจะไม่สอนอะไรคุณเลย เพราะเรื่องราวที่ซื่อสัตย์ของ รีลีสขนาด 127 คอมมิต ไม่ใช่ตัวลิสต์ แต่มันคือรูปทรง

นี่คือรูปทรงของมัน หนึ่งร้อยยี่สิบเจ็ดคอมมิตฟังดูเหมือนเรื่องเล็ก ๆ หนึ่งร้อยยี่สิบเจ็ดเรื่อง แต่มันแทบไม่เคยเป็นแบบนั้น v1.7.0 คือ ฟีเจอร์ใหญ่สองอย่าง ที่สร้างคู่ขนานกันบน branch ที่อยู่ยาวราวสิบเอ็ดวัน แล้วถักทอเข้าด้วยกันในตอนท้าย การเข้าใจรีลีสขนาดใหญ่หมายถึงการเข้าใจสองสายนั้น — และจุดเดียวที่เราสร้างบางอย่างไว้ผิดที่จนต้องรื้อกลับออกมากลางคัน

สายที่หนึ่ง: การคาลิเบรต

สายแรกคือ การคาลิเบรต — การประเมินทักษะการสื่อสารของคุณด้วยเสียง AI คุณเริ่มการโทรสดกับ "โค้ชอาชีพ" AI ทำงานผ่านชุดเฟสที่มีโครงสร้าง (วอร์มอัป พฤติกรรม การสื่อสารเชิงเทคนิค การรับมือภายใต้แรงกดดัน การตั้งเป้าหมาย) และในตอนท้ายคุณจะได้คะแนนใน 6 มิติ: ความมั่นใจ ความชัดเจน ความเฉพาะเจาะจง การมีส่วนร่วม ความสงบนิ่ง และความตรงประเด็น เบื้องหลังนั้นมันยังวัดเมตริกการพูดที่จับต้องได้ด้วย — จังหวะการพูดของคุณ ความถี่ของคำเสริม ว่าการหยุดของคุณอ่านออกมาเป็นการวางแผนหรือความลังเล

ผลลัพธ์ไม่ใช่เกรด แต่มันคือจุดเริ่มต้น การคาลิเบรตให้จุดแข็งของคุณ พื้นที่ที่คุณควรพัฒนา และ — ที่สำคัญที่สุด — ระดับความยากที่แนะนำให้เริ่มฝึก มันคาลิเบรตว่าตัวผลิตภัณฑ์ควรเข้ามาพบคุณตรงจุดไหน ทักษะแต่ละอย่างกลับมาเป็นการ์ดฟีดแบ็กที่ขยายได้ พร้อมสรุป คำแนะนำที่จับต้องได้ และประโยคจริงที่ยกมาจากการโทรของคุณเองเป็นตัวอย่าง มันคือฟีเจอร์ที่ประสบการณ์การฝึกที่เหลือทั้งหมดถูกสร้างต่อยอดขึ้นไป

สายที่สอง: หน้าต่างใหม่ทั้งบาน

สายที่สองคือ การออกแบบพรีเมียมใหม่ — และการเรียกมันว่าการออกแบบใหม่ก็ยังพูดน้อยไป มันไม่ใช่การเปลี่ยนผิวของหน้าจอเดิม แต่มันคือ หน้าต่างแอปพลิเคชันที่สอง อย่างแท้จริง ที่สร้างออกมาในหกเฟสอย่างชัดเจน: แถบข้างสไตล์ Notion ที่ยุบได้ ดรอปดาวน์ในส่วนหัวที่มาแทนที่ลิสต์เซสชันแบบเดิม การนำทางสไตล์เบราว์เซอร์พร้อมประวัติและเบรดครัมบ์ และการรีบิลด์พรีเมียมของหน้า Home, Profiles, Meetings และ Settings

ฟีเจอร์ใหญ่สองอย่าง นั่นแหละคือสิ่งที่ 127 คอมมิตเป็นจริง ๆ และส่วนที่ยากที่สุดของการส่งมอบมันไม่ใช่การเขียนอย่างใดอย่างหนึ่ง — แต่มันคือการถักทอ branch ทั้งสองพึ่งพากันและกัน; อันหนึ่งถูก merge เข้าไปในอีกอัน และ branch การคาลิเบรตต้องดึง branch main เข้ามาถึง สี่ครั้งแยกกัน เพียงเพื่อไม่ให้หลุดออกจากการซิงก์ในขณะที่งานออกแบบใหม่ขยับอยู่ข้างใต้มัน จำนวนคอมมิตไม่ใช่ต้นทุนของรีลีสขนาดใหญ่ branch ที่อยู่ยาวและลำดับการรวมโค้ดต่างหากที่เป็น

ส่วนที่คุ้มค่าแก่การอ่าน: เราสร้างการคาลิเบรตไว้ผิดที่

นี่คือความผิดพลาด และมันเป็นความผิดพลาดที่ดีเพราะมันพบได้บ่อยมาก

GeekBye มีกฎทางสถาปัตยกรรมที่แน่วแน่: การทำงานของ AI ทั้งหมดอยู่ที่ backend ตัว client เป็นเปลือกบาง ๆ ที่คุยกับเซิร์ฟเวอร์ ทุกคนรู้เรื่องนี้

แต่กระนั้นการคาลิเบรตก็ถูกสร้างไว้ ในฐานข้อมูลในเครื่องของ client ก่อน ตารางเฉพาะทาง การ migrate ฐานข้อมูล repository ขนาด 254 บรรทัด IPC handlers และคลังคำถามประเมิน 515 บรรทัด — ทั้งหมดอยู่บนเครื่องของผู้ใช้ มันใช้งานได้ และมันยังละเมิดสัญญาที่ทั้งแอปสร้างขึ้นมาบนนั้นอย่างเงียบ ๆ ด้วย

สามวันต่อมา คอมมิตหนึ่งลบ 680 บรรทัดข้ามแปดไฟล์ เพื่อย้ายทั้งหมดไปที่ backend ซึ่งข้อมูลการคาลิเบรตกลายเป็นโมเดลฝั่งเซิร์ฟเวอร์ที่ถูกต้อง และตรรกะคำถามกับการให้คะแนนก็กลายเป็นเรื่องของเซิร์ฟเวอร์ อีกคอมมิตหนึ่งลบคลังคำถามฝั่ง client ขนาด 515 บรรทัดออกไปทั้งหมด diff นั้นเกือบจะน่าขำ: หนึ่งการเพิ่ม หกร้อยแปดสิบการลบ

ไม่มีใครตั้งใจจะเขียนโค้ดใช้แล้วทิ้ง 680 บรรทัด มันเกิดขึ้นในแบบที่มันเกิดขึ้นเสมอ: ทางลัดฝั่ง client มันอยู่ตรงนั้น การสร้างต้นแบบในเครื่องมันเร็วกว่า และคำว่า "เดี๋ยวค่อยย้ายไป backend ทีหลัง" ก็รู้สึกไม่มีพิษภัย แต่เมื่อสถาปัตยกรรมของคุณบอกอยู่แล้วว่า source of truth อยู่ที่ไหน การสร้างมันไว้ที่อื่นก็ไม่ใช่ทางลัด — มันคืองานรื้อทำใหม่ที่คุณจองคิวไว้ให้ตัวเองล่วงหน้า บทเรียนที่ติดตัวมา: วางมันไว้ในที่ที่สัญญาบอกไว้ ตั้งแต่ครั้งแรก แม้ในตอนที่เวอร์ชันในเครื่องจะตั้งขึ้นได้เร็วกว่าก็ตาม

บั๊กที่มีเพียงการรวมโค้ดเท่านั้นที่หาเจอ

หลักฐานอีกชิ้นหนึ่ง เพราะมันคือรูปแบบความล้มเหลวอันเป็นเอกลักษณ์ของรีลีสขนาดใหญ่ เมื่อการคาลิเบรตและการนำทางใหม่ถูกต่อสายเข้าด้วยกันและทำงานจริง แอปก็เริ่มไปสะดุด rate limit — HTTP 429 — โดยไม่มีเหตุผลที่ชัดเจน

สาเหตุคือการรวมโค้ดล้วน ๆ สถานะการคาลิเบรตถูก fetch ที่ระดับคอมโพเนนต์ ดังนั้นทุกการนำทางจึง fetch มันซ้ำ — และ strict mode ของ React ซึ่งจงใจเรียก effect ซ้ำสองครั้งในโหมด development เพื่อเผยบั๊ก ก็ทำให้มันเป็นสองเท่าอีก ผลลัพธ์คือ คำขอคาลิเบรตที่เหมือนกันสี่ถึงแปดคำขอยิงออกไปต่อการเปลี่ยนหน้าจอหนึ่งครั้ง ซึ่งมากพอที่จะไปสะดุดตัวจำกัดอัตราของเซิร์ฟเวอร์ การแก้ไขรวมการ fetch ให้เหลือเพียงไม่กี่ครั้งตอน mount

คุณไม่มีทางหาบั๊กนี้เจอด้วยการทดสอบการคาลิเบรตเพียงลำพัง หรือการนำทางเพียงลำพัง มันมีอยู่ได้เฉพาะที่รอยต่อ — ที่ซึ่งฟีเจอร์สองอย่างที่ถูกต้องในตัวเองมาบรรจบกัน นั่นคือภาษีที่รีลีสขนาดใหญ่เรียกเก็บ: หนึ่งไมล์สุดท้ายไม่ใช่การสร้างฟีเจอร์ แต่มันคือการค้นพบทุกสิ่งที่จะพังก็ต่อเมื่อพวกมันได้มาอยู่ในห้องเดียวกันเสียที

สามสิ่งที่รีลีสขนาดใหญ่สอนเรา

1. รีลีสขนาด 127 คอมมิตคือธีมใหญ่สองหรือสามธีม ไม่ใช่เรื่องเล็ก ๆ ร้อยเรื่อง จงหาสายให้เจอ งาน — และความเสี่ยง — อยู่ที่วิธีที่พวกมันถักทอเข้าด้วยกัน ไม่ใช่ที่จำนวนนับ
2. วาง source of truth ไว้ในที่ที่สัญญาบอกว่ามันอยู่ ตั้งแต่ครั้งแรก เราลบ 680 บรรทัดเพื่อย้ายการคาลิเบรตจาก client ไป backend ทางลัดในเครื่องคืองานรื้อทำใหม่ที่คุณจัดคิวไว้ล่วงหน้า สถาปัตยกรรมบอกคำตอบให้คุณแล้ว
3. การรวมโค้ดเผยความล้มเหลวที่การทำงานแบบแยกส่วนหาไม่เจอ พายุ 429 อาศัยอยู่ที่รอยต่อระหว่างฟีเจอร์ที่ถูกต้องสองอย่างและปรากฏออกมาก็ต่อเมื่อพวกมันทำงานร่วมกัน จงเผื่องบให้กับรอบการรวมโค้ด ไม่ใช่แค่การทดสอบทีละฟีเจอร์

นี่คือญาติในยุค v1 ของเรื่องราวที่เราจะเล่าอีกครั้งในสเกลที่ใหญ่กว่ามาก — ดูว่าเวอร์ชัน 2 ต้องใช้อะไรจริง ๆ: 206 คอมมิตของสถานะที่ซื่อสัตย์ (v2.0.0) ที่ซึ่งความจริงเดียวกันว่า "ตัวเลขใหญ่จริง ๆ แล้วคือไอเดียใหญ่ไม่กี่อัน" เล่นตัวออกมาตลอดการเขียนใหม่ทั้ง v2 สำหรับบทก่อนหน้าในเรื่องราว v1 ดูวิธีสตรีมรายงานสดโดยไม่ให้หน้าจอกระพริบ (v1.6.13); และสำหรับภาพรวมทั้งเส้นเรื่อง ดูกายวิภาคของการส่งมอบซอฟต์แวร์ให้สมบูรณ์แบบ