Critique - วิธีที่ Google ลดความเจ็บปวดของการรีวิวโค้ดด้วยความพึงพอใจของนักพัฒนา 97%

xguru · 2023-12-11T10:32:02+09:00

อดีตพนักงาน Google จำนวนมากยังคงคิดถึงเครื่องมือรีวิวโค้ดของ Google ที่ชื่อว่า "Critique" จากผลสำรวจภายใน Google พบว่านักพัฒนา 97% พึงพอใจกับ Critique แนวทางการรีวิวโค้ดของ Google ส่งเสริมการปรับปรุงอย่างต่อเนื่องมากกว่าการมุ่งหาความสมบูรณ์แบบ รักษาสภาพของ codebase ให้คงเดิมหรือดีขึ้น ปฏิบัติตาม style guide แบ่งปันความรู้อยู่เสมอ: สนับสนุนการแบ่งปันความรู้เกี่ยวกับฟีเจอร์ของภาษา, codebase และอาร์ติแฟกต์ที่เกี่ยวข้องอื่น ๆ ผ่านการรีวิวโค้ด เขียนการเปลี่ยนแปลงให้มีขนาดเล็ก (ประมาณ 200 บรรทัด) มีมาตรฐานที่เข้มงวดเรื่องความเบาและรวดเร็ว (รีวิวการเปลี่ยนแปลงโค้ดภายใน 24 ชั่วโมง และถ้าเป็นไปได้ใช้ผู้รีวิวเพียงคนเดียว) ความสุภาพและความเป็นมืออาชีพ: การรักษาวัฒนธรรมแห่งความไว้วางใจและความเคารพเป็นสิ่งสำคัญ Critique: เครื่องมือรีวิวโค้ดของ Google ช่วยให้วิศวกรรีวิวการเปลี่ยนแปลงโค้ดและส่งขึ้นระบบได้อย่างมีประสิทธิภาพ จากบทความวิจัยล่าสุด - Resolving code review comments with ML ระบุว่าใช้งานเครื่องมือรีวิวโค้ดแบบครอบคลุมที่ขับเคลื่อนด้วย AI เมื่อผู้รีวิวทิ้งคอมเมนต์ไว้บนโค้ด Critique จะแสดงข้อเสนอการแก้ไขที่อิง ML ผู้เขียนโค้ดสามารถแก้ไขตามคอมเมนต์นั้นได้ทั้งชุดด้วยการกดปุ่มเพียงครั้งเดียว ขั้นตอนการรีวิวโค้ด ขั้นที่ 1: เขียนการเปลี่ยนแปลง CL (หรือ Pull Request) ถูกเขียนใน Cider ซึ่งเป็นตัวแก้ไขโค้ดภายในของ Google ทำงานร่วมกับ Critique และเครื่องมือภายในอื่น ๆ ของ Google อย่างใกล้ชิดเพื่อเพิ่มประสิทธิภาพการทำงานของนักพัฒนา เครื่องมือ Prereview: ช่วยเกลาการเปลี่ยนแปลงก่อนรีวิว และแสดง diff, ผลการ build และ test รวมถึงการตรวจสอบ style การดูและแสดงผล Diff: มี syntax highlighting, cross-reference, intraline diffing, การมองข้าม whitespace และการตรวจจับการย้ายโค้ด แสดงผลจาก static analyzer เพื่อเน้นผลลัพธ์สำคัญและเสนอแนวทางแก้ไข รวมถึง "presubmits" ซึ่งเป็นการทดสอบอัตโนมัติที่รันภายใน Critique ขั้นที่ 2: ขอรีวิว เมื่อ Pull Request พร้อมให้ตรวจ ผู้เขียนโค้ดจะเพิ่มผู้รีวิวและส่งเข้าสู่การรีวิวอย่างเป็นทางการ เมื่อส่ง PR/CL เพื่อรีวิวแล้ว หากยังไม่มีการรันกับ snapshot ของโค้ดปัจจุบัน ระบบจะรัน "Presubmits" ทำให้ทุกคนที่เกี่ยวข้องกับการรีวิวรู้ได้ว่ามีปัญหาในโค้ดหรือไม่ ยังสามารถทำให้การรีวิวโค้ดเป็นแบบไม่เปิดเผยตัวตนได้ เพื่อซ่อนตัวผู้เขียนโค้ดจากผู้รีวิว แต่ Google ไม่พบความแตกต่างที่มีประโยชน์ระหว่างการรีวิวแบบไม่เปิดเผยตัวตนกับการรีวิวโค้ดแบบ 'ปกติ' ขั้นที่ 3 และ 4: ทำความเข้าใจการเปลี่ยนแปลงและแสดงความเห็น ทุกคนสามารถแสดงความคิดเห็นต่อการเปลี่ยนแปลงได้ และมีความสามารถในการติดตามความคืบหน้าของการรีวิวและการจัดการคอมเมนต์ คอมเมนต์ที่ยังไม่ถูกแก้ไขหมายถึงรายการงานที่ผู้เขียนการเปลี่ยนแปลงต้องจัดการให้แน่ชัด คอมเมนต์เหล่านี้สามารถถูกทำเครื่องหมายว่า 'แก้ไขแล้ว' ได้เมื่อผู้เขียนโค้ดตอบกลับคอมเมนต์นั้นโดยตรง คอมเมนต์ที่ถูกแก้ไขแล้วอาจเป็นคอมเมนต์ทางเลือกหรือคอมเมนต์ให้ข้อมูลซึ่งไม่จำเป็นต้องให้ผู้เขียนดำเนินการ มีแดชบอร์ดสำหรับตรวจสอบสถานะการรีวิว และมี "Attention Set" ที่ทำให้ผู้มีส่วนร่วมในการรีวิวโค้ดแต่ละรายการรู้ได้ว่าตอนนี้กำลังรอใครอยู่ ขั้นที่ 5: อนุมัติการเปลี่ยนแปลง อย่างที่กล่าวไว้ข้างต้น การรีวิวจะถือว่าเสร็จสมบูรณ์ได้ก็ต่อเมื่อได้รับ LGTM (Looks Good To Me) จากผู้รีวิวอย่างน้อยหนึ่งคน แม้ผู้เขียนโค้ดจะสามารถทำเครื่องหมายคอมเมนต์ที่ตนจัดการเองว่าแก้ไขแล้วได้ แต่จำนวนคอมเมนต์ที่ยังไม่ถูกแก้ไขต้องเป็น 0 นอกจากนี้ยังต้องได้รับการอนุมัติจากเจ้าของส่วนของ codebase ที่โค้ดจะเข้าไปอยู่ และการอนุมัติด้าน readability ทั้งหมดนี้ผู้รีวิวเพียงคนเดียวก็สามารถดำเนินการได้ ขั้นที่ 6: commit การเปลี่ยนแปลง ส่งและ commit การเปลี่ยนแปลงได้จากภายใน Critique โดยตรง Critique ยังมีประโยชน์แม้หลังจากส่งการเปลี่ยนแปลงแล้ว "นักวิจัยของ Google พบหลักฐานชัดเจนว่าการใช้งาน Critique ขยายไปไกลกว่าการรีวิวโค้ด ผู้เขียนการเปลี่ยนแปลงใช้ Critique เพื่อตรวจดู diff และค้นหาผลลัพธ์จากเครื่องมือวิเคราะห์ ในบางกรณี การรีวิวโค้ดเป็นส่วนหนึ่งของกระบวนการพัฒนาการเปลี่ยนแปลง โดยผู้รีวิวอาจได้รับการเปลี่ยนแปลงที่ยังไม่เสร็จเพื่อช่วยตัดสินใจว่าจะทำ implementation ให้เสร็จอย่างไร นอกจากนี้ นักพัฒนายังใช้ Critique เพื่อตรวจดูประวัติของการเปลี่ยนแปลงที่ถูกส่งไปแล้วแม้หลังจากการเปลี่ยนแปลงนั้นจะได้รับอนุมัติ" สถิติการรีวิวโค้ดล่าสุดของ Google ความถี่ในการเขียนการเปลี่ยนแปลง: ค่ามัธยฐาน: เปลี่ยนแปลง 3 ครั้งต่อสัปดาห์ 80% ของผู้เขียนมีการเปลี่ยนแปลงน้อยกว่า 7 ครั้งต่อสัปดาห์ ความถี่ในการรีวิว: ค่ามัธยฐาน: รีวิวการเปลี่ยนแปลง 4 รายการต่อสัปดาห์ 80% ของผู้รีวิวจัดการการเปลี่ยนแปลงน้อยกว่า 10 รายการต่อสัปดาห์ เวลาที่ใช้กับการรีวิวต่อสัปดาห์: เฉลี่ย 3.2 ชั่วโมงต่อสัปดาห์ ค่ามัธยฐาน 2.6 ชั่วโมงต่อสัปดาห์ เวลารอ feedback แรกเริ่ม: การเปลี่ยนแปลงขนาดเล็ก: โดยเฉลี่ยน้อยกว่า 1 ชั่วโมง การเปลี่ยนแปลงขนาดใหญ่มาก: ประมาณ 5 ชั่วโมง เวลาของกระบวนการรีวิวทั้งหมด: ค่าเฉลี่ยของเวลาแฝงสำหรับทุกขนาดโค้ด: น้อยกว่า 4 ชั่วโมง เมื่อเทียบกับบริษัทอื่น: AMD: 17.5 ชั่วโมง (ค่ามัธยฐานของเวลาจนได้รับอนุมัติ) Chrome OS: 15.7 ชั่วโมง โปรเจกต์ของ Microsoft: 14.7 ชั่วโมง, 19.8 ชั่วโมง, 18.9 ชั่วโมง Microsoft (งานวิจัยอื่น): 24 ชั่วโมง ทำไมชาว Google ถึงรัก Critique? Static analysis: มีชุดเครื่องมือ static analysis ที่ครบถ้วน ซึ่งให้ feedback ที่นำไปลงมือแก้ไขได้โดยอัตโนมัติ ช่วยประหยัดเวลาให้ทั้งผู้เขียนโค้ดและผู้รีวิว และทำให้ผู้รีวิวไม่ต้องคอยชี้สิ่งที่ชัดเจนอยู่แล้วทีละจุด โฟกัสเฉพาะไฟล์ที่เพิ่งเปลี่ยนล่าสุด: สามารถโฟกัสได้เฉพาะ 'snapshot' ล่าสุดของโค้ดเท่านั้น โดยไม่แสดง snapshot, commit และการเปลี่ยนแปลงโค้ดก่อนหน้า ทำให้ UI สะอาดกว่า อินเทอร์เฟซ Side-by-Side Diff ที่คุ้นเคย: โดยปกติจะแสดง "ความต่างจากการรีวิวครั้งล่าสุด" ข้อเสนอที่ขับเคลื่อนด้วย machine learning: ฟีเจอร์ข้อเสนอแบบ ML ใหม่ของ Google ทำให้ความเร็วในการรีวิวโค้ดเพิ่มขึ้นอย่างมาก การทำงานร่วมกับเครื่องมืออื่นของ Google อย่างแนบแน่น: Critique เชื่อมต่อกับเครื่องมือภายในอื่น ๆ เช่น IDE และ bug tracker ของ Google ได้ดีมาก ทำให้ประสิทธิภาพการทำงานดีขึ้น ซึ่งรวมถึงการเชื่อมโค้ด คอมเมนต์ และ ticket เข้าด้วยกันได้อย่างง่ายดาย การติดตาม 'ชุดงาน': ช่วยให้รู้ว่าใครต้องเป็นคนดำเนินการขั้นต่อไป Gamification ที่น่าพึงพอใจ: แม้ Critique จะไม่ได้ถูกออกแบบมาให้เป็นเกม แต่ชาว Google บอกว่ารู้สึกสนุกเมื่อ Critique 'เปลี่ยนเป็นสีเขียว' และ PR พร้อมส่งแล้ว (ผ่านการทดสอบทั้งหมด และได้รับ LGTM จากผู้รีวิว) คอมเมนต์จาก Reddit คีย์ลัดบนคีย์บอร์ดที่ยอดเยี่ยมสำหรับรีวิวโค้ดจำนวนมากได้อย่างมีประสิทธิภาพสูง โดยปกติจะแสดง "แตกต่างจากการรีวิวครั้งล่าสุด" มีฟีเจอร์ "ตรวจจับการย้ายโค้ด" ที่ช่วยให้โฟกัสกับการเปลี่ยนแปลงของโค้ดได้ มีฟีเจอร์ที่ยอดเยี่ยมในการบอกว่าไม่ว่าจะเป็นผู้รีวิวหรือผู้เขียน ใครคือคนที่ต้องลงมือทำอะไรต่อ หากใช้ร่วมกับส่วนขยาย Chrome ก็จะรับการแจ้งเตือนได้ง่ายและตรวจดูคิวรีวิวได้ ภายในองค์กร ใคร ๆ ก็สามารถรันคิวรีกับข้อมูลการรีวิวโค้ดเพื่อเก็บ insight ได้ การเชื่อมโค้ดและคอมเมนต์เข้าด้วยกันแบบอัตโนมัติ (รวมถึง ticket และการย้าย/ลิงก์) สามารถดูการวิเคราะห์ ประวัติ และคอมเมนต์ของ PR ในรูปแบบตาราง ทำให้เข้าใจความคืบหน้าของ PR ที่มีโค้ดหลายรอบได้ง่ายขึ้นมาก คำศัพท์/แท็กของคอมเมนต์ เช่น ตัวเลือก ข้อสังเกต ฯลฯ มีความสอดคล้องกันมาก ความคิดและประเด็นที่น่าสนใจ แม้ว่าฟีเจอร์จำนวนมากเหล่านี้จะมีให้ใช้ในเครื่องมืออื่นในปัจจุบันแล้ว แต่เหตุผลที่เครื่องมือนี้เป็นที่รัก น่าจะมาจากการผสานเข้ากับ workflow และ codebase อันเป็นเอกลักษณ์ของ Google อย่างแนบแน่น รวมถึงความ 'ปรับให้เหมาะเฉพาะบุคคล' อย่างสูง ในขณะเดียวกัน นี่ก็หมายความว่าแทบเป็นไปไม่ได้ในทางปฏิบัติที่ทุกบริษัทจะทำซ้ำ Critique และเครื่องมือที่เกี่ยวข้องได้แบบตรงตัว เช่น เครื่องมือบางอย่างถูกออกแบบมาเฉพาะกับปัญหาที่เกิดจากโครงสร้าง monorepo แม้ Critique เองจะไม่ได้เปิดเป็นโอเพนซอร์ส แต่ Gerrit ก็เป็นเครื่องมือที่คล้ายกับ Critique ซึ่งเป็นเครื่องมือรีวิวโค้ดโอเพนซอร์สที่ Google สร้างและดูแลเช่นกัน แต่ก็คิดว่า Google ทุ่มเทความพยายามและความใส่ใจอย่างมากเพื่อ productivity ของนักพัฒนา พวกเขาเผยแพร่งานวิจัยของตนอย่างเสรี และเราสามารถดึงประเด็นที่มีประโยชน์จากงานของพวกเขาได้

