ฉันสงสัยว่ารหัสตรวจสอบที่สำคัญครอบคลุมในทีมของฉัน มีการรวมความเห็นรหัสมากเกินไปโดยไม่มีความคิดเห็นใด ๆ

ดูเหมือนว่าฉันจะไม่มีสิ่งเช่นรหัสตรวจสอบโดยไม่ต้องแสดงความคิดเห็นเดียว

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

ปรับปรุง

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

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

ดังนั้นฉันจึงเพิ่มห้องสมุดชื่อ "jscpd" เพื่อตรวจจับการคัดลอก บิลด์ล้มเหลวเมื่อคัดลอกวาง นั่นเป็นการขจัดปัญหาหนึ่งทันที

ต่อไปเราจะลองแปลงสภาพ

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

โดยทั่วไปแล้วรู้สึกว่าเรากำลังเคลื่อนไหวในทิศทางที่ถูกต้อง

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

แต่จากประสบการณ์ของฉันฉันสงสัยว่ามีสิ่งอื่นเกิดขึ้น

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

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

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

การบังคับให้เครื่องมืออยู่ด้านบนของกระบวนการที่เสียหายจะไม่ทำให้กระบวนการดีขึ้น

ฉันไม่ชอบโพสต์คำตอบเดียว แต่ดูเหมือนว่าเหมาะสม:

เข้าร่วมในกระบวนการ

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

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

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

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

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

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

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

• ตรวจสอบว่ารหัสทำในสิ่งที่ควรทำคือตรงตามข้อกำหนด

• รูปแบบรหัสเพื่อให้แน่ใจว่านักพัฒนากำลังเข้ารหัสให้มีลักษณะสอดคล้อง

• การเพิ่มประสิทธิภาพเช่นจำนวนการเรียกใช้ฟังก์ชัน

• สถาปัตยกรรมและการใช้ซ้ำ

• การจัดการข้อยกเว้นและการบันทึก

• หนี้ทางเทคนิค: เป็นรหัสในสถานะที่ดีกว่าเมื่อนักพัฒนาเริ่มทำงานกับมัน

• ตรวจสอบและสร้างรหัส (ฉันพบว่ามีประโยชน์ แต่ devs อื่น ๆ ในทีมของฉันต้องการปล่อยให้ผู้ทดสอบ)

• ใช้เครื่องมืออัตโนมัติ (ฉันใช้SonarQube ) ฉันพบว่ามีประโยชน์ในการรวมสิ่งนี้เข้ากับกระบวนการสร้างของคุณเพื่อบังคับใช้การปรับปรุงโค้ดเช่นการเพิ่มการครอบคลุมการทดสอบ

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

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

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

ฉันจะบอกคุณว่าทีมของฉันรวมการตรวจสอบโค้ดเข้ากับเวิร์กโฟลว์ได้อย่างไร

ก่อนอื่นให้ฉันถามคำถามคุณ คุณใช้ระบบควบคุมเวอร์ชัน (เช่น Mercurial, Git) หรือไม่?

หากคำตอบของคุณคือใช่ให้ทำต่อไป

1. ห้ามไม่ให้ทุกคนดันสิ่งใด ๆ (แม้แต่การแก้ไขเล็กน้อย) ไปยังสาขาหลักโดยตรง (ลำตัว) *
2. พัฒนาคุณสมบัติใหม่ (หรือแก้ไข) ในสาขาแยก
3. เมื่อนักพัฒนาเชื่อว่าสาขาพร้อมที่จะรวมในต้นแบบพวกเขาจะสร้าง "คำขอดึง"
4. ห้ามไม่ให้ทุกคนรวมคำขอดึงของตัวเอง *
5. ให้ผู้พัฒนารายอื่นประเมินคำขอการดึงและตรวจสอบรหัสใหม่
6. หากรหัสผ่านการตรวจสอบดีสามารถดึงคำขอรวมได้มิฉะนั้นสามารถแก้ไขได้
7. ทำซ้ำขั้นตอนที่ 6 จนกว่ารหัสจะโตพอ (สามารถทำได้โดยไม่ต้องเริ่มต้นใหม่) **
8. เสร็จสิ้นโค้ดใหม่ทั้งหมดของคุณจะได้รับการตรวจสอบ (อย่างน้อยก็ในช่วงสั้น ๆ ) โดยคนที่มีชื่อ

ตอนนี้คุณมีจุดที่แม่นยำในเวิร์กโฟลว์ของคุณที่การตรวจสอบโค้ดเสร็จสิ้น

ทำหน้าที่ที่นั่น

* สามารถบังคับใช้โดยอัตโนมัติพร้อมกับ hooks ด้านเซิร์ฟเวอร์

** ขั้นตอนนี้ได้รับการสนับสนุนอย่างสมบูรณ์จาก GitHub (รวมถึงอื่น ๆ ) และใช้งานได้ง่ายมากลองใช้ดู

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