ทุกขั้นตอนการรีวิวทำให้ความเร็วช้าลง 10 เท่า

• อธิบายโครงสร้างที่ ยิ่งมีขั้นตอนอนุมัติ·ตรวจทานภายในองค์กรมากขึ้น ความเร็วในการทำงานก็จะยิ่งช้าลงแบบทวีคูณ พร้อมยกตัวอย่างจริงว่าขั้นตอนอนุมัติแต่ละขั้นทำให้เกิดความล่าช้าราว 10 เท่า
• แม้เครื่องมือเขียนโค้ดด้วย AI จะเพิ่มความเร็วในการเขียนโค้ดอย่างมาก แต่ เวลาแฝง (latency) ในไปป์ไลน์การรีวิวหลังจากนั้นไม่ได้ลดลง จึงทำให้ผลของการเพิ่มความเร็วโดยรวมมีน้อยมาก
• นำปรัชญาคุณภาพการผลิตของ W. E. Deming มาประยุกต์กับซอฟต์แวร์ โดยชี้ว่าการเพิ่มขั้นตอน QA กลับทำให้ ทั้งคุณภาพและความเร็วแย่ลง
• ควรลดการรีวิวลงและแทนที่ด้วย วัฒนธรรมคุณภาพที่อิงกับความเป็นโมดูลและความไว้วางใจ โดยหัวใจสำคัญคือการปรับปรุงเชิงโครงสร้างให้การรีวิวกลายเป็นสิ่งไม่จำเป็น
• ทีมขนาดเล็กได้เปรียบในยุค AI และจำเป็นต้องออกแบบองค์กรและระบบใหม่ด้วยวิธี ประกอบคอมโพเนนต์เล็ก ๆ ที่งดงาม เข้าด้วยกัน

---

กฎที่ว่าขั้นตอนรีวิวสร้างความล่าช้า 10 เท่า

• เช่นเดียวกับกฎของผลกระทบจากเครือข่าย เมื่อทีมใหญ่ขึ้นจะเกิด ภาระโอเวอร์เฮดในการประสานงาน และแม้เพิ่มจำนวนทีมเป็นสองเท่า ความเร็วก็ไม่ได้เพิ่มเป็นสองเท่า
• มีกฎจากประสบการณ์ที่พบมาหลายสิบปี: ทุกครั้งที่เพิ่มขั้นตอนรีวิวหนึ่งขั้น กระบวนการจะช้าลง 10 เท่า
• แม้จะไม่มีฐานทฤษฎีรองรับ แต่เป็นปรากฏการณ์ที่สังเกตพบซ้ำแล้วซ้ำเล่าในโลกจริง
• เวลาที่วัดในที่นี้ไม่ใช่ effort แต่เป็น เวลาตามนาฬิกาจริง (wall clock time) และเวลาที่เพิ่มขึ้นส่วนใหญ่คือเวลารอ
• ตัวอย่างที่เป็นรูปธรรม:
  • เขียนโค้ดแก้บั๊กง่าย ๆ: 30 นาที
  • รีวิวโค้ดโดยเพื่อนร่วมงานที่นั่งข้าง ๆ: 300 นาที (ประมาณ 5 ชั่วโมง หรือครึ่งวัน)
  • ขออนุมัติเอกสารออกแบบจากทีมสถาปนิก: 50 ชั่วโมง (ประมาณ 1 สัปดาห์)
  • ใส่เข้าตารางงานของอีกทีมหนึ่ง (เช่น คำขอฟีเจอร์จากลูกค้า): 500 ชั่วโมง (12 สัปดาห์, 1 ไตรมาสบัญชี)
• ขั้นถัดไปคือ 10 ไตรมาส (ประมาณ 2.5 ปี) ก็ไม่ใช่เรื่องเกินจริง และแม้แต่บริษัทที่ค่อนข้างเล็กอย่าง Tailscale ก็ยังเกิดความล่าช้าระดับนี้เมื่อมีการเปลี่ยนทิศทางผลิตภัณฑ์