(engineercodex.substack.com)

52 คะแนน โดย xguru 2023-12-11 | 5 ความคิดเห็น | แชร์ทาง WhatsApp

อดีตพนักงาน Google จำนวนมากยังคงคิดถึงเครื่องมือรีวิวโค้ดของ Google ที่ชื่อว่า "Critique"
จากผลสำรวจภายใน Google พบว่านักพัฒนา 97% พึงพอใจกับ Critique

แนวทางการรีวิวโค้ดของ Google

ส่งเสริมการปรับปรุงอย่างต่อเนื่องมากกว่าการมุ่งหาความสมบูรณ์แบบ
รักษาสภาพของ codebase ให้คงเดิมหรือดีขึ้น
ปฏิบัติตาม style guide
แบ่งปันความรู้อยู่เสมอ: สนับสนุนการแบ่งปันความรู้เกี่ยวกับฟีเจอร์ของภาษา, codebase และอาร์ติแฟกต์ที่เกี่ยวข้องอื่น ๆ ผ่านการรีวิวโค้ด
เขียนการเปลี่ยนแปลงให้มีขนาดเล็ก (ประมาณ 200 บรรทัด)
มีมาตรฐานที่เข้มงวดเรื่องความเบาและรวดเร็ว (รีวิวการเปลี่ยนแปลงโค้ดภายใน 24 ชั่วโมง และถ้าเป็นไปได้ใช้ผู้รีวิวเพียงคนเดียว)
ความสุภาพและความเป็นมืออาชีพ: การรักษาวัฒนธรรมแห่งความไว้วางใจและความเคารพเป็นสิ่งสำคัญ

