บริษัท ที่ฉันทำงานเพื่อขอรหัสทั้งหมดจะต้องได้รับการตรวจสอบโดยผู้พัฒนารายอื่นก่อนที่จะส่งมอบ สมาชิกในทีมของฉันมักจะหงุดหงิดเพราะนักพัฒนาคนอื่นเขียนโค้ดไม่ว่างเกินกว่าจะทำการตรวจสอบโดยเฉพาะถ้ามันยาวมาก คุณสร้างแรงจูงใจให้นักพัฒนารายอื่นทำรีวิวรหัสทันเวลาได้อย่างไร
(เราใช้ git-svn เพื่อให้เราสามารถเขียนโค้ดต่อไปได้ในขณะที่รอการตรวจสอบอย่างไรก็ตามฉันยังพบว่ามันน่าผิดหวังเมื่อฉันต้องรอเป็นเวลานานก่อนที่ฉันจะสามารถส่งรหัสได้)
คำตอบ:
ดูวิธีที่ Facebook ใช้กับแอพของตัวเองที่ชื่อว่า phabricator: http://phabricator.org/
พวกเขากระทำโดยพื้นฐานต่อปัญหาและสำหรับแต่ละปัญหารหัสจะแสดงซึ่งจะต้องมีการตรวจสอบโดยใครบางคน รหัสไม่ได้เข้าไปในพื้นที่เก็บข้อมูลหลักจนกว่าผู้ตรวจทานจะบอกว่าทำได้
ฉันเดาว่ามันทำให้สนุกมากขึ้น
นอกจากนี้อาจมีการกำหนดรหัสให้กับคนสองคน: ผู้ทำและผู้วิจารณ์
แม้ว่าเพื่อนร่วมทีมของคุณอาจไม่เชื่อในรีวิวนี้เลย
ส่วนตัวผมขาดการตรวจสอบฉันใช้การทดสอบหน่วยสำหรับฟังก์ชั่นระดับต่ำและ "การทดสอบภารโรง" สำหรับส่วนที่เหลือทั้งหมด: การทดสอบภารโรงเรียกว่าเป็นอย่างนั้นเพราะแม้แต่ภารโรงก็สามารถเข้าใจรหัสของคุณได้
ฉันมักจะลบบางส่วนเล็กน้อยเช่นวงเล็บขอบเขตบล็อก / ฟังก์ชั่นสัญกรณ์การมองเห็นบางครั้งก็พิมพ์และแสดงให้ผู้จัดการผู้จัดการผู้เชี่ยวชาญโดเมนเพื่อนร่วมใครก็ตามที่ขอรหัส: "นี่คือสิ่งที่คุณต้องการ?"
นอกจากนี้การไปที่นั่นเป็นการส่วนตัวและอย่าออกไปจนกว่าการตรวจสอบเสร็จสิ้นจะช่วยได้
หรือในกรณีที่คุณไม่ได้อยู่กับทีมหรือไม่ดีกับคุณคุณก็รู้ "ถ้าคุณสามารถ 'เปลี่ยน บริษัท เปลี่ยน บริษัท " ...
ฉันจะใช้ฐานสองข้อนี้:
อนุญาตให้เฉพาะผู้ที่แสดงความคิดเห็นเพื่อทำการตรวจสอบรหัสเท่านั้น
บางทีช่วงเวลาหนึ่งอาจทุ่มเทให้กับการตรวจสอบโค้ดโดยหวังว่าจะได้หลีกเลี่ยงปัญหาการถูกขัดจังหวะ
เป้าหมายควรจะตรวจสอบในรหัสคุณภาพ คุณไม่ต้องการที่จะลงโทษ / บังคับให้ความคิดเห็นถึงจุดที่ทุกคนเพียงแค่ให้การอนุมัติ "ตรายาง"
หากคุณมีระดับที่แตกต่างกัน (jr., sr. ฯลฯ ) การเลื่อนตำแหน่งและการดูแลรักษาตำแหน่งควรจะเกิดขึ้นกับการทำงานของคุณ
ที่นายจ้างสองคนก่อนหน้านี้เราหมุนผู้ที่อยู่ในการตรวจสอบรหัสทุกวัน โดยปกติแล้ว 3 คนที่แชร์ CR วันและ CR แต่ละคนต้องลงชื่อโดยผู้ตรวจสอบสองคน สิ่งนี้ทำให้แน่ใจได้ว่าเมื่อถึงวันของคุณคุณรู้ว่า CR เป็นที่คาดหวังของคุณโดยไม่คำนึงถึงโครงการอื่น ๆ ของคุณ ดังนั้นทุก ๆ ห้าวันหรือมากกว่านั้นเป็นตาคุณและคุณสามารถปรับงานการพัฒนาให้เหมาะสม
ขณะนี้เรามีหัวหน้าทีมทำ CR คร่าวๆในรหัสของทีม ขึ้นอยู่กับพื้นที่ของแอปพลิเคชันที่ได้รับการอัปเดตหลังจาก CR เสร็จสมบูรณ์สามารถชนกับทีม Global Review ซึ่งเราตรวจสอบสิ่งต่าง ๆ ที่มีผลกระทบระดับโลกต่อแอปพลิเคชันแทนที่จะเป็นสิ่งที่ เกี่ยวข้องกับคุณสมบัติเดียว เมื่อมีการตรวจสอบจำนวนมากที่ต้องทำเรามักจะแยกมันออกมาระหว่างคนไม่กี่คนดังนั้นจึงไม่มีใครจัดการกับการเปลี่ยนแปลงของจำนวนไฟล์ที่ไร้สาระ
ที่กล่าวว่าเราเป็นเพียงการตรวจสอบรหัสที่มุ่งมั่นไปยังสาขา Dev / ตัวแปรปัจจุบัน รหัสจะต้องผ่านการตรวจสอบรหัส, การตรวจสอบทั่วโลก, การตรวจสอบฐานข้อมูลและการตรวจสอบ UI (แต่ละรายการที่จำเป็น) ก่อนที่จะสามารถเลื่อนระดับไปยังสภาพแวดล้อมถัดไป (เช่นอัลฟ่า)
ในที่สุดเราตกลงกับ SLA เกี่ยวกับความคิดเห็นที่เปลี่ยนไปอย่างรวดเร็ว แทบจะไม่มีอะไรรออยู่ในคิวนานกว่า 48 ชั่วโมงและความเห็นส่วนใหญ่จะใช้เวลาน้อยกว่า 24 ชั่วโมง
บริษัท ที่ฉันทำงานเพื่อขอรหัสทั้งหมดจะต้องได้รับการตรวจสอบโดยผู้พัฒนารายอื่นก่อนที่จะส่งมอบ สมาชิกในทีมของฉันมักจะผิดหวัง ...
หากคุณไม่ได้ทำซอฟต์แวร์ที่มีความสำคัญต่อภารกิจหรือแพตช์ที่สำคัญไปยังรหัสผู้ผลิตออกมาไม่มีเหตุผลที่น่าสนใจที่จะยึดติดกับบทวิจารณ์โค้ดบางประเภท
เดินในรองเท้าของคุณครั้งแรกที่ผมจะชี้ให้ผู้บริหารที่หลังกระทำการตรวจสอบรหัสได้รับการพิจารณาอย่างเท่าเทียมกันเป็นเกียรติเป็นก่อนกระทำคน คำเหล่านี้สามารถค้นหาได้บนเว็บ - หากจำเป็นให้ค้นหามีการอ้างอิงเพื่อสำรองข้อมูลนี้ ผู้ใช้ไม่จำเป็นต้องทำการตรวจสอบล่วงหน้าเพื่อรับโค้ดที่ตรวจสอบ 100%
จากข้างต้นฉันขอแนะนำให้พวกเขาลดทัศนคติการจัดการไมโครซอฟต์และให้นักพัฒนาลองวิธีที่พวกเขารู้สึกสะดวกสบายมากขึ้น บทวิจารณ์ก่อนหรือหลังโพสต์จะดีที่สุดสำหรับโปรแกรมเมอร์ที่จะเลือก หาก บริษัท รู้ดีกว่าโปรแกรมเมอร์ทำไมพวกเขาถึงไม่เขียนโค้ดด้วยตัวเอง?
คุณมีปัญหาหลายอย่างในการจัดการ - คุณต้องชนะใจและจิตใจและคุณต้องให้แน่ใจว่ามีเวลาสำหรับการตรวจสอบโค้ด
ส่วนที่สองนั้นง่ายที่สุด - คุณเห็นด้วย (โดยรวมและต้องมีการจัดการ) สิ่งแรกที่นักพัฒนาทำคือทุกเช้าคือบทวิจารณ์โค้ดของพวกเขา - นี่ง่ายเข้าใจเข้าใจได้ดีมีประสิทธิภาพและช่วยให้คุณเอาชนะคนได้ดี หากพวกเขาไม่ปฏิบัติตาม ดีกว่าคุณไม่ขัดจังหวะอะไรเลยคุณไม่ได้ขอให้พวกเขาหยุดทำงานบนรหัสของพวกเขาคุณไม่ได้ขอให้คนอื่นบีบบางสิ่งลงในรายการที่ต้องทำ ...
ส่วนแรกเป็นปัญหาจริง - ผู้เข้าร่วมในกระบวนการตรวจสอบต้องเห็นว่ามีค่ามิฉะนั้นพวกเขาจะไม่ทำการตรวจสอบโค้ด (ซึ่งรู้ว่าไม่มีคุณค่า) เมื่อพวกเขาสามารถเขียนรหัสหรือแก้ไขข้อบกพร่อง (ซึ่ง มีความสำคัญมากกว่า ... ?)
หากคุณสามารถนำสองสิ่งนี้มารวมกัน - ให้แน่ใจว่าทุกคนเชื่อ (หรือเข้าใจ) ว่ามีคุณค่าในการตรวจสอบโค้ด - ที่ขั้นพื้นฐานที่สุดนั้นควรหมายถึงข้อผิดพลาดที่น้อยลงซึ่งหมายถึงรหัสใหม่ที่มากขึ้น สิ่งต่าง ๆ เพื่อให้มีพื้นที่ว่างในตารางสำหรับการตรวจสอบโค้ดที่จะทำแล้วหวังว่าสิ่งที่ดีจะเกิดขึ้น ... มันจะกลายเป็นส่วนหนึ่งของวัฒนธรรม
เมื่อเป็นส่วนหนึ่งของวัฒนธรรมแล้วมันไม่จำเป็นที่จะต้องพูดว่า "สิ่งแรกทุกวัน" อีกต่อไป - แต่ต้องบอกว่าฉันคิดว่ามันเหมาะกับรูปแบบที่เราอาจต้องการให้ dev ทำงาน
ที่ บริษัท ส่วนใหญ่ที่ฉันทำงานมาคุณมีเวลา 3 วันในการตรวจสอบ ไม่สามารถยอมรับความคิดเห็นได้ มันเป็นส่วนหนึ่งของงานของคุณ หากคุณไม่แสดงความเห็นอย่างตรงเวลาจะมีผลกับการประเมินประสิทธิภาพของคุณ และใช่ความเห็นดูเหมือนจะเกิดขึ้นในเวลาที่ไม่เหมาะสมที่สุดเสมอ แย่มากเรียนรู้ที่จะรวมเวลาตรวจสอบในการประมาณการของคุณ อย่างไรก็ตามหากผู้บริหารเชื่อว่าบทวิจารณ์มีความสำคัญ (เช่นพวกเขายืนยันว่ามีการตรวจสอบรหัสทั้งหมด) ดังนั้นพวกเขาจะผลักดันนโยบายที่คล้ายกัน นอกจากนี้หากผู้คนไม่ทำการตรวจสอบให้เสร็จภายในเวลาที่กำหนดนั่นก็เป็นการยอมรับเนื้อหา
พิจารณาใช้เครื่องมือเช่นคณะกรรมการตรวจสอบ มันมีประโยชน์มากโดยเฉพาะอย่างยิ่งสำหรับความคิดเห็นที่ยาวนาน
คุณสามารถอัพโหลดความแตกต่างและรอจนกว่าผู้ตรวจทานจะตรวจสอบเสร็จ หากคุณมีความเห็นแบบเปิดที่ทำให้คุณไม่สามารถทำงานต่อได้คุณสามารถรายงานสิ่งนี้ในระหว่างการประชุมประจำวัน (ทีมของคุณต้องการให้มีการตรวจสอบคุณสมบัติใหม่เพื่อให้สามารถทำการทดสอบได้โดยเร็วที่สุดใช่ไหม)
จุดสองสามจุดที่จะเพิ่มที่ไม่ได้อยู่ในคำตอบอื่น ๆ
ต้องตรวจสอบรหัสที่จะตรวจสอบ
การบล็อกงานนั้นมีลำดับความสำคัญดังนั้นการตรวจสอบโค้ดควรจะมีความสำคัญมากกว่างานอื่น ๆ ในฐานะนักพัฒนาซอฟต์แวร์คุณควรต้องการให้ผู้อื่นตรวจสอบโค้ดของคุณ (ในขณะที่คุณต้องการทำให้ดีขึ้น) ในความรู้นั้นคุณควรทำการตรวจทานเพื่อคนอื่นโดยทันที
คำถามที่ยากขึ้นคือเมื่อใดและอย่างไรที่จะทำการตรวจสอบโค้ดให้ดี
กฎที่ใช้งานได้สำหรับเราในเวลาที่ต้องใช้รหัสที่ใช้ร่วมกันจะต้องได้รับการตรวจสอบเนื่องจากมีผลกระทบกว้างกว่าในขณะที่ในรหัสสำหรับแอปพลิเคชันเดียว