กายวิภาคของการส่งซอฟต์แวร์ให้สมบูรณ์แบบ: เมื่อ Code Review จับสิ่งที่ Test จับไม่ได้

ในช่วงเวลาไม่กี่สัปดาห์ GeekBye ส่งออกไปเก้ารีลีส — v2.0.0 ถึง v2.0.11 — และซีรีส์นี้เล่าเรื่องราวของแต่ละรีลีส อ่านรวมกันแล้วจะเห็นรูปแบบหนึ่งโดดขึ้นมา ซึ่งน่าสนใจยิ่งกว่าบั๊กใดบั๊กหนึ่ง: ครั้งแล้วครั้งเล่า การแก้ไขผ่านทุกเทสต์บนเครื่องของนักพัฒนา แล้ว code review ก็พิสูจน์ว่ามันจะพังสำหรับเกือบทุกคนที่เหลือ

ช่องว่างนั้น — ระหว่าง "มันทำงานบนเครื่องผม" กับ "มันทำงานได้จริง" — คือที่ที่ความเชื่อถือได้อยู่จริง นี่คือเวิร์กโฟลว์ที่ปิดช่องว่างนั้น และดัชนีไปสู่ทุกรีลีสที่มันสร้างขึ้น

รูปแบบ: เทสต์สีเขียว คำตอบผิด

นี่คือสามกรณีที่ชัดเจนที่สุดจากซีรีส์ เพราะมันทำให้สิ่งที่เป็นนามธรรมกลายเป็นรูปธรรม

• ในการแก้ไขการจับภาพหน้าจอหลายจอ (v2.0.10) การimplement ครั้งแรกยึดการจับภาพหน้าจอไว้กับหน้าต่าง overlay ของแอป มันผ่านการทดสอบ — บนเครื่องนักพัฒนาที่มีจอเดียว การรีวิวให้เหตุผลว่า overlay นั้นอยู่ที่ไหนจริงๆ (จอหลัก เสมอ เว้นแต่คุณจะลากมันไปเอง) และพิสูจน์ว่า "การแก้ไข" นั้นจะชี้กลับไปที่จอผิดสำหรับผู้ใช้จริงเกือบทุกคน จุดยึดที่ถูกต้อง — เคอร์เซอร์ — ออกมาจากการโต้แย้งนั้น ไม่ได้ออกมาจากการรันเทสต์
• ในรีลีสWebSocket-fallback (v2.0.8) การรีวิวพบว่า 403 ที่ blocking proxy คืนกลับมานั้น ถูกจัดประเภทเป็น fatal auth error — ดังนั้น fallback ที่ฟีเจอร์นี้มีอยู่เพื่อทริกเกอร์จึงไม่มีวันทำงาน ฟีเจอร์นี้คงจะถูกส่งออกไป ผ่านเทสต์ happy-path ของมัน และไม่ทำอะไรเลยสำหรับกลุ่มผู้ใช้ที่แท้จริง
• ในการแก้ไข idle-timeout (v2.0.9) เวอร์ชันแรกประทับนาฬิกา "ยังมีชีวิตอยู่" ไว้ในเส้นทางโค้ดที่ทรานสคริปต์บางส่วนข้ามไปอย่างชอบธรรม — ของอีกคนที่พูด การรีวิวจับได้ว่าการเปลี่ยนแปลงในอนาคตอาจนำบั๊กที่กำลังแก้กลับมาเงียบๆ และตราประทับจึงถูกย้ายไปที่ที่ไม่มีเงื่อนไข พร้อมเทสต์ที่คอยรักษาไว้ตรงนั้น

ไม่มีสักอันในนี้ที่ถูกจับได้จากการรันโค้ด ทั้งหมดถูกจับได้จากผู้รีวิวที่ให้เหตุผลว่า ทำไม โค้ดถึงทำงาน — และพบกรณีที่มันไม่ทำงาน

สามส่วนของด่าน

เวิร์กโฟลว์เบื้องหลังซีรีส์นี้ไม่ได้ซับซ้อน มันคือนิสัยสามอย่างที่ใช้โดยไม่มีข้อยกเว้น

1. การรีวิวให้เหตุผลเรื่องความถูกต้อง ไม่ใช่แค่รันโค้ด เทสต์ที่ผ่านพิสูจน์ว่าโค้ดทำงานได้สำหรับกรณีที่คุณคิดถึง การรีวิวคือโมเดลที่สองที่ตั้งใจหักล้างระบบ ถามว่า กรณีไหนที่คุณคิดไม่ถึง? — จอที่สอง proxy ขององค์กร ทรานสคริปต์ที่ข้ามสาขานั้น ไคลเอนต์ที่ตามหลังอยู่หนึ่งเวอร์ชัน ขั้นตอนรีวิวในซีรีส์นี้บ่อยครั้งเป็น agent reviewer อิสระที่ถูกสั่งให้ หักล้าง การแก้ไข ไม่ใช่ให้พร มุมมองนั้นคือหัวใจทั้งหมด: ผู้รีวิวที่พยายามทำลายเหตุผลของคุณจะพบรูที่ผู้รีวิวซึ่งพยายามอนุมัติมันอ่านผ่านไป