Critique: เครื่องมือรีวิวโค้ดของ Google

ช่วยให้วิศวกรรีวิวการเปลี่ยนแปลงโค้ดและส่งขึ้นระบบได้อย่างมีประสิทธิภาพ
จากบทความวิจัยล่าสุด - Resolving code review comments with ML ระบุว่าใช้งานเครื่องมือรีวิวโค้ดแบบครอบคลุมที่ขับเคลื่อนด้วย AI
- เมื่อผู้รีวิวทิ้งคอมเมนต์ไว้บนโค้ด Critique จะแสดงข้อเสนอการแก้ไขที่อิง ML
- ผู้เขียนโค้ดสามารถแก้ไขตามคอมเมนต์นั้นได้ทั้งชุดด้วยการกดปุ่มเพียงครั้งเดียว

ขั้นตอนการรีวิวโค้ด

ขั้นที่ 1: เขียนการเปลี่ยนแปลง
- CL (หรือ Pull Request) ถูกเขียนใน Cider ซึ่งเป็นตัวแก้ไขโค้ดภายในของ Google
- ทำงานร่วมกับ Critique และเครื่องมือภายในอื่น ๆ ของ Google อย่างใกล้ชิดเพื่อเพิ่มประสิทธิภาพการทำงานของนักพัฒนา
- เครื่องมือ Prereview: ช่วยเกลาการเปลี่ยนแปลงก่อนรีวิว และแสดง diff, ผลการ build และ test รวมถึงการตรวจสอบ style
- การดูและแสดงผล Diff: มี syntax highlighting, cross-reference, intraline diffing, การมองข้าม whitespace และการตรวจจับการย้ายโค้ด
- แสดงผลจาก static analyzer เพื่อเน้นผลลัพธ์สำคัญและเสนอแนวทางแก้ไข รวมถึง "presubmits" ซึ่งเป็นการทดสอบอัตโนมัติที่รันภายใน Critique
ขั้นที่ 2: ขอรีวิว
- เมื่อ Pull Request พร้อมให้ตรวจ ผู้เขียนโค้ดจะเพิ่มผู้รีวิวและส่งเข้าสู่การรีวิวอย่างเป็นทางการ
- เมื่อส่ง PR/CL เพื่อรีวิวแล้ว หากยังไม่มีการรันกับ snapshot ของโค้ดปัจจุบัน ระบบจะรัน "Presubmits" ทำให้ทุกคนที่เกี่ยวข้องกับการรีวิวรู้ได้ว่ามีปัญหาในโค้ดหรือไม่
- ยังสามารถทำให้การรีวิวโค้ดเป็นแบบไม่เปิดเผยตัวตนได้ เพื่อซ่อนตัวผู้เขียนโค้ดจากผู้รีวิว แต่ Google ไม่พบความแตกต่างที่มีประโยชน์ระหว่างการรีวิวแบบไม่เปิดเผยตัวตนกับการรีวิวโค้ดแบบ 'ปกติ'
ขั้นที่ 3 และ 4: ทำความเข้าใจการเปลี่ยนแปลงและแสดงความเห็น
- ทุกคนสามารถแสดงความคิดเห็นต่อการเปลี่ยนแปลงได้ และมีความสามารถในการติดตามความคืบหน้าของการรีวิวและการจัดการคอมเมนต์
- คอมเมนต์ที่ยังไม่ถูกแก้ไขหมายถึงรายการงานที่ผู้เขียนการเปลี่ยนแปลงต้องจัดการให้แน่ชัด คอมเมนต์เหล่านี้สามารถถูกทำเครื่องหมายว่า 'แก้ไขแล้ว' ได้เมื่อผู้เขียนโค้ดตอบกลับคอมเมนต์นั้นโดยตรง
- คอมเมนต์ที่ถูกแก้ไขแล้วอาจเป็นคอมเมนต์ทางเลือกหรือคอมเมนต์ให้ข้อมูลซึ่งไม่จำเป็นต้องให้ผู้เขียนดำเนินการ
- มีแดชบอร์ดสำหรับตรวจสอบสถานะการรีวิว และมี "Attention Set" ที่ทำให้ผู้มีส่วนร่วมในการรีวิวโค้ดแต่ละรายการรู้ได้ว่าตอนนี้กำลังรอใครอยู่
ขั้นที่ 5: อนุมัติการเปลี่ยนแปลง
- อย่างที่กล่าวไว้ข้างต้น การรีวิวจะถือว่าเสร็จสมบูรณ์ได้ก็ต่อเมื่อได้รับ LGTM (Looks Good To Me) จากผู้รีวิวอย่างน้อยหนึ่งคน
- แม้ผู้เขียนโค้ดจะสามารถทำเครื่องหมายคอมเมนต์ที่ตนจัดการเองว่าแก้ไขแล้วได้ แต่จำนวนคอมเมนต์ที่ยังไม่ถูกแก้ไขต้องเป็น 0
- นอกจากนี้ยังต้องได้รับการอนุมัติจากเจ้าของส่วนของ codebase ที่โค้ดจะเข้าไปอยู่ และการอนุมัติด้าน readability
- ทั้งหมดนี้ผู้รีวิวเพียงคนเดียวก็สามารถดำเนินการได้
ขั้นที่ 6: commit การเปลี่ยนแปลง
- ส่งและ commit การเปลี่ยนแปลงได้จากภายใน Critique โดยตรง
- Critique ยังมีประโยชน์แม้หลังจากส่งการเปลี่ยนแปลงแล้ว
- "นักวิจัยของ Google พบหลักฐานชัดเจนว่าการใช้งาน Critique ขยายไปไกลกว่าการรีวิวโค้ด ผู้เขียนการเปลี่ยนแปลงใช้ Critique เพื่อตรวจดู diff และค้นหาผลลัพธ์จากเครื่องมือวิเคราะห์ ในบางกรณี การรีวิวโค้ดเป็นส่วนหนึ่งของกระบวนการพัฒนาการเปลี่ยนแปลง โดยผู้รีวิวอาจได้รับการเปลี่ยนแปลงที่ยังไม่เสร็จเพื่อช่วยตัดสินใจว่าจะทำ implementation ให้เสร็จอย่างไร นอกจากนี้ นักพัฒนายังใช้ Critique เพื่อตรวจดูประวัติของการเปลี่ยนแปลงที่ถูกส่งไปแล้วแม้หลังจากการเปลี่ยนแปลงนั้นจะได้รับอนุมัติ"

