Review by exception คือแนวคิดที่เสนอว่า เราไม่ควรบังคับให้โค้ดทุกบรรทัดผ่าน code review หรือการให้เพื่อนร่วมทีมอ่านโค้ดที่เขียนเสร็จแล้วก่อนรวมเข้าโปรเจกต์ แต่ควรเก็บการรีวิวไว้เฉพาะกรณีที่ต้องใช้วิจารณญาณของคนจริงๆ

แนวคิดนี้เสนอโดย Rachel Laycock จาก Thoughtworks ซึ่งเขียนขึ้นมาเพื่อตอบบทความ What are code reviews even for? ของ Brian Houck จาก DX หลังจากที่ทั้งคู่ได้ขึ้นดีเบตกันในงานเสวนา Code Remix

สิ่งที่ทั้งสองคนเห็นตรงกันคือ ตอนนี้ AI ผลิตโค้ดออกมาเร็วและเยอะเกินกว่าที่คนจะอ่านทัน ตัวเลขที่ฝั่ง Houck ยกมาคือ ที่ Meta จำนวนบรรทัดโค้ดที่มีนัยสำคัญต่อหนึ่ง diff หรือชุดโค้ดที่แก้ในหนึ่งรอบ เพิ่มขึ้นถึง 106% ภายในปีเดียว ส่วนข้อมูลของ DX เองก็พบว่า ค่ากลางของขนาด pull request ซึ่งเป็นคำขอรวมโค้ดเข้าโปรเจกต์หลัก โตขึ้น 64%

เธอไม่ได้เถียงตัวเลขชุดนี้เลย เธอยอมรับทั้งหมดแล้วไปแย้งที่ข้อสรุปแทน เพราะฝั่ง Houck มองว่าเราต้องรักษา code review ไว้แล้วหาวิธีช่วยให้คนตรวจไหว ส่วนเธอตั้งคำถามกลับว่า ทำไมเราถึงต้องรอให้โค้ดเสร็จก่อน แล้วค่อยมาคุยเรื่องสำคัญกันตอน code review

คอขวดไม่ได้หายไป มันแค่ย้ายที่

ภาพที่เธอวางไว้ตรงไปตรงมา ต่อให้ระบบ AI อย่าง agent ผลิตโค้ดออกมาได้มากกว่าเดิมสิบเท่า แต่ถ้าโค้ดทุกบรรทัดยังต้องไปต่อคิวรอวิศวกรอาวุโสนั่งอ่านทีละชิ้นเหมือนเดิม องค์กรนั้นก็ไม่ได้กลายเป็นองค์กรที่เก่งขึ้นสิบเท่าตามที่คิด สิ่งที่ได้เพิ่มมามีแค่กองงานค้างที่ใหญ่ขึ้น กับคอขวดจุดใหม่

อีกทางหนึ่งที่ทำได้เลยคือส่ง agent ไปนั่งรีวิวโค้ดแทนคน เพื่อให้ขั้นตอนเดิมผ่านไปได้เร็วขึ้น แต่เธอยืนยันว่าไม่เห็นด้วย เพราะนั่นเป็นเพียงการเอาระบบอัตโนมัติมาทับธรรมเนียมเดิม โดยไม่ได้ย้อนกลับไปถามว่าเราทำขั้นตอนนี้ไปเพื่ออะไร เรื่อง code review กลายเป็นคอขวดใหม่ จึงวนกลับมาซ้ำที่เดิมทุกครั้ง เพราะเรามัวแต่ไปเร่งความเร็วของขั้นตอน แทนที่จะถามว่างานแต่ละอย่างควรย้ายไปทำตั้งแต่ขั้นตอนไหน

code review ทำหน้าที่หลายอย่างพร้อมกัน

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

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

ฝั่ง Houck กังวลว่า ถ้าเรายกเลิก code review ทิ้งไปเฉยๆ งานสำคัญที่เหลือจะหายไปด้วย ทีมจะจับบั๊กได้น้อยลง สอนงานกันน้อยลง และเข้าใจสถาปัตยกรรมระบบของตัวเองน้อยลง เธอเองก็บอกว่ากังวลเรื่องนี้เหมือนกัน จุดที่ทั้งสองคนมองต่างกันจึงไม่ใช่ว่างานพวกนี้สำคัญหรือไม่ แต่คืองานพวกนี้ควรย้ายไปทำตอนไหน

