คุณควรแก้ไขข้อบกพร่องที่มีอยู่ก่อนขณะที่กำลังทำงานอย่างอื่นอยู่หรือไม่?

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

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

ขอบคุณ Corey

ฉันทำงานกับทีมเล็ก ๆ ดังนั้นมันขึ้นอยู่กับว่าการเปลี่ยนแปลงคืออะไร:

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

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

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

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

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

เช่นเคยมันขึ้นอยู่กับ

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

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

Pragmatic Programmer เรียก 'Broken Windows' เหล่านี้

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

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

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

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

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

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

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

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

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

สิ่งหนึ่งที่ควรทราบก็คือเราเป็นร้านค้าขนาดเล็กที่มี 4 devs และฝึกงานและการแก้ไข bug i น่าจะเป็นข้อบกพร่องที่ฉันสร้างขึ้น

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

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

จัดทำเอกสารข้อสังเกตก่อนและตัดสินใจว่าจะแก้ไขในภายหลัง

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

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

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

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