ตรวจสอบก่อนหรือหลังการส่งมอบรหัสซึ่งดีกว่า?

ตามเนื้อผ้าเราทำการตรวจสอบโค้ดก่อนส่งฉันมีข้อโต้แย้งกับเพื่อนร่วมงานของฉันในวันนี้ซึ่งต้องการตรวจสอบโค้ดหลังจากส่งมอบ

ก่อนอื่นนี่คือพื้นหลังบางส่วน

1. เรามีนักพัฒนาที่มีประสบการณ์และเรายังมีการจ้างงานใหม่ด้วยประสบการณ์การเขียนโปรแกรมเกือบเป็นศูนย์
2. เราต้องการทำซ้ำอย่างรวดเร็วและสั้นเพื่อเผยแพร่ผลิตภัณฑ์ของเรา
3. สมาชิกในทีมทั้งหมดอยู่ที่ไซต์เดียวกัน

ข้อดีของการตรวจสอบโค้ดก่อนส่งมอบฉันได้เรียนรู้:

1. ให้คำปรึกษาจ้างใหม่
2. พยายามป้องกันข้อผิดพลาดความล้มเหลวการออกแบบที่ไม่ดีในช่วงต้นของวงจรการพัฒนา
3. เรียนรู้จากผู้อื่น
4. การสำรองข้อมูลความรู้ถ้ามีคนเลิก

แต่ฉันก็มีประสบการณ์ที่ไม่ดีเช่นกัน:

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

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

UPDATE:

1. เรากำลังใช้ Perforce สำหรับ VCS
2. เราใช้รหัสและกระทำในสาขาเดียวกัน (สาขาการแก้ไขลำต้นหรือข้อบกพร่อง)
3. เพื่อปรับปรุงประสิทธิภาพเราได้พยายามแบ่งรหัสเป็นการเปลี่ยนแปลงเล็กน้อย เราได้ลองตรวจสอบการสนทนาสดแล้ว แต่ทุกคนไม่ปฏิบัติตามกฎ นี่เป็นปัญหาอีกอย่างหนึ่ง

เช่นเดียวกับSimon Whitehead ที่กล่าวถึงในความคิดเห็นของเขามันขึ้นอยู่กับกลยุทธ์การแยกสาขาของคุณ

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

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

มีมนต์ที่ยังไม่มีใครอ้างถึง: เช็คอินก่อนและมักจะ :

นักพัฒนาซอฟต์แวร์ที่ทำงานเป็นเวลานาน - และอีกต่อไปฉันหมายถึงมากกว่าหนึ่งวันโดยไม่ต้องตรวจสอบอะไรเลยในการควบคุมแหล่งที่มา เห็นด้วย Damon Poole :

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

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

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

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

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

นอกจากนี้ยังมีคำกล่าวของ Jeff Atwood: อย่ากลัวที่จะทำลายสิ่งต่าง ๆ :

วิธีที่ดีที่สุดในการพัฒนาในฐานะนักพัฒนาซอฟต์แวร์คือการไม่ต้องกลัวเมื่อเปลี่ยนรหัสของคุณ นักพัฒนาซอฟต์แวร์ที่กลัวรหัสที่เสียคือนักพัฒนาซอฟต์แวร์ที่จะไม่พัฒนาเป็นมืออาชีพ

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

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

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

สิ่งนี้จะเปลี่ยนผลการรับรู้ของการตรวจสอบโค้ดด้วย: มันถูกมองว่าเป็นสิ่งที่สร้างงานเพิ่มเติมเท่านั้นซึ่งตรงข้ามกับสิ่งที่ทุกคน (ผู้ตรวจทานและผู้เขียนรหัส) สามารถเรียนรู้สิ่งใหม่ทุกครั้ง

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

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

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

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

ทำทั้งสองอย่าง:

• ก่อนคอมมิชชัน - ทำบทวิจารณ์ชนิดนี้เมื่อมันเป็นสิ่งที่สำคัญมากเช่นชิ้นส่วนที่ใช้ซ้ำได้มากหรือการตัดสินใจออกแบบที่สำคัญ
• โพสต์กระทำ - ทำบทวิจารณ์ชนิดนี้เมื่อคุณต้องการรับความคิดเห็นเกี่ยวกับโค้ดที่อาจได้รับการปรับปรุง

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

นี่เป็นการหลีกเลี่ยงการขัดแย้งประเภท "คุณยังไม่มีไฟล์ล่าสุด" และทำให้ทุกคนตรวจทานสำเนาต้นฉบับของซอร์สโค้ดเดียวกัน

นอกจากนี้ยังหมายถึงว่าหากจำเป็นต้องมีการแก้ไขหลังการตรวจสอบใด ๆ ประวัติสามารถบันทึกย่อด้วยข้อเท็จจริงนั้น

สำหรับการตรวจสอบโค้ดนั้นการลงคะแนนของฉันมีไว้สำหรับ 'ระหว่าง' การกระทำ

ระบบเช่น gerrit หรือ clover (ฉันคิดว่า) สามารถจัดลำดับการเปลี่ยนแปลงได้และให้ผู้ตรวจทานส่งไปยังตัวควบคุมแหล่งที่มา (push in git) ถ้ามันดี นั่นคือสิ่งที่ดีที่สุดของทั้งสองโลก

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

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

ด้วยการตรวจสอบโดยเพื่อนมีความเสี่ยงน้อยที่สุดในการสูญเสียการควบคุม ตลอดเวลาที่คนสองคนมีความรู้เกี่ยวกับรหัสเดียวกัน พวกเขาต้องเปลี่ยนเป็นครั้งคราวดังนั้นพวกเขาจึงต้องใส่ใจตลอดเวลาเพื่อติดตามรหัส

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

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

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

ความคิดเห็นได้รับประโยชน์จากทั้งก่อนและหลัง

ตรวจสอบล่วงหน้า

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

ไม่มีข้อผูกพันใด ๆ ในระหว่างการตรวจสอบ

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

โพสต์รีวิวแก้ไข

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

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

โพสต์รีวิว

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

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

ตามบรรทัดเหล่านั้นการมีกระบวนการ CI ที่ดีและ / หรือการเช็คอินแบบ gated ช่วยลดความต้องการในการตรวจสอบก่อนที่จะส่งมอบ

ฉันและเพื่อนร่วมงานของฉันทำการวิจัยทางวิทยาศาสตร์เกี่ยวกับหัวข้อนี้เมื่อเร็ว ๆ นี้ดังนั้นฉันต้องการเพิ่มความเข้าใจของเราบางอย่างแม้ว่านี่จะเป็นคำถามที่ค่อนข้างเก่า เราสร้างแบบจำลองสถานการณ์ของกระบวนการพัฒนา / ทีม Kanban ที่คล่องตัวและเปรียบเทียบการคอมมิทล่วงหน้าและโพสต์การคอมเม้นท์สำหรับสถานการณ์ที่แตกต่างกันจำนวนมาก (จำนวนสมาชิกทีมที่แตกต่างกันระดับทักษะที่แตกต่างกัน ... ) เราดูผลลัพธ์หลังจาก 3 ปีของเวลาในการพัฒนา (จำลอง) และมองหาความแตกต่างเกี่ยวกับประสิทธิภาพ (คะแนนเรื่องราวที่เสร็จสมบูรณ์) คุณภาพ (ข้อบกพร่องที่พบโดยลูกค้า) และรอบเวลา (เวลาตั้งแต่เริ่มต้นจนถึงการส่งเรื่องผู้ใช้) . ผลการวิจัยของเรามีดังนี้:

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

จากสิ่งเหล่านี้เราได้รับกฎการแก้ปัญหาต่อไปนี้:

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

งานวิจัยฉบับเต็มมีอยู่ที่นี่: http://dx.doi.org/10.1145/2904354.2904362หรือบนเว็บไซต์ของฉัน: http://tobias-baum.de

ในความเห็นของฉันการตรวจสอบโค้ดเพียร์ทำงานได้ดีที่สุดถ้าทำการโพสต์เสร็จแล้ว

ฉันขอแนะนำให้ปรับกลยุทธ์การแยกสาขาของคุณ การใช้สาขานักพัฒนาซอฟต์แวร์หรือสาขาคุณลักษณะมีประโยชน์หลายประการ ... ไม่น้อยไปกว่านั้นเป็นการอำนวยความสะดวกในการตรวจสอบโค้ดหลังการส่ง

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

http://www.atlassian.com/software/crucible/overview

ประโยชน์อื่น ๆ ของสาขาผู้ใช้ / ฟีเจอร์:

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

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

ทั้งสอง (ประเภท)

คุณควรตรวจสอบรหัสของคุณเองอย่างย่อก่อนที่จะกระทำ ใน Git ฉันคิดว่าพื้นที่จัดเตรียมยอดเยี่ยม หลังจากที่ฉันจัดฉากการเปลี่ยนแปลงของฉันฉันวิ่งgit diff --cachedไปดูทุกอย่างที่เป็นฉาก ฉันใช้สิ่งนี้เป็นโอกาสในการตรวจสอบให้แน่ใจว่าฉันไม่ได้ตรวจสอบในไฟล์ใด ๆ ที่ไม่ได้เป็นของ (สร้างสิ่งประดิษฐ์บันทึก ฯลฯ ) และตรวจสอบให้แน่ใจว่าฉันไม่มีรหัสการแก้ปัญหาในนั้นหรือรหัสสำคัญใด ๆ ออก. (ถ้าฉันทำสิ่งที่ฉันรู้ว่าฉันไม่ต้องการเช็คอินฉันมักจะแสดงความคิดเห็นในตัวพิมพ์ใหญ่ทั้งหมดเพื่อให้ฉันจำได้ในระหว่างการจัดเตรียม)

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

หากคุณไม่ได้ทำงานในสาขาหัวข้อที่คุณควร มันช่วยลดความเครียดและความยุ่งยากและทำให้การวางแผนการปล่อยมีความยุ่งยากและซับซ้อนน้อยลง

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

การเขียนโปรแกรมจับคู่ 100% (ไม่ว่าคุณจะคิดว่าคุณเป็นคนอาวุโส) ด้วยความมุ่งมั่นเล็ก ๆ และระบบ CI ที่สร้างขึ้นจากการกระทำทุกอย่าง (ด้วยการทดสอบแบบอัตโนมัติ โพสต์การส่งคำวิจารณ์สำหรับการเปลี่ยนแปลงที่มีขนาดใหญ่หรือมีความเสี่ยง หากคุณต้องมีการตรวจทาน gated / pre-commit บางอย่าง Gerrit จะทำงานได้

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

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

สิ่งที่ทำให้สิ่งนี้ยากขึ้นคือนักพัฒนาซอฟต์แวร์ทุกคนไม่เหมือนกัน โซลูชั่นที่เรียบง่ายไม่ทำงานสำหรับโปรแกรมเมอร์ วิธีแก้ปัญหาง่าย ๆ คือ:

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

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

• รีวิวในการเช็คอินแต่ละครั้งซึ่งรับประกันความคิดเห็นบ่อยครั้ง นักพัฒนาบางคนลืมและพึ่งพาการเช็คอินบ่อยมากซึ่งหมายความว่าคนอื่น ๆ ต้องทำการตรวจสอบโค้ดทุก ๆ 15 นาที

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

ในทางปฏิบัติคุณทำให้งานนี้ทำได้ง่ายขึ้นและซับซ้อนขึ้นในเวลาเดียวกัน คุณกำหนดแนวทางง่าย ๆ และให้แต่ละทีมพัฒนาคิดเป็นทีมว่าพวกเขาต้องทำอะไรเพื่อปฏิบัติตามแนวทางเหล่านี้ ตัวอย่างของแนวทางดังกล่าวคือ:

• งานถูกแบ่งย่อยในงานที่ควรใช้เวลาน้อยกว่าหนึ่งวัน
• งานยังไม่เสร็จหากยังไม่ได้ตรวจสอบรหัส (ถ้ามี)
• งานยังไม่เสร็จหากรหัส (ถ้ามี) ยังไม่ได้รับการตรวจสอบ

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

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

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

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

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

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

การมีมนุษย์เข้ามาเกี่ยวข้องในกระบวนการอัตโนมัติควรเป็นสิ่งที่สิ้นเปลือง