การทบทวน Peer / Code ผิดหวัง

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

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

ฉันมักจะเห็นความเห็นทบทวนเพื่อนร่วมงานจากเพื่อนร่วมงานเดียวกันเช่น -

• คงจะเป็นการดีถ้าจะเพิ่มช่องว่างหลังจากนั้น <INSERT SOMETHING HERE>
• บรรทัดที่ไม่ต้องการพิเศษระหว่างเมธอด
• ควรใช้การหยุดแบบเต็มเมื่อสิ้นสุดความคิดเห็นใน docblock

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

• คุณสามารถลดความซับซ้อนของวัฏจักรโดย ...
• ออกจากต้นและหลีกเลี่ยงถ้า / อื่น
• สรุปแบบสอบถาม DB ของคุณไปยังที่เก็บ
• ตรรกะนี้ไม่ได้อยู่ที่นี่จริงๆ
• อย่าทำซ้ำตัวเอง - นามธรรมและนำมาใช้ใหม่
• อะไรจะเกิดขึ้นถ้าXถูกส่งผ่านเป็นอาร์กิวเมนต์วิธีY?
• การทดสอบหน่วยสำหรับสิ่งนี้อยู่ที่ไหน

ฉันพบว่าเป็นคนประเภทเดียวกันที่ให้ความเห็นประเภทเครื่องสำอางและผู้คนประเภทเดียวกันซึ่งในความคิดเห็นของฉันให้ความเห็นแบบ "Quality & Logic"

อะไรคือวิธีที่ถูกต้องในการตรวจสอบโดยเพื่อน และฉันถูกต้องในการผิดหวังกับคนเดียวกันโดยทั่วไป skimming ผ่านรหัสที่กำลังมองหาข้อผิดพลาดการสะกด & ข้อบกพร่องด้านความงามมากกว่าข้อบกพร่องรหัสจริงหรือไม่

ถ้าฉันถูกต้อง - ฉันจะให้กำลังใจเพื่อนร่วมงานให้มองหาข้อบกพร่องในรหัสอย่างสมดุลได้อย่างไรด้วยการแนะนำการใช้เครื่องสำอาง

ถ้าฉันไม่ถูกต้อง - โปรดสอนฉัน มีกฎง่ายๆสำหรับสิ่งที่ถือเป็นการตรวจสอบรหัสที่ดีจริง ๆ ? ฉันพลาดจุดตรวจสอบโค้ดแล้วหรือยัง

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

เมื่อฉันตรวจสอบรหัสฉันอาจใช้เวลาประมาณ 15-45 นาทีต่อ 500 Loc ฉันไม่สามารถจินตนาการความเห็นตื้น ๆ เหล่านี้ใช้เวลานานกว่า 10 นาทีเลยทีเดียวหากนั่นเป็นความคิดเห็นเชิงลึกที่พวกเขากำลังแสดง นอกจากนี้นิ้วหัวแม่มือขึ้นจากผู้ตรวจสอบตื้นคืออะไร? แน่นอนนี่หมายความว่านิ้วหัวแม่มือทั้งหมดไม่ได้มีน้ำหนักเท่ากันและจำเป็นต้องมีกระบวนการตรวจสอบแบบ 2 รอบ หนึ่งนิ้วหัวแม่มือสำหรับความคิดเห็นที่ลึกและนิ้วหัวแม่มือที่สองสำหรับ "ขัด"?

ประเภทของความคิดเห็น

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

ประเภทของผู้ตรวจสอบ

เช่นเดียวกับที่เรามีเกณฑ์การตัดสินซอฟต์แวร์ที่แตกต่างกันคนที่ทำการตัดสินก็แตกต่างกัน เราทุกคนมีทักษะและความชอบของเราเอง บางคนอาจคิดว่าการปฏิบัติตามมาตรฐานท้องถิ่นมีความสำคัญอย่างยิ่งเช่นเดียวกับที่คนอื่นอาจเกี่ยวข้องกับการใช้หน่วยความจำหรือการครอบคลุมโค้ดของการทดสอบของคุณและอื่น ๆ คุณต้องการบทวิจารณ์ทุกประเภทเหล่านี้เพราะโดยรวมแล้วจะช่วยให้คุณเขียนโค้ดได้ดีขึ้น

การตรวจสอบโดยเพื่อนคือการทำงานร่วมกันไม่ใช่เกมของแท็ก

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

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

คำแนะนำ

ในตอนท้ายของคำถามที่คุณเขียน:

ฉันจะส่งเสริมให้เพื่อนร่วมงานมองหาข้อบกพร่องในรหัสอย่างสมดุลโดยมีข้อผิดพลาดเกี่ยวกับสุนทรียศาสตร์ที่ชัดเจนได้อย่างไร

อีกครั้งคำตอบคือการสื่อสาร บางทีคุณอาจถามพวกเขาว่า "เฮ้ฉันขอขอบคุณที่คุณจับข้อผิดพลาดเหล่านี้มันจะช่วยฉันได้อย่างมากถ้าคุณสามารถมุ่งเน้นไปที่ปัญหาที่ลึกกว่าเช่นว่าฉันกำลังจัดโครงสร้างรหัสของฉันถูกต้องหรือไม่ ช่วยด้วย."