AI แก้ปัญหานี้ไม่ได้

• ต่อให้ Claude ทำงานเขียนโค้ด 30 นาทีให้เสร็จใน 3 นาที คุณก็แค่ประหยัดได้ 27 นาทีเพื่อเอาไป วนรีวิวกับ AI ต่อเอง หรือไม่ก็ส่งโค้ดที่ยังไม่ได้ตรวจสอบให้คนรีวิว
• คนรีวิวยังต้องใช้เวลา 5 ชั่วโมงเหมือนเดิม และถ้าคุณส่งโค้ดที่ตัวเองยังไม่ได้อ่านให้เขา คนรีวิวก็จะไม่พอใจ
• มีคนบอกว่าคุณค่าที่แท้จริงของ agentic coding คือการทำโปรเจ็กต์ใหญ่ที่ปกติต้องใช้ 1 สัปดาห์ให้เสร็จในไม่กี่ชั่วโมง แต่ผลลัพธ์นั้นใหญ่เกินกว่าที่ผู้รีวิวจะตรวจได้ในรอบเดียว
  • ต้องแยกเป็นหน่วยเล็ก ๆ และแต่ละหน่วยก็ยังเกิดรอบรีวิว 5 ชั่วโมง
  • และเพราะไม่มีเอกสารออกแบบ ก็ไม่มีสถาปัตยกรรมที่ตั้งใจไว้ สุดท้ายก็กลับไปจบที่การประชุมรีวิวการออกแบบ
  • ผลคือ โปรเจ็กต์ที่เสร็จใน 2 ชั่วโมงกลับยืดไปเป็น 1 สัปดาห์อีกครั้ง

วิธีเดียวคือต้องลดการรีวิว

• สมมติฐานของทฤษฎี Singularity คือ ระบบจะสร้างระบบที่ฉลาดขึ้นเรื่อย ๆ และหากเวลาในการปรับปรุงต่อหนึ่งหน่วยเข้าใกล้ศูนย์ ก็จะเกิดการเติบโตแบบระเบิด
• เหตุผลที่ไม่เชื่อทฤษฎีนี้คือ เวลาส่วนใหญ่ในการทำอะไรให้เสร็จไม่ได้เป็นเวลาทำงานจริง แต่เป็น เวลาตามนาฬิกาจริง หรือก็คือการรอและความล่าช้า
• เวลาแฝงไม่สามารถเอาชนะได้ด้วย brute force

หรือจะไม่รีวิวเลยไม่ได้ไม่ใช่หรือ