อยากได้ผลลัพธ์แบบไหน ให้ย้ายไปทำตั้งแต่ก่อนเริ่มเขียนโค้ด

หลักการที่เธอบอกว่าได้เรียนรู้มาตั้งแต่ยุคแรกๆ ที่ Thoughtworks คือการทำให้วงจร feedback สั้นลง ถ้าความคิดเห็นและข้อเสนอแนะนั้นมีค่า อย่าตัดมันทิ้ง แต่ให้ย้ายไปอยู่ใกล้กับจุดที่ตัดสินใจจริงๆ พอนำหลักการนี้มาจับกับงานที่ code review เคยแบกไว้ เราจะเห็นว่าแต่ละอย่างมีที่ทางที่เหมาะสมกว่า

• ถ้าอยากสำรวจทางเลือกอื่น ให้คุยและลองตั้งแต่ตอนที่ยังไม่ได้เริ่มเขียน ไม่ใช่รอให้เขียนเสร็จแล้วค่อยมาบอกให้เปลี่ยน
• ถ้าอยากแชร์ความรู้ในทีม ให้ทำ pair programming หรือนั่งเขียนโค้ดชิ้นเดียวกันเป็นคู่ เพราะการได้นั่งคิดหาทางแก้ไปด้วยกันช่วยให้สอนกันได้มากกว่าการมานั่งอ่านโค้ดหลังอีกฝ่ายคิดหาทางแก้เสร็จแล้ว
• ถ้าอยากสอนงานรุ่นน้อง ให้เขาได้อยู่ร่วมในกระบวนการตั้งแต่ตอนเริ่มคิด ทั้งการจับคู่ทำงาน และ design session ที่ทั้งทีมยืนคุยหน้าไวท์บอร์ดร่วมกันก่อนลงมือเขียนโค้ดจริง รวมถึงก่อนสั่งให้ agent เริ่มเขียนด้วย
• ถ้าอยากให้ทีมเป็นเจ้าของระบบร่วมกัน ให้จัดทีมแบบที่คนในทีมร่วมกันสร้างและดูแลระบบ เช่น mob programming ที่ทั้งทีมช่วยกันทำโจทย์เดียว แทนที่จะรอให้ pull request ทำหน้าที่ประกาศว่าใครสร้างอะไรเสร็จไปแล้ว
• ถ้าอยากคุมสถาปัตยกรรมให้ไปทางเดียวกัน ให้ออกแบบร่วมกัน แล้วแปลงข้อจำกัดสำคัญเป็น fitness function โดยเขียนออกมาเป็นเงื่อนไขทางสถาปัตยกรรมที่เครื่องตรวจซ้ำได้เอง
• ถ้าอยากตรวจรูปแบบโค้ด กฎเกณฑ์ไวยากรณ์ หรือช่องโหว่ความปลอดภัยที่รู้จักหน้าตากันแล้ว ให้ส่งต่อให้ระบบอัตโนมัติจัดการทั้งหมด อะไรที่มีกฎเกณฑ์ตายตัวและเขียนเป็นแบบทดสอบได้ ไม่ควรต้องเปลืองเวลาคน เธอถึงกับย้ำว่าตอนนี้คือปี 2026 แล้ว เราไม่ควรต้องมานั่งเถียงกันเรื่องเว้นวรรคในโค้ดอีก

จุดร่วมของแนวทางทั้งหมดนี้คือ feedback มาเร็วขึ้น บางอย่างเกิดขึ้นตั้งแต่ยังไม่มีโค้ดให้อ่าน ส่วนบางอย่างใช้ตรวจระหว่างทางก่อนงานจะไปถึงคิวของคน วิธีทำงานอย่าง pair programming, trunk-based development, automated testing, static analysis, fitness function และ security scanning ล้วนอยู่ในกลุ่มนี้