ในบันทึกที่ใช้งานได้จริงฉันแบ่งความคิดเห็นเกี่ยวกับโค้ดออกเป็นสองค่ายและวลีเหล่านั้นอย่างเหมาะสม: สิ่งที่ต้องแก้ไขและสิ่งที่เป็นเครื่องสำอางมากกว่า ฉันจะไม่ป้องกันรหัสที่ทำงานไม่ทำงานเมื่อเช็คอินหากมีบรรทัดว่างมากเกินไปในตอนท้ายของไฟล์ ฉันจะชี้ให้เห็น แต่ฉันจะทำเช่นนั้นกับ "แนวทางของเราบอกว่าจะมีบรรทัดว่างเปล่าในตอนท้ายและคุณมี 20. มันไม่ใช่ show-stop แต่ถ้าคุณมีโอกาสคุณ อาจต้องการแก้ไข "

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

จะทำอย่างไรหลังจากการตรวจสอบ

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

ผู้คนแสดงความคิดเห็นเกี่ยวกับการจัดรูปแบบโค้ดและการพิมพ์ผิดเพราะง่ายต่อการมองเห็นและไม่ต้องการความพยายามมาก

ส่วนนี้เป็นเรื่องง่ายที่จะแก้ไข - เกือบทุกภาษามีเครื่องมือตรวจสอบ linter หรือ style ปลั๊กอินในกระบวนการสร้างของคุณดังนั้นมันจะล้มเหลวในการสร้างหากมีพื้นที่ซ้ำซ้อน ดังนั้นจะไม่มีปัญหาเกี่ยวกับสไตล์ที่จะแสดงความคิดเห็น

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

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

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

นี่คือคำตอบที่ใช้งานได้จริง:

สถานการณ์ที่ 1 : คุณเป็นสมาชิกอาวุโสและผู้ที่สามารถตัดสินใจได้

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

สถานการณ์ที่ 2 : คุณไม่ใช่คนที่ตัดสินใจฝึกหรือคุณเป็นสมาชิกในทีม

ทางออกที่ดีที่สุดของคุณเป็นเพียงการแก้ไขปัญหาการตรวจสอบรหัสจนกว่าคุณจะจัดการเพื่อเข้าถึงสถานการณ์ 1

คำตอบง่ายๆในการป้องกันความคิดเห็นการทบทวนรหัส "เล็กน้อย" คือการยืนยัน (เพื่อประสิทธิภาพ) เพื่อให้ผู้ตรวจสอบควรเป็นผู้แก้ไข ดังนั้นหากผู้ตรวจสอบพบว่าคุณ (สยองขวัญ!) พลาด fullstop หรือสะกดความคิดเห็นผิดพวกเขาควรแก้ไขและดำเนินการต่อ

จากประสบการณ์ของฉันนี่หมายความว่า:

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

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

ตรวจสอบกระบวนการตรวจสอบ

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

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

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

ในฐานะที่เป็นคนที่อยู่ทั้งสองด้านของนี้ (การตรวจสอบโค้ดที่เขียนโดยผู้อื่นรวมถึงการเขียนโค้ดที่ฉันเขียนไว้) ฉันจะบอกว่าฉันมีข้อเสนอแนะสามหมวดหมู่ สี่ยังมีกรณีที่น่ายินดีของ "ทุกอย่างดี"

"จะดี แต่จะไม่ปิดกั้นคุณ" (หากข้อเสนอแนะทั้งหมดตกอยู่ในหมวดหมู่นี้ฉันอาจส่งคำขอรวมกับ "จะรวมที่ XX: XX เว้นแต่คุณจะบอกฉันว่าคุณต้องการแก้ไข" หรือ "แน่นอนไปข้างหน้าเพื่อตรวจสอบในสิ่งที่บล็อกระบบจะโยนถูกปิดใช้งาน"):

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

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

• สิ่งที่เล็ก ๆ น้อย ๆ ("คุณกำลังเปรียบเทียบบูลีนกับtrueนั่นเป็นบิตหวาดระแวง ... ", ... )
• การละเมิดสไตล์ไมเนอร์ ("คู่มือสไตล์บอกว่า X สิ่งที่คุณทำอยู่นอกนั้นฉันจะทำ Y หรือ Z ขึ้นอยู่กับว่าคุณต้องการไปทางไหน")
• กรณีทดสอบที่หายไปสองสามอย่างซึ่งไม่ควรเขียนยาก

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

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

ดูเหมือนว่าบางคนลืมคำถามที่สำคัญที่สุด: คุณต้องการได้อะไรจากการตรวจสอบโค้ด

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

หากคุณเห็นว่ากระบวนการตรวจสอบเป็นโอกาสที่จะวางเพื่อนร่วมงานของคุณหรือสร้างงานให้พวกเขาแสดงว่าคุณทำผิด