วิธีการกำหนดลำดับความสำคัญและความรุนแรงของ "การปรับปรุงรหัส"?

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

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

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

อย่างไรก็ตามฉันเชื่อว่าการ cruical เพื่อปรับปรุงและ refactor รหัสอย่างต่อเนื่องเนื่องจาก:

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

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

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

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

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

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

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

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

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

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

คำถามที่น่าสนใจ

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

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

จากนั้นมีขีด จำกัด สำหรับระดับความสำคัญและระดับความรุนแรงที่ตรงกันเหล่านี้

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

เริ่มจากสมมติฐานสองข้อที่นี่

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

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

ฉันจะขโมยการลงคะแนนจากขบวนการเปรียว:

ป้อนข้อบกพร่องทำการเดาอย่างคร่าวๆเกี่ยวกับความรุนแรงและลำดับความสำคัญ

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