เตรียมพร้อมสำหรับการตรวจสอบรหัสในฐานะนักพัฒนาหรือไม่

ฉันกำลังมองหาแนวคิดบางอย่างที่นี่

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

คำถามของฉันคือ

1. ในฐานะนักพัฒนาเป้าหมายคุณสามารถแนะนำวิธีปฏิบัติที่ดีที่สุดบางประการที่นักพัฒนาสามารถรวมไว้ก่อนที่โค้ดของเขาจะได้รับการตรวจสอบ

   • ขณะนี้ฉันฝึกวิธีการดังต่อไปนี้

     • PPT สำหรับการไหลแบบลอจิคัล
     • ความคิดเห็นรายละเอียด

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

ฉันคิดว่านักพัฒนาจำนวนมากจะต้องผ่านสิ่งที่ฉันกำลังจะผ่านเช่นกัน

จากรายละเอียด OP ที่ให้ไว้ดูเหมือนว่าคำถามคือ "ฉันจะเรียนรู้รหัสของตัวเองอย่างไรเมื่อถามให้ค้นหา X หรืออธิบาย Y ฉันจะตอบได้อย่างรวดเร็ว"

ข้อเสนอแนะเล็กน้อยที่ฉันนึกได้:

• เมื่อการเข้ารหัสคุณต้องใช้เวลาในการเรียนรู้และเข้าใจรหัสของคุณเอง นี่อาจเป็นสิ่งที่ TL ของคุณพยายามที่จะข้ามไปหาคุณด้วยคำพูดไม่มากนัก ในฐานะที่เป็น TL ในโครงการปัจจุบันฉันได้ทำการตรวจสอบโค้ดจำนวนมากในช่วง 11 เดือนที่ผ่านมาและฉันสังเกตเห็นการฝึกฝนของนักพัฒนาบางคนเพื่อค้นหา "โค้ดตัวอย่าง" ในฐานรหัสของเราเองหรือที่อื่น (google ฯลฯ ... ) และคัดลอก / วางโดยส่วนตัวแล้วฉันไม่สามารถยืนได้เพราะในขณะที่รหัสของพวกเขาผ่านการทดสอบหน่วยง่าย ๆ พวกเขาไม่เข้าใจสิ่งที่มันกำลังทำจริงดังนั้นเราจึงไม่รับประกันว่าจะไม่มี กรณีขอบเขตหรือเงื่อนไขความล้มเหลวที่คาดว่าจะเกิดขึ้น

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

• อ่านและเรียนรู้ที่จะรักหลักการแห้ง หลายครั้งสิ่งที่คุณอยากจะคัดลอก / วางสามารถวางในตำแหน่งทั่วไป (ฟังก์ชั่นแยกชั้นเรียนแยกห้องสมุดแยก ... )

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

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

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

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

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

การปฏิบัติแตกต่างกันไป แต่ในประสบการณ์ของฉัน:

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

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

• รหัสควรจะพิมพ์หรือแสดงหมายเลขบรรทัด ควรมีหมายเลขต่อจากไฟล์หนึ่งไปเป็นไฟล์ถัดไป การอ้างถึง "บรรทัด 3502" ง่ายกว่า "บรรทัด 238 ของ foo.c" มากขึ้นและการมีตัวเลขทำให้ทุกคนสามารถพูดคุยเกี่ยวกับบรรทัดเฉพาะได้โดยไม่ต้องเสียเวลาค้นหาบรรทัดเหล่านั้น

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

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

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

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

อีกสิ่งหนึ่งที่จะเพิ่มคำตอบอื่น ๆ : จะทำให้ทางการแสดงความคิดเห็นรหัสได้ง่ายขึ้นการดำเนินการจำนวนมากของทางการตรวจสอบรหัส! ตัวอย่างเช่น

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

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

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