2. ทุกการแก้พฤติกรรมถูกส่งพร้อมเทสต์ที่ตรึงจุดพังไว้แน่นอน ไม่ใช่เทสต์ที่บอกว่าฟีเจอร์ทำงาน — แต่เป็นเทสต์ที่บอกว่า บั๊กเฉพาะตัวนี้ ตายแล้ว 403 จาก blocked-proxy ต้องหล่นลงไปที่ fallback; 403 ที่เป็น auth จริงต้องไม่ นาฬิกากิจกรรมต้องประทับบนทรานสคริปต์ที่ข้ามการระบุแหล่งที่มา เทสต์เหล่านี้มีอยู่เพื่อไม่ให้บั๊กกลับมาเงียบๆ ในอีกหกเดือน ตอนที่ใครสักคนรีแฟกเตอร์บริเวณใกล้เคียง — จุดพังถูกตอกตรึงไว้กับพื้น

3. บิลด์ถูก notarized และยืนยันก่อนส่ง การแก้ไขหลายอันเดินทางจากการวินิจฉัยไปสู่รีลีสที่เซ็น notarized และอัปเดตอัตโนมัติ ภายในวันเดียว ความเร็วนั้นปลอดภัยได้ก็เพราะด่านมีวินัยเท่านั้น: การวินิจฉัยพิสูจน์ต้นตอ (รีลีสสิทธิ์ไมโครโฟน ส่งการวินิจฉัยของมัน ก่อน) เทสต์ตรึงการแก้ไข การรีวิวหักล้างเหตุผล และเมื่อนั้นเท่านั้นบิลด์ notarized จริงจึงจะออกไป ความเข้มงวดคือสิ่งที่ทำให้ความเร็วปลอดภัย ไม่ใช่สิ่งที่ต้องแลกกับความเร็ว

ทำไมเรื่องนี้สำคัญกว่าสำหรับแอป AI

มีเหตุผลว่าทำไมวินัยนี้ถึงต่อรองไม่ได้สำหรับเครื่องมืออย่าง GeekBye โดยเฉพาะ บั๊กที่ร้ายกาจที่สุดหลายตัวในซีรีส์เป็นแบบ ผิดเงียบๆ ไม่ใช่แครชดังลั่น: ภาพหน้าจอที่ป้อน จอผิด ให้ AI (v2.0.10) การถอดเสียงที่เอนเอียงไปหาคำขยะจน "speak" กลายเป็นชื่อคน (v2.0.11) ผู้ช่วยที่ตอบในโหมดผิดโดยไม่มีทางมองเห็นมัน (v2.0.3 + v2.0.5) เมื่อแอปของคุณป้อนบริบทให้โมเดล อินพุตที่ผิดจะสร้างเอาต์พุตที่ผิดอย่างมั่นใจ และ ไม่มี error ที่ไหนเลย คุณเทสต์ตัวเองออกจากความล้มเหลวที่ไม่โยน error ไม่ได้ คุณต้องให้เหตุผลตัวเองออกมา — ซึ่งเป็นสิ่งที่ด่านรีวิวมีไว้เพื่อการนั้นพอดี

ซีรีส์ ตามลำดับ

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

1. เวอร์ชัน 2 ต้องใช้อะไรจริงๆ: 206 commit ของสถานะที่ซื่อสัตย์ — v2.0.0 รากฐาน: อย่าแสดงสถานะที่ไม่จริง
2. วันที่แอปของเรา DDoS ตัวเอง — v2.0.1 + v2.0.4 backlog การอัปโหลดตอนสตาร์ทที่ถล่ม backend ของเราเอง และบันได liveness ที่มันบีบให้ต้องสร้าง
3. ซอฟต์แวร์ที่สงบนิ่ง: การแก้กระพริบและ chip โหมดคำตอบ — v2.0.3 + v2.0.5 รีลีสที่ไม่มีฟีเจอร์ ซึ่งซื้อความเชื่อใจทีละรายละเอียด
4. แอป Mac ของคุณลืมสิทธิ์เข้าถึงไมโครโฟนทุกครั้งที่เปิด — v2.0.6 macOS App Translocation และการส่งการวินิจฉัยก่อนการแก้ไข
5. หนึ่งตัวแปร CSS ห้ารอบรีวิว และ Swift toolchain ที่โกหก — v2.0.7 ความโปร่งแสงที่สม่ำเสมอ และไบนารีที่ขนาดเปลี่ยนเพราะเอกสารขัดแย้งกับสคริปต์ตรวจสอบ
6. การถอดเสียงสดเมื่อไฟร์วอลล์บล็อก WebSocket — v2.0.8 fallback แบบ HTTPS ล้วน และ 403 ที่คงจะซ่อนมันจากตัวมันเอง
7. ทำไม AI จดบันทึกการประชุมของคุณหยุดอัดกลางการประชุม — v2.0.9 ตัวจับเวลา idle ที่ได้ยินแค่คุณ และแครชที่อาจล็อกเดสก์ท็อปของคุณ
8. ทำไมการอัดหน้าจอถึงจับจอผิด — v2.0.10 บั๊กจอผิด และการแก้ไขที่ผ่านบนจอเดียวแต่จะพังบนสองจอ
9. ทำไม AI ถอดเสียงถึงฟังศัพท์เทคนิคผิด — v2.0.11 การ bias การพูดไปหาคำศัพท์ของคุณ — และการถดถอยที่ทำให้มันแย่ลงก่อนจะทำให้ดีขึ้น

สิ่งที่ได้เรียนรู้

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

ทุกรีลีสข้างต้นใช้งานได้แล้วผ่านการอัปเดตอัตโนมัติ สำหรับผลิตภัณฑ์ที่การแก้ไขเหล่านี้รวมกันสร้างขึ้น ดูมีอะไรใหม่ใน GeekBye v2