สถิติการรีวิวโค้ดล่าสุดของ Google

ความถี่ในการเขียนการเปลี่ยนแปลง:
- ค่ามัธยฐาน: เปลี่ยนแปลง 3 ครั้งต่อสัปดาห์
- 80% ของผู้เขียนมีการเปลี่ยนแปลงน้อยกว่า 7 ครั้งต่อสัปดาห์
ความถี่ในการรีวิว:
- ค่ามัธยฐาน: รีวิวการเปลี่ยนแปลง 4 รายการต่อสัปดาห์
- 80% ของผู้รีวิวจัดการการเปลี่ยนแปลงน้อยกว่า 10 รายการต่อสัปดาห์
เวลาที่ใช้กับการรีวิวต่อสัปดาห์:
- เฉลี่ย 3.2 ชั่วโมงต่อสัปดาห์
- ค่ามัธยฐาน 2.6 ชั่วโมงต่อสัปดาห์
เวลารอ feedback แรกเริ่ม:
- การเปลี่ยนแปลงขนาดเล็ก: โดยเฉลี่ยน้อยกว่า 1 ชั่วโมง
- การเปลี่ยนแปลงขนาดใหญ่มาก: ประมาณ 5 ชั่วโมง
เวลาของกระบวนการรีวิวทั้งหมด:
- ค่าเฉลี่ยของเวลาแฝงสำหรับทุกขนาดโค้ด: น้อยกว่า 4 ชั่วโมง
- เมื่อเทียบกับบริษัทอื่น:
  - AMD: 17.5 ชั่วโมง (ค่ามัธยฐานของเวลาจนได้รับอนุมัติ)
  - Chrome OS: 15.7 ชั่วโมง
  - โปรเจกต์ของ Microsoft: 14.7 ชั่วโมง, 19.8 ชั่วโมง, 18.9 ชั่วโมง
  - Microsoft (งานวิจัยอื่น): 24 ชั่วโมง

ทำไมชาว Google ถึงรัก Critique?

Static analysis: มีชุดเครื่องมือ static analysis ที่ครบถ้วน ซึ่งให้ feedback ที่นำไปลงมือแก้ไขได้โดยอัตโนมัติ ช่วยประหยัดเวลาให้ทั้งผู้เขียนโค้ดและผู้รีวิว และทำให้ผู้รีวิวไม่ต้องคอยชี้สิ่งที่ชัดเจนอยู่แล้วทีละจุด
โฟกัสเฉพาะไฟล์ที่เพิ่งเปลี่ยนล่าสุด: สามารถโฟกัสได้เฉพาะ 'snapshot' ล่าสุดของโค้ดเท่านั้น โดยไม่แสดง snapshot, commit และการเปลี่ยนแปลงโค้ดก่อนหน้า ทำให้ UI สะอาดกว่า
อินเทอร์เฟซ Side-by-Side Diff ที่คุ้นเคย: โดยปกติจะแสดง "ความต่างจากการรีวิวครั้งล่าสุด"
ข้อเสนอที่ขับเคลื่อนด้วย machine learning: ฟีเจอร์ข้อเสนอแบบ ML ใหม่ของ Google ทำให้ความเร็วในการรีวิวโค้ดเพิ่มขึ้นอย่างมาก
การทำงานร่วมกับเครื่องมืออื่นของ Google อย่างแนบแน่น: Critique เชื่อมต่อกับเครื่องมือภายในอื่น ๆ เช่น IDE และ bug tracker ของ Google ได้ดีมาก ทำให้ประสิทธิภาพการทำงานดีขึ้น ซึ่งรวมถึงการเชื่อมโค้ด คอมเมนต์ และ ticket เข้าด้วยกันได้อย่างง่ายดาย
การติดตาม 'ชุดงาน': ช่วยให้รู้ว่าใครต้องเป็นคนดำเนินการขั้นต่อไป
Gamification ที่น่าพึงพอใจ: แม้ Critique จะไม่ได้ถูกออกแบบมาให้เป็นเกม แต่ชาว Google บอกว่ารู้สึกสนุกเมื่อ Critique 'เปลี่ยนเป็นสีเขียว' และ PR พร้อมส่งแล้ว (ผ่านการทดสอบทั้งหมด และได้รับ LGTM จากผู้รีวิว)
คอมเมนต์จาก Reddit
- คีย์ลัดบนคีย์บอร์ดที่ยอดเยี่ยมสำหรับรีวิวโค้ดจำนวนมากได้อย่างมีประสิทธิภาพสูง
- โดยปกติจะแสดง "แตกต่างจากการรีวิวครั้งล่าสุด"
- มีฟีเจอร์ "ตรวจจับการย้ายโค้ด" ที่ช่วยให้โฟกัสกับการเปลี่ยนแปลงของโค้ดได้
- มีฟีเจอร์ที่ยอดเยี่ยมในการบอกว่าไม่ว่าจะเป็นผู้รีวิวหรือผู้เขียน ใครคือคนที่ต้องลงมือทำอะไรต่อ
- หากใช้ร่วมกับส่วนขยาย Chrome ก็จะรับการแจ้งเตือนได้ง่ายและตรวจดูคิวรีวิวได้
- ภายในองค์กร ใคร ๆ ก็สามารถรันคิวรีกับข้อมูลการรีวิวโค้ดเพื่อเก็บ insight ได้
- การเชื่อมโค้ดและคอมเมนต์เข้าด้วยกันแบบอัตโนมัติ (รวมถึง ticket และการย้าย/ลิงก์)
- สามารถดูการวิเคราะห์ ประวัติ และคอมเมนต์ของ PR ในรูปแบบตาราง ทำให้เข้าใจความคืบหน้าของ PR ที่มีโค้ดหลายรอบได้ง่ายขึ้นมาก
- คำศัพท์/แท็กของคอมเมนต์ เช่น ตัวเลือก ข้อสังเกต ฯลฯ มีความสอดคล้องกันมาก

ความคิดและประเด็นที่น่าสนใจ

แม้ว่าฟีเจอร์จำนวนมากเหล่านี้จะมีให้ใช้ในเครื่องมืออื่นในปัจจุบันแล้ว แต่เหตุผลที่เครื่องมือนี้เป็นที่รัก น่าจะมาจากการผสานเข้ากับ workflow และ codebase อันเป็นเอกลักษณ์ของ Google อย่างแนบแน่น รวมถึงความ 'ปรับให้เหมาะเฉพาะบุคคล' อย่างสูง
ในขณะเดียวกัน นี่ก็หมายความว่าแทบเป็นไปไม่ได้ในทางปฏิบัติที่ทุกบริษัทจะทำซ้ำ Critique และเครื่องมือที่เกี่ยวข้องได้แบบตรงตัว เช่น เครื่องมือบางอย่างถูกออกแบบมาเฉพาะกับปัญหาที่เกิดจากโครงสร้าง monorepo
แม้ Critique เองจะไม่ได้เปิดเป็นโอเพนซอร์ส แต่ Gerrit ก็เป็นเครื่องมือที่คล้ายกับ Critique ซึ่งเป็นเครื่องมือรีวิวโค้ดโอเพนซอร์สที่ Google สร้างและดูแลเช่นกัน
แต่ก็คิดว่า Google ทุ่มเทความพยายามและความใส่ใจอย่างมากเพื่อ productivity ของนักพัฒนา พวกเขาเผยแพร่งานวิจัยของตนอย่างเสรี และเราสามารถดึงประเด็นที่มีประโยชน์จากงานของพวกเขาได้

5 ความคิดเห็น

xguru 2023-12-17

ดูเหมือนว่าจะมีความพยายามนำ ChatGPT ไปผูกเข้ากับ Gerrit อยู่เหมือนกัน
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

kkweon 2023-12-12

สิ่งที่รู้สึกได้ชัดที่สุดคือใน Critique สามารถรีวิว CL ที่ต่อเนื่องกันเป็นลำดับได้ครับ ใน GitHub การที่ไม่รองรับ PR chain โดยตรงนี่ค่อนข้างไม่สะดวก เลยต้องกลายเป็น PR ใหญ่ก้อนเดียว หรือไม่ก็ต้องรอให้ PR ก่อนหน้าถูก merge ก่อนครับ

tested 2023-12-11

GitHub ก็มีอะไรคล้าย ๆ กันอยู่เหมือนกัน ไม่รู้ว่าจะเปิดให้ใช้งานเมื่อไหร่
> https://githubnext.com/projects/copilot-for-pull-requests

winterjung 2023-12-11

แม้จะไม่มีการวิเคราะห์แบบสถิตและข้อเสนอแนะที่อิงกับ ML แต่พออ่านบทความแล้วก็รู้สึกว่าคล้ายกับฟังก์ชันรีวิวของ GitHub มากเลยนะครับ ในฐานะคนที่ใช้ GitHub review บ่อย ๆ ก็หวังว่าจะมีการนำฟังก์ชันอื่น ๆ ที่ Critique มีมาเพิ่มอีกครับ

xguru 2023-12-11

คู่มือ Code Review ของ Google [แปลเกาหลี]