• หลายคนเริ่มเห็นอาการนี้แล้ว: ขั้นแรกของไปป์ไลน์ (โค้ดที่ AI สร้าง) เร็วขึ้น แต่ขั้นรีวิวถัดไปกลับกลายเป็นคอขวด
• ทางแก้ที่ดูเข้าใจง่ายคือ เลิกรีวิวไปเลย → ต่อให้งานออกมาหยาบ ถ้า ต้นทุนถูกลง 100 เท่า แค่ให้มูลค่าได้ 1% ก็ถึงจุดคุ้มทุน
• แต่ตรรกะนี้ตั้งอยู่บนสมมติฐานที่ค่อนข้างไร้เดียงสา
• กราฟดิ่งสู่ความบ้าคลั่งของนักพัฒนา AI (AI Developer's Descent Into Madness):
  1. สร้างต้นแบบได้เร็วอย่างน่าทึ่ง → รู้สึกเหมือนมีพลังพิเศษ
  2. ต้นแบบเริ่มมีบั๊ก → สั่งให้ AI แก้
  3. ทุกครั้งที่แก้ไข ก็เกิดบั๊กใหม่พอ ๆ กับที่แก้ได้
  4. เริ่มหลงคิดว่าให้ AI agent รีวิวโค้ดของตัวเองแล้วจะเจอบั๊กของตัวเองได้
  5. สุดท้ายพบว่าตัวเองกำลังส่งข้อมูลระหว่าง agent โดยตรง
  6. เริ่มรู้สึกว่าต้องมี agent framework
  7. แล้วก็ใช้ agent เขียน agent framework อีกที
  8. วนกลับไปข้อ 1
• Claude Code เพิ่งใช้งานได้จริงเมื่อไม่กี่เดือนที่ผ่านมา วงจรนี้จึงเพิ่งเริ่มเมื่อไม่นานนี้ และมีทั้งเพื่อนร่วมงานกับคนที่นับถือจำนวนมาก กำลังติดอยู่ในวงจรนี้

ทำไมเราถึงรีวิว

• เมื่อบริษัทเติบโตขึ้น ขั้นตอนร่วมงาน รีวิว และการจัดการก็เพิ่มขึ้น → เพื่อป้องกันความผิดพลาด เพราะยิ่งขนาดใหญ่ ต้นทุนของความผิดพลาดก็ยิ่งสูง
• จะมีจุดหนึ่งที่มูลค่าเพิ่มเฉลี่ยของฟีเจอร์ใหม่ ต่ำกว่าความเสียหายเฉลี่ยจากบั๊กใหม่ที่มันก่อขึ้น
• เพราะไม่มีวิธีเพิ่มมูลค่าของฟีเจอร์ได้ เราจึงหันไป ลดความเสียหาย แทน
• หากเพิ่มการตรวจสอบและการควบคุม ความเร็วจะช้าลง แต่คุณภาพดูเหมือนจะ เพิ่มขึ้นแบบ monotonic จึงดูเหมือนเป็นฐานของการปรับปรุงอย่างต่อเนื่อง
• แต่ “การตรวจสอบและการควบคุมให้มากขึ้น” ไม่ใช่ วิธีเดียวในการยกระดับคุณภาพ และยังเป็นวิธีที่อันตราย

“การประกันคุณภาพ (QA)” กลับทำให้คุณภาพต่ำลง

• อ้างอิงปรัชญาคุณภาพที่ W. E. Deming ทำให้แพร่หลายในอุตสาหกรรมรถยนต์ญี่ปุ่น
• ปัญหาของขั้น QA ในโรงงานคือ: ผลิตชิ้นส่วน → ตรวจ/QA → คัดของไม่ผ่าน → เพื่อกันตกหล่นจึง เพิ่ม QA รอบที่สอง
• ในแบบจำลองคณิตศาสตร์อย่างง่าย เรื่องนี้ดูสมเหตุสมผล (ถ้า QA แต่ละขั้นจับข้อบกพร่องได้ 90% การมี 2 ขั้นจะ ลดข้อบกพร่องลง 100 เท่า)
• แต่ในสภาพแวดล้อมที่มี มนุษย์ผู้กระทำการอย่างอิสระ (agentic humans) แรงจูงใจจะบิดเบี้ยว:
  • ทีม QA รอบสองมีหน้าที่เหมือนประเมินทีม QA รอบแรก → ไม่มีแรงจูงใจจะขยันหาผลลัพธ์ที่อาจทำให้เพื่อนร่วมงานตกงาน
  • ทีม QA รอบแรกก็จะคาดว่าทีมรอบสองคงจับให้เอง จึง ลดความพยายามลง
  • ทีมผลิตชิ้นส่วนก็คิดว่ามีทีม QA อยู่แล้ว จึงละเลยการตรวจของตัวเอง → เมื่อเทียบกันแล้ว ของเสีย 10% ดูดีกว่าทำงานช้าลง 20%
  • การออกแบบทางวิศวกรรมใหม่ทั้งระบบเพื่อยกระดับคุณภาพถูก หลีกเลี่ยงเพราะต้นทุนสูงเกินไป
• Toyota Production System เอาขั้น QA ออกไปทั้งหมด และให้ทุกคนมี ปุ่ม “หยุดสายการผลิต”
• ผู้ผลิตรถยนต์สหรัฐฯ ติดปุ่มแบบเดียวกัน แต่ ไม่มีใครกด → เพราะกลัวถูกไล่ออก

ความไว้วางใจ (Trust)

• ความต่างที่ทำให้ระบบญี่ปุ่นสำเร็จและระบบอเมริกันล้มเหลวคือ ความไว้วางใจ
• ความไว้วางใจระหว่างบุคคล: มั่นใจว่าหัวหน้าต้องการรู้ข้อบกพร่องทั้งหมดจริง ๆ และเมื่อเจอแล้วควรหยุดสายการผลิต
• ความไว้วางใจระหว่างผู้จัดการ: มั่นใจว่าฝ่ายบริหารจริงจังกับคุณภาพ
• ความไว้วางใจระหว่างผู้บริหาร: มั่นใจว่าถ้ามีระบบและแรงจูงใจที่ถูกต้อง คนแต่ละคนจะ ทำงานที่มีคุณภาพสูงและพบข้อบกพร่องของตัวเองได้
• ยังมีเงื่อนไขเพิ่มเติมคือ ต้อง ไว้วางใจว่าระบบนี้ใช้งานได้จริง → ซึ่งแปลว่าต้องมีระบบที่ใช้งานได้จริงก่อน

ความผิดพลาดเป็นไปได้เสมอ (Fallibility)

• AI coder มักเขียนโค้ดที่ไม่ดี และในแง่นี้ก็ ไม่ต่างจากโปรแกรมเมอร์มนุษย์
• แนวทางของ Deming ไม่มีคำตอบวิเศษ → วิศวกรต้อง ออกแบบคุณภาพจากล่างขึ้นบน ให้กับระบบทั้งหมด
• ทุกครั้งที่เกิดปัญหา ต้องถามว่า “เรื่องนี้เกิดขึ้นได้อย่างไร?” แล้วใช้ postmortem และ Five Whys หาเหตุรากและแก้ไข
• “เพราะคนเขียนโค้ดทำผิด” ไม่ใช่เหตุราก แต่เป็น อาการ → ต้องหาสาเหตุเชิงโครงสร้างที่เปิดทางให้คนเขียนทำผิดได้
• บทบาทที่แท้จริงของคนรีวิวโค้ดไม่ใช่การรีวิวโค้ด แต่คือ ทำให้คอมเมนต์รีวิวของตัวเองกลายเป็นสิ่งไม่จำเป็น
  • ปรับปรุงระบบเพื่อไม่ให้คอมเมนต์ประเภทนั้นเกิดขึ้นอีกในอนาคต
  • ต้องตั้งเป้าไปสู่สภาวะที่ไม่ต้องมีรีวิวก็ได้
• ตัวอย่าง: คนที่สร้าง go fmt → กำจัดคอมเมนต์รีวิวเรื่องช่องว่างและรูปแบบโค้ดได้ถาวร → นี่ต่างหากคือวิศวกรรมที่แท้จริง
• กว่าที่การรีวิวจะพบความผิดพลาด ความผิดพลาดนั้นก็เกิดขึ้นไปแล้ว → ต้นเหตุที่แท้จริงได้ผ่านพ้นไปแล้ว

ความเป็นโมดูล (Modularity)

• ไปป์ไลน์รีวิว (ขั้น QA) ใช้งานไม่ได้จริง และยังทำให้ช้าลงพร้อมกับ ซ่อนสาเหตุราก ของปัญหา → ยิ่งทำให้แก้ที่ต้นเหตุได้ยากขึ้น
• เสน่ห์ของการเขียนโค้ดด้วย AI คือ ขั้นแรกของไปป์ไลน์ เร็วอย่างท่วมท้น → ให้ความรู้สึกเหมือนมีพลังพิเศษ
• เป็นไปได้ว่าในที่สุดเราก็มีแรงจูงใจมากพอที่จะสะสางปัญหาที่ซ่อนอยู่ใต้วัฒนธรรม code review ตลอด 20 ปี และ แทนที่ด้วยวัฒนธรรมคุณภาพที่แท้จริง
• ฝ่ายมองโลกในแง่ดีถูกอยู่ครึ่งหนึ่ง: เราต้องลดขั้นตอนรีวิวลง แต่ถ้าลดโดย ไม่มีสิ่งมาทดแทน ก็จะลงเอยเหมือน Ford Pinto หรือเครื่องบิน Boeing รุ่นล่าสุด
• เช่นเดียวกับที่ Deming เปลี่ยนอุตสาหกรรมการผลิต เราต้องการ การพลิกโต๊ะแบบยกแพ็กเกจทั้งหมด (table flip) → ระบบ “คุณภาพทั่วทั้งองค์กร” จะหยิบมาใช้แค่ครึ่งเดียวไม่ได้
• ต้องเอาการรีวิวออกไปพร้อมกับ ทำให้มันไม่จำเป็นไปในเวลาเดียวกัน
• มีทางทำได้โดยเริ่มรับเอาระบบใหม่นี้อย่างครบชุดในหน่วยเล็ก ๆ:
  • เปรียบได้กับผู้ผลิตรถยนต์อเมริกันแบบเก่าที่ ซื้อชิ้นส่วนคุณภาพสูงจากซัพพลายเออร์ญี่ปุ่น
  • ถ้าชิ้นส่วนนั้นทำมาดีพอ ก็สามารถตัดขั้น QA ในส่วนอื่นออกได้ → ความซับซ้อนของงาน “ประกอบชิ้นส่วน” ลดลงอย่างมาก
• เราสามารถ ประกอบของเล็ก ๆ ที่งดงามให้กลายเป็นของใหญ่ที่งดงามได้
• ทีมเล็ก ๆ ที่เชื่อใจกัน สามารถสร้างคอมโพเนนต์แต่ละชิ้นได้ เพราะ พวกเขารู้ว่าคุณภาพสำหรับตัวเองคืออะไร
• และทีมลูกค้าก็อธิบายได้อย่างชัดเจนว่า คุณภาพสำหรับพวกเขาคืออะไร → ทำให้คุณภาพ แพร่จากล่างขึ้นบน

ทีมขนาดเล็กและการออกแบบองค์กรในยุค AI

• สตาร์ตอัปขนาดเล็ก อาจได้เปรียบกว่าในโลกใหม่ เพราะมีคนน้อยและเดิมทีก็มีขั้นตอนรีวิวน้อยอยู่แล้ว
• สตาร์ตอัปบางแห่งจะหาวิธีสร้างคอมโพเนนต์คุณภาพสูงได้อย่างรวดเร็ว ส่วนที่เหลือจะล้มเหลว → คุณภาพผ่านการคัดเลือกโดยธรรมชาติ
• บริษัทใหญ่มีระบบรีวิวที่ช้าจนฝังแน่นอยู่แล้ว และถ้าถอดมันออกอาจเกิด ความโกลาหลเต็มรูปแบบ
• ไม่ว่าบริษัทจะใหญ่แค่ไหน ทีมวิศวกรรมก็สามารถเล็กลงได้ และสามารถ กำหนดอินเทอร์เฟซระหว่างทีมให้ชัดเจนขึ้น
• อาจเกิดโมเดลที่ หลายทีมในบริษัทเดียวกันพัฒนาคอมโพเนนต์เดียวกันแข่งกัน
  • แต่ละทีมประกอบด้วยคนจำนวนน้อยและ coding bot
  • ลอง 100 วิธีแล้วเลือกสิ่งที่ดีที่สุด → คุณภาพผ่านวิวัฒนาการ
  • โค้ดมีราคาถูกลง แต่ ไอเดียที่ดียังมีราคาแพง → เพียงแต่เราสามารถลองไอเดียใหม่ได้เร็วกว่าที่เคย
• อาจเกิดจุดเหมาะสมใหม่บน continuum ระหว่าง monolith กับ microservices
  • microservices ถูกมองไม่ดีเพราะเล็กเกินไป แต่ในความหมายดั้งเดิม “micro” service คือขนาดที่เหมาะให้ ทีมขนาด “สองถาดพิซซ่า” สร้างและดูแล
  • ในยุค AI มันอาจเหลือแค่ระดับ “พิซซ่าหนึ่งถาดกับโทเค็นอีกนิดหน่อย”
• การเขียนโค้ดที่เร็วขึ้นแบบใหม่ทำให้เราสามารถ ทดลองกับขอบเขตของโมดูลเองได้เร็วขึ้น
  • ฟีเจอร์ยังคงเป็นเรื่องยาก แต่ refactoring และการทดสอบรวมแบบอัตโนมัติ เป็นสิ่งที่ AI ทำได้ดี
  • เราอาจลองแยกโมดูลที่เมื่อก่อนกลัวจะแยกไม่ได้ → แม้จำนวนบรรทัดโค้ดจะเพิ่มขึ้น แต่ก็ยังถูกกว่า โอเวอร์เฮดในการประสานงาน ที่เกิดจากทีมใหญ่ต้องดูแลทั้งสองฝั่ง
• ทุกทีมมีทั้ง monolith ที่ใหญ่เกินไปและขั้นตอนรีวิวที่มากเกินไป
• ต่อให้ไปไม่ถึง Singularity เราก็ยัง สร้างโลกที่ดีกว่านี้ได้มากผ่านวิศวกรรม → ปัญหานี้แก้ได้
• หัวใจสำคัญคือ ความไว้วางใจ

[bbulbum]

ตอนที่ฉันเห็น go fmt ครั้งแรก: ทำไมถึงฟอร์แมตตามสไตล์ที่ฉันชอบไม่ได้ล่ะ..!

ตอนนี้: จะต้องมีรสนิยมกับการฟอร์แมตไปทำไม?

[GN⁺]

ความคิดเห็นจาก Hacker News

• อาจไม่ต้องมีรีวิวเลยก็ได้
  ถ้า ดึงรีวิวมาไว้ทางซ้าย แล้วเปลี่ยนเป็นเซสชันออกแบบโค้ด หยิบปัญหามาคุยในเดลี่ และแก้ส่วนที่ยากด้วยการทำ pair programming จุดประสงค์ส่วนใหญ่ของการรีวิวก็จะหายไป
  ส่วนที่เหลืออีก 10% อย่างชื่อตัวแปร เว้นวรรค แพตเทิร์นต่าง ๆ สามารถทำให้เป็นอัตโนมัติได้ด้วย linter
  ท้ายที่สุด สิ่งสำคัญคือการสร้าง วัฒนธรรมทีมที่ตั้งอยู่บนความไว้วางใจ ที่ทำให้ทีมเชื่อใจกันและเขียนโค้ดตามข้อตกลงร่วมกันได้

  • เหมือนคำพูดที่ว่า “ใช้เวลาวางแผนหลายชั่วโมงเพื่อประหยัดเวลาลงโค้ดไม่กี่นาที” แต่เราก็ไม่สามารถออกแบบสถาปัตยกรรมทั้งหมดบนไวต์บอร์ดได้
    มักจะเพิ่งเห็นปัญหาตอนลงมือทำจริง
    แทบไม่เคยมีครั้งไหนที่ทุกอย่างเป็นไปตามแผนแบบสมบูรณ์ สุดท้ายจึงต้องมี การประชุมสถาปัตยกรรมแบบวนซ้ำ แต่แบบนั้นก็เสี่ยงจะจมลงไปในบึงของประชุมรายสัปดาห์อีก
  • เคยเห็นวิศวกรที่เคารพหลายคนเลิกใช้แนวทางนี้ หลังจากเริ่มใช้ coding agent สร้าง PR อัตโนมัติ
    พอถึงขั้นไม่รีวิวแม้แต่โค้ดที่ตัวเองเป็นคนเขียน ความไว้วางใจที่สะสมมาก็พังทลายลงอย่างรวดเร็ว
  • แก่นของบทความนี้สุดท้ายก็คือ ระบบแห่งความไว้วางใจ
    ถ้าจะตัดขั้น QA ออกแบบ Toyota Production System ก็ต้องมีความไว้วางใจที่ทำให้ทุกคนหยุดได้ทันทีเมื่อพบข้อบกพร่อง
    pipeline การรีวิวมีแต่ซ่อนปัญหาและทำให้ช้าลง
  • “ดึงรีวิวมาไว้ทางซ้าย เรียกมันว่า design session หยิบปัญหามาคุยในเดลี่ แล้วแก้ด้วย pair programming”
    แค่ประโยคนี้ก็เหมือน คำนิยามของนรก แล้ว
  • เราบอกคนที่เพิ่งเข้ามาใหม่ว่า “เราเชื่อใจคุณ แต่เรารู้เบอร์โทรคุณนะ”
    ปรากฏว่าได้ผลดีทีเดียว ผู้คนจะเขียนเทสต์เอง และทำการตรวจสอบแบบแมนนวลควบคู่กันไป
    เรายังสร้าง ตาข่ายนิรภัยที่ย้อนการ deploy ที่ผิดพลาดกลับได้ภายใน 10 นาที ไว้ด้วย

• code review คือ ภาวะกลืนไม่เข้าคายไม่ออกของอาสาสมัคร
  เพราะสิ่งที่ถูกเอาไปประเมินคือ “ปล่อยฟีเจอร์ได้มากแค่ไหน” ไม่ใช่ “รีวิว PR ไปกี่อัน”
  สุดท้ายคนจึงมักรีวิวอย่างจริงจังเฉพาะเมื่อมันกระทบกับงานของตัวเองโดยตรง
  แต่เพราะโค้ดมีความยืดหยุ่น การ merge ให้เร็วแล้วค่อยแก้ตามทีหลังอาจทำให้ ลู่เข้าหาคำตอบได้เร็วกว่า

  • บางครั้งรีวิวเวอร์ก็รู้สึกรับผิดชอบต่อ ผลลัพธ์ของทีม แบบเดียวกับทีมลีด
    โดยเฉพาะแรงจูงใจในการจับบั๊กให้ได้ก่อนเพื่อลด ความเครียดจากการ on-call
  • สำหรับจูเนียร์ ควรแนะนำให้รีวิวทุก PR
    ต่อให้ยังไม่เข้าใจก็ควรทิ้งคำถามไว้ เพราะช่วยเรื่องการเรียนรู้ได้มาก
    ถ้าอยากเป็นผู้นำ ก็ควรรีวิวทั้งโค้ดและ เอกสารการออกแบบ ให้เยอะ
  • น่าสนใจที่ว่าสองสิ่งที่นักพัฒนาส่วนใหญ่มองว่าสำคัญที่สุด — การรีวิวโค้ดและการลบโค้ด — กลับไม่ค่อยได้รับผลตอบแทน

• บทความนี้ช่วยจัดระเบียบ สัญชาตญาณและประสบการณ์ ของผมได้อย่างชัดเจน
  เดิมก็ชอบผลิตภัณฑ์ของ Tailscale อยู่แล้ว แต่ตอนนี้คงได้กลายเป็นแฟนของ CEO ด้วย
  ขอบคุณ Avery ผู้เขียน และตั้งใจจะแชร์บทความนี้ให้กว้างที่สุด

• Valve เป็นหนึ่งในไม่กี่บริษัทที่เข้าใจข้อจำกัดของ แบนด์วิดท์การสื่อสาร
  ยิ่งองค์กรใหญ่ขึ้น ภาระด้านการสื่อสารก็ เพิ่มขึ้นแบบเอ็กซ์โปเนนเชียล

  • คิดว่าคนแรกที่ตระหนักเรื่องนี้คือ Jeff Bezos
    บริษัทอื่น ๆ ก็น่าจะรู้กันแล้วในตอนนี้ แต่ความจริงก็ยังไม่ใช่แบบนั้น

• น่าแปลกใจที่รีวิวถูกจัดการภายใน 5 ชั่วโมง
  ส่วนใหญ่กินเวลาเป็นระดับหลายวัน
  แต่ถ้ามี วัฒนธรรมที่ทุกคนหยุดได้ทันทีเมื่อเจอบั๊ก จริง ๆ รีวิวก็อาจไม่จำเป็น
  ในโลกความจริง โครงสร้างมักเป็นแบบที่ถ้าพลาดเป้าหมายการปล่อยของ คนคนนั้นจะเสียประโยชน์

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

• อัตราส่วนระหว่าง คุณค่ากับแรงที่ต้องใช้ ในการรีวิวมักถูกมองข้าม
  ถ้าการรีวิวไม่ได้ช่วยเพิ่มคุณภาพจริง เวลานั้นก็สูญเปล่า
  แทนที่จะถกกันเรื่องรายละเอียดจุกจิก การเช็กแค่ว่า “มันทำงานได้ไหม” แล้วรีบ merge อาจมีประสิทธิภาพกว่า
  แล้วค่อยปรับปรุงด้วย commit ถัดไปก็ได้
  รีวิวควรเป็น จุดตรวจสั้น ๆ ที่เช็กแค่ทิศทาง

• เห็นด้วยเต็มที่กับคำพูดที่ว่า “งานของ reviewer คือทำให้ไม่ต้องมีรีวิว”

• บทความนี้ตั้งต้นจากกระบวนการแบบ serialized process แต่ในความเป็นจริงมันเกิดแบบขนาน
  ถ้าจัดการหลายบั๊กพร้อมกัน ความล่าช้าของรีวิวก็ไม่ใช่ปัญหาใหญ่
  แก่นสำคัญคือการควบคุม จำนวนงานพร้อมกัน (N)

  • เลยลองทำ เครื่องคำนวณตามทฤษฎีคิว ขึ้นมา
    ลิงก์
    ยิ่งรีวิว PR ช้าเท่าไร ต้นทุนจาก context switching ก็ยิ่งสูงขึ้น
    จากผลคำนวณ ถ้าเพิ่มความเร็วในการรีวิวได้ ผลิตภาพก็จะดีขึ้นมาก

• เห็นด้วยกับคำพูดที่ว่า “เป้าหมายของ reviewer คือทำให้การรีวิวไม่จำเป็น”
  แต่ถ้า ขอบเขตของความไว้วางใจ ขยายออกไปนอกบริษัท เรื่องก็จะเปลี่ยนไป
  ตัวอย่างเช่น ถ้า npm update ทำให้มัลแวร์ถูกปล่อยออกไป การรับมือหลังเกิดเหตุย่อมสายเกินไป
  ต่อให้ยึดความไว้วางใจเป็นหลัก บางครั้งก็ยังมี จุดที่ต้องให้มนุษย์ตรวจสอบ อยู่

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

  • ทำให้นึกถึง Rule 9 ของ “How complex systems fail”
    ผู้ปฏิบัติงานต้องรับผิดชอบทั้งผลิตภาพและความปลอดภัยพร้อมกัน
    ก่อนเกิดอุบัติเหตุ ทุกคนจะเน้นผลิตภาพ แต่หลังเกิดอุบัติเหตุ ทุกคนจะเน้นความปลอดภัย
    คนนอกมักไม่เข้าใจสมดุลของ บทบาทสองด้าน นี้ดีนัก
    ลิงก์ที่เกี่ยวข้อง