agent เองก็เข้ามาช่วยในวงจรช่วงต้นเหล่านี้ได้เหมือนกัน ทั้งช่วยตั้งคำถามกับแบบที่วางไว้ ช่วยทดสอบสมมติฐาน หรือคอยตรวจสิ่งที่กำลังสร้างอยู่ตลอดเวลา แต่ความคิดจริงๆ ยังมาจากคนที่มีประสบการณ์ ซึ่งไปทางเดียวกับเรื่อง Citizens build, Agents execute, Experts govern ที่เคยเล่าไปก่อนหน้านี้

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

review by exception คือการตรวจเฉพาะเคสที่คุ้มกับเวลาที่คนต้องใช้จริงๆ

จุดที่ชวนสับสนที่สุดอยู่ที่ชื่อของมันเอง review by exception ไม่ได้แปลว่าจะไม่มีการตรวจโค้ดกันอีกต่อไป เธออธิบายว่ายังมีการแก้โค้ดบางแบบที่เธออยากให้คนที่มีประสบการณ์อีกคนมาช่วยอ่านแน่นอน สิ่งที่เปลี่ยนไปจริงๆ คือเราเลิกใช้กฎบังคับตรวจทุกชิ้นแบบเหมารวม แล้วเปลี่ยนมาตกลงกันในทีมว่ามีกรณีไหนบ้างที่คุ้มค่าจะใช้เวลาคนมาตรวจ เช่น

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

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

ข้อกังวลเรื่อง cognitive debt ที่เธอไม่ปัดทิ้ง

มีประเด็นหนึ่งจากฝั่งตรงข้ามที่เธอบอกว่าเป็นปัญหาจริง นั่นคือเรื่อง cognitive debt กับ intent debt หรือหนี้ทางความเข้าใจที่ทีมสะสมไว้ ซอฟต์แวร์เติบโตและซับซ้อนขึ้นเรื่อยๆ ขณะที่คนที่ต้องรับผิดชอบกลับเข้าใจน้อยลงเรื่อยๆ ว่าทำไมระบบถึงทำงานแบบนั้น เธอเห็นด้วยว่านี่เป็นเรื่องน่ากังวล เพียงแต่เธอไม่คิดว่าการบังคับให้ทุกอย่างผ่าน pull request จะเป็นเกราะที่แข็งแรงพอจะป้องกันได้

ถ้า agent จะเข้ามารับงานเขียนโค้ดมากขึ้นเรื่อยๆ สิ่งที่ทีมต้องตั้งใจทำมากกว่าเดิมคือการรักษาความเข้าใจในตัวระบบของคนในทีมเอาไว้ ผ่านการออกแบบร่วมกันตั้งแต่แรก · การจับคู่ทำงาน · การวางขอบเขตของระบบให้ชัดเจน · การทำสถาปัตยกรรมที่รันตรวจตัวเองได้ · และการร่วมกันรับผิดชอบตอนระบบขึ้นใช้งานจริง

เราต้องการวิศวกรที่เข้าใจทั้งระบบ ไม่ใช่เข้าใจแค่ diff ที่วางอยู่ตรงหน้า

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

ทีมที่กำลังชั่งใจเรื่องการจ้าง junior engineer ในยุคที่ AI เขียนโค้ดได้ จะเจอโจทย์นี้เร็วเป็นพิเศษ เพราะทั้งสองเรื่องขึ้นอยู่กับคำถามเดียวกัน นั่นคือความเข้าใจของคนในทีมเกิดขึ้นในขั้นตอนไหน

ธรรมเนียมปฏิบัติมักอยู่รอดได้นานกว่าเงื่อนไขที่เคยทำให้มันได้ผลเสมอ สิ่งที่ AI กำลังทำกับ code review จึงอาจเป็นแค่การบังคับให้เราต้องหาทางใหม่ไปให้ถึงเป้าหมายเดิมที่ยังสำคัญอยู่เท่าเดิม

---

ที่มา: บทความ Maybe We Shouldn't Be Reviewing All This Code จาก martinfowler.com