ฉันจะแนะนำการปรับปรุงโค้ดที่ออกแบบมาไม่ดีของผู้อื่นในระหว่างการตรวจสอบได้อย่างไร?

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

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

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

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

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

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

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

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

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

มีจุดหวานสำหรับการเพิ่มมูลค่าผ่าน refactoring การเปลี่ยนแปลงจำเป็นต้องทำให้สำเร็จสามสิ่ง:

• ปรับปรุงรหัสที่อาจมีการเปลี่ยนแปลง
• เพิ่มความชัดเจน
• ใช้ความพยายามน้อยที่สุด

การพิจารณา:

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

หากโค้ดทำงานโดยไม่มีข้อบกพร่องร้ายแรงและกำหนดเวลาสำคัญ (ในลักษณะพิเศษ P&L หรือ PR ขององค์กร) ใกล้จะถึงกำหนดสายเกินไปที่จะแนะนำการปรับปรุงที่ต้องมีการเปลี่ยนแปลงครั้งใหญ่ แม้แต่การปรับปรุงรหัสก็สามารถสร้างความเสี่ยงในการปรับใช้โครงการ เวลาในการปรับปรุงเร็วขึ้นในโครงการเมื่อมีเวลามากขึ้นในการลงทุนในความแข็งแกร่งในอนาคตของรหัสฐาน

ตรวจสอบรหัสทำหน้าที่ 3 วัตถุประสงค์:

1. ตรวจสอบข้อบกพร่อง

2. กำลังตรวจสอบเพื่อดูว่าสามารถปรับปรุงรหัสได้ที่ไหน

3. เครื่องมือการสอนสำหรับผู้ที่เขียนรหัส

การประเมินคุณภาพการออกแบบ / รหัสเป็นเรื่องเกี่ยวกับ # 2 และ # 3

เท่าที่ # 2:

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

  เช่น "วิธีการออกแบบ X จะช่วยลดโอกาสเกิดข้อผิดพลาด Y ได้อย่างมีนัยสำคัญเมื่อทำการเปลี่ยนแปลง Z และเรารู้ว่ารหัสชิ้นนี้ผ่านการเปลี่ยนแปลงประเภท Z ทุก 2 สัปดาห์ค่าใช้จ่ายในการจัดการปัญหาการหยุดทำงานจากบั๊ก Y + การค้นหาข้อผิดพลาด + แก้ไขและปล่อยการแก้ไข + ค่าเสียโอกาสจากการไม่ส่งชุดเพลงถัดไปคือ$Aในขณะที่ค่าใช้จ่ายในการทำความสะอาดโค้ดตอนนี้และค่าเสียโอกาส (เช่นราคาของการจัดส่งล่าช้าหรือมีคุณสมบัติน้อย) คือ$Bตอนนี้ประเมิน - หรือ มีผู้นำทีมของคุณ / ผู้จัดการ - ประเมิน$Aเทียบ$Bและตัดสินใจ

  • สิ่งนี้จะช่วยให้ทีมสมาร์ทนำไปสู่การจัดการสิ่งนี้ได้อย่างมีประสิทธิภาพ เช่นพวกเขาจะทำการตัดสินใจอย่างมีเหตุผลโดยใช้ข้อมูลทั้งหมด

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

  • และในกรณีที่มีแนวโน้มว่า bug Z เกิดขึ้นคุณจะได้รับประโยชน์ทั้งหมดที่มากขึ้นจากชุดคำแนะนำถัดไป

เท่าที่ # 3:

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

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

พวกเขาควรเห็นคุณค่าก่อนที่จะทำงานพิเศษ

ฉันมักจะแสดงความคิดเห็นของฉันด้วย "ฉันจะ" ซึ่งเป็นสัญญาณว่าฉันเป็นเพียงหนึ่งในหลาย ๆ มุมมอง

ฉันยังมีเหตุผลเสมอ

" ฉันจะแยกบล็อกนี้เป็นวิธีหนึ่งเนื่องจากสามารถอ่านได้"

ฉันแสดงความคิดเห็นในทุกสิ่ง; ใหญ่และเล็ก บางครั้งฉันแสดงความคิดเห็นมากกว่าร้อยครั้งเกี่ยวกับการเปลี่ยนแปลงซึ่งในกรณีนี้ฉันยังแนะนำการเขียนโปรแกรมคู่และเสนอตัวเองในฐานะ wing-man

ฉันพยายามสร้างภาษากลางด้วยเหตุผล; การอ่าน DRY SRP ฯลฯ

ฉันได้สร้างงานนำเสนอเกี่ยวกับ Clean Code และ Refactoring อธิบายว่าทำไมและแสดงวิธีที่ฉันจัดให้กับเพื่อนร่วมงานของฉัน ฉันถือมันมาสามครั้งแล้วและที่ปรึกษาที่เราใช้ขอให้ฉันถืออีกครั้งสำหรับพวกเขา

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

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

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

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

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

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

