การตรวจสอบรหัสที่ใช้ความเห็นโค้ดเป็นความคิดที่ดีหรือไม่

ปัจจัยพื้นฐาน

• ทีมใช้ DVCS
• IDE รองรับการแยกวิเคราะห์ความคิดเห็น (เช่นสิ่งที่ต้องทำและอื่น ๆ )
• เครื่องมือเช่น CodeCollaborator มีราคาแพงสำหรับงบประมาณ
• เครื่องมือเช่น gerrit นั้นซับซ้อนเกินไปสำหรับการติดตั้งหรือไม่สามารถใช้งานได้

ขั้นตอนการทำงาน

• ผู้เขียนเผยแพร่บางแห่งในสาขาฟีเจอร์ repo กลาง
• ผู้ตรวจทานดึงข้อมูลและเริ่มตรวจสอบ

• ในกรณีที่ผู้ตรวจสอบคำถาม / ปัญหาสร้างความคิดเห็นด้วยป้ายกำกับพิเศษเช่น "REV" ป้ายกำกับดังกล่าวต้องไม่อยู่ในรหัสการผลิต - เฉพาะในขั้นตอนการตรวจสอบ:

  $somevar = 123;
  // REV Why do echo this here?
  echo $somevar;
  

• เมื่อผู้ตรวจทานโพสต์ความคิดเห็นเสร็จ - เพียงแค่คอมเม้นต์ด้วยข้อความ "ความคิดเห็น" ที่งี่เง่าและดันกลับมา

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

การสนับสนุน IDE

ฉันรู้ว่าแท็กความคิดเห็นที่กำหนดเองนั้นเป็นไปได้ใน eclipse & netbeans แน่นอนว่ามันควรจะอยู่ในครอบครัว blablaStorm

คำถาม

1. คุณคิดว่าวิธีการนี้เป็นไปได้หรือไม่?
2. คุณรู้อะไรที่คล้ายกันไหม
3. สิ่งที่สามารถปรับปรุงได้

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

ยังมีข้อเสียอยู่เล็กน้อย:

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

• ฉันไม่เชื่อว่าผู้ตรวจสอบมีข้อเสนอแนะเพียงพอจากผู้ตรวจสอบเพื่อทราบว่ามีการใช้คะแนนที่ได้รับการตรวจสอบจริงอย่างไร

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

  Alice แนะนำไวยากรณ์ทางเลือกและส่งรหัสกลับไปที่ Eric เขาเขียนรหัสใหม่โดยใช้ไวยากรณ์ทางเลือกนี้ซึ่งเขาเชื่อว่าเข้าใจอย่างถูกต้องและลบ// BLAความคิดเห็นที่เกี่ยวข้อง

  ในสัปดาห์หน้าเธอได้รับรหัสสำหรับการตรวจสอบครั้งที่สอง เธอจะสามารถจำได้จริงหรือไม่ว่าเธอได้ทำคำพูดนี้ในระหว่างการตรวจสอบครั้งแรกของเธอเพื่อดูว่า Eric แก้ไขได้อย่างไร?

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

• ผู้คนยังคงเป็นคน ผมค่อนข้างมั่นใจว่าบางส่วนของความคิดเห็นเหล่านั้นจะสิ้นสุดในรหัสการผลิตและบางส่วนจะยังคงเป็นขยะในขณะที่กำลังล้าสมัยสมบูรณ์

  แน่นอนปัญหาเดียวกันอยู่กับความคิดเห็นอื่น ๆ ; ตัวอย่างเช่นมีความคิดเห็นสิ่งที่ต้องทำมากมายในการผลิต (รวมถึงสิ่งที่มีประโยชน์มากที่สุด: "สิ่งที่ต้องทำ: แสดงความคิดเห็นรหัสด้านล่าง") และความคิดเห็นจำนวนมากที่ไม่ได้รับการปรับปรุงเมื่อรหัสที่สอดคล้องกัน

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

• สิ่งนี้ไม่ได้แทนที่การตรวจสอบแบบเห็นหน้ากัน (แต่ปัญหาเดียวกันนี้นำไปใช้กับการทบทวนอย่างเป็นทางการอื่น ๆ ที่ไม่ได้ทำแบบตัวต่อตัว)

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

• คุณอาจพบปัญหาเล็กน้อยเกี่ยวกับไวยากรณ์ (ซึ่งมีอยู่สำหรับความคิดเห็น TODO) ตัวอย่างเช่นถ้าความคิดเห็น "// BLA" ที่ยาววางไข่ในหลายบรรทัดและบางคนตัดสินใจที่จะเขียนด้วยวิธีนี้:

  // BLA This is a very long comment which is way beyond 80 characters, so it actually
  // fills more then one line. Since the next lines start with slashes, but not "BLA"
  // keyword, the IDE may not be able to show those lines, and display only the first one.
  

• และสุดท้ายเป็นบันทึกย่อและเป็นส่วนตัวมาก: อย่าเลือก "BLA" เป็นคำหลัก มันฟังดูน่าเกลียด ;)

ฉันจะเสริมความคิดเห็นในรหัสด้วยเอกสารที่เป็นคู่หู สิ่งนี้จะสรุปผลการวิจัยและดำเนินการต่อหลังจากความคิดเห็นถูกนำออกไป ข้อดีของสิ่งนี้คือ:

• ความเป็นปึกแผ่น หากบุคคลนั้นล้มเหลวในการตรวจสอบว่าตัวชี้ที่ส่งผ่านนั้นไม่ว่างเปล่า (หรือข้อผิดพลาดทั่วไปสำหรับผู้เริ่มต้นทั่วไปในภาษาที่คุณใช้) ผู้ตรวจสอบสามารถแสดงความคิดเห็น REV หลายสิบครั้งเพื่อผลกระทบนั้นและในเอกสารสามารถพูดว่า " ฉันพบสถานที่ 37 แห่งที่ไม่ได้ตรวจสอบพอยน์เตอร์แรก "โดยไม่แสดงรายการทั้งหมด
• สถานที่สำหรับการสรรเสริญ ความคิดเห็นที่REV this is a nice designดูเหมือนจะแปลก แต่รีวิวรหัสของฉันมักจะรวมถึงการอนุมัติและการแก้ไข
• การติดต่อสื่อสาร ความคิดเห็นตัวอย่างของคุณคือ "ทำไมคุณถึงทำเช่นนี้?" และมันก็เป็นเรื่องธรรมดามาก วิธีการแสดงความคิดเห็นอย่างเดียวไม่รองรับการสนทนา บุคคลนั้นสามารถเปลี่ยนรหัสและลบความคิดเห็นหรือลบความคิดเห็นได้ แต่ "ทำไมคุณถึงทำเช่นนี้?" และ "โปรดเปลี่ยนสิ่งนี้มันผิด" ไม่เหมือนกัน
• เก็บบันทึก ผู้ตรวจสอบในภายหลังสามารถตรวจสอบว่ามีการเปลี่ยนแปลงรหัสจริงหรือความคิดเห็นเพิ่งถูกลบออก พวกเขายังสามารถตรวจสอบได้ว่ามีการแสดงความคิดเห็น "นำขึ้นบอร์ด" และนักพัฒนาไม่ได้ทำผิดพลาดเหมือนกันในการตรวจสอบภายหลัง

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

คนอื่นพูดถึงข้อ จำกัด ของวิธีการนี้ คุณพูดถึงว่าเครื่องมืออย่าง gerrit นั้นติดตั้งยากฉันขอแนะนำให้คุณดูที่ phabricator (http://www.phabricator.com) นี่คือระบบตรวจสอบรหัสที่ Facebook ใช้มานานหลายปีและเพิ่งเปิดแหล่งที่มา การติดตั้งมันไม่ยากมีเวิร์กโฟลว์ที่ยอดเยี่ยมและแก้ไขปัญหาทั้งหมดที่กล่าวถึงในความคิดเห็นอื่น