ให้ตัวเลือกระหว่างสองตัวเลือก (refactor หรือไม่มี refactor) ให้คิดว่าฟังดูเหมือนการขายที่ฉลาดกว่า:

เฮ้หัวหน้าเราอยู่ในกำหนดและมีทุกอย่างทำงาน แต่ตอนนี้เรากำลังจะสร้างสิ่งต่าง ๆ มากมายเพื่อที่เราจะได้เพิ่มฟีเจอร์ X ในอนาคต

หรือ

เฮ้บอสพวกเราพร้อมที่จะเปิดตัวแล้ว หากเราต้องเพิ่มฟีเจอร์ X อาจต้องใช้เวลาเพิ่มอีกสองสามวัน

ถ้าคุณพูดอย่างใดอย่างหนึ่งเจ้านายของคุณอาจจะพูดว่า:

ใครพูดอะไรเกี่ยวกับคุณสมบัติ X

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

[คำตอบนี้กว้างกว่าคำถามเล็กน้อยที่ตั้งไว้เนื่องจากนี่เป็นการเปลี่ยนเส้นทางสำหรับคำถามอื่น ๆ มากมายในการตรวจสอบโค้ด]

นี่คือหลักการบางอย่างที่ฉันพบว่ามีประโยชน์:

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

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

อย่าลืมแสดงความคิดเห็นในเชิงบวก สั้น ๆ "ดี!" หรือ "เคล็ดลับเรียบร้อย!" สามารถทำวันโปรแกรมเมอร์จูเนียร์หรือไม่ปลอดภัย

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

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

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

ฉันสงสัยว่ามันจะดีกว่าถ้า ...

หรือ

มันสมเหตุสมผลไหมที่จะ ...

หากเหตุผลชัดเจนชัดเจนฉันไม่ได้กล่าว สิ่งนี้ทำให้คนอื่นมีโอกาสสมมติความเป็นเจ้าของทางปัญญาของข้อเสนอแนะดังใน:

"ใช่นั่นเป็นความคิดที่ดีเพราะ < เหตุผลที่ชัดเจนของคุณที่นี่ >"

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

ฉันสงสัยว่าจะมีวิธีการ ...

นี่เป็นเพียงการติดต่อกับคนที่งี่เง่าจริงๆ - กับเพื่อนส่วนใหญ่ของฉันฉันแค่ปล่อยให้มันมี!

การตรวจสอบโค้ดไม่ได้มีวัตถุประสงค์เพื่อทำการปรับปรุงเสมอไป

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

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

คำถามของคุณคือ "วิธีตรวจสอบโค้ดที่ออกแบบมาไม่ดี":

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

หากรหัสคือ "เพียงพอตามหน้าที่" และ / หรือ "ตรงตามข้อกำหนด" และ / หรือ "ตรงตามข้อกำหนด":

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

มีตัวเลือกสองทางเหลืออยู่สำหรับคุณ:

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

ฉันพบว่าไม่มีกระสุนเงิน คุณต้องใช้ทั้งสามและคุณต้องมีความคิดสร้างสรรค์ในการใช้งานของทั้งสาม

ในกรณีที่มีการออกแบบที่ไม่ดี cripplingly, โฟกัสของคุณควรจะอยู่ในการเพิ่มencapsulation ด้วยวิธีนี้จะง่ายต่อการแทนที่แต่ละคลาส / ไฟล์ / รูทีนย่อยด้วยคลาสที่ออกแบบมาดีกว่า

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

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

ทำซ้ำจนกว่าจะถึงกำหนดหรือจนกว่าระบบจะ "สมบูรณ์แบบ"

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

วิธีหนึ่งที่ฉันทำตามคือ

1. มันจะดีที่สุดถ้าเราทำแบบนี้
2. การเขียนด้วยวิธีนี้จะทำให้มันทำงานได้เร็วขึ้น
3. รหัสของคุณจะสามารถอ่านได้มากขึ้นถ้าคุณทำ "สิ่งนี้" "สิ่งนี้" และ "สิ่งนี้"

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

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

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

เพิ่มคุณภาพของการตรวจสอบรหัส

นอกเหนือจากคุณภาพของรหัสที่อยู่ระหว่างการตรวจสอบแล้วยังมีสิ่งอื่นอีกเช่นคุณภาพของการตรวจสอบโค้ดเอง:

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

มันง่ายกว่ามากที่จะยอมรับการตรวจสอบโค้ดที่มีคุณภาพดีกว่าการกรูมมิ่งอัตตาที่น่าสงสัย

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

แนบเนียน ฉันคิดว่าคุณต้องการหลีกเลี่ยงอัตตาการแปรงและการย้อนกลับด้านลบต่อบทวิจารณ์ ข้อเสนอแนะบางส่วน:

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

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

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

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

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

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

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

แต่โปรดพยายามหลีกเลี่ยงการสิ้นสุดในสถานการณ์นี้ในตอนแรก!