เป็นความคิดที่ดีหรือไม่ที่จะกำหนดเวลาปกติในการล้างรหัส? [ปิด]

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

เป็นความคิดที่ดีหรือไม่ที่จะกำหนดเวลาปกติพูด 1 สัปดาห์ทุก 2 เดือนเพื่อทำความสะอาดโค้ดโค๊ดของเรา

เลขที่

แก้ไขในขณะที่คุณกำลังทำงาน:

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

ความคิดเห็นส่วนตัวของฉัน: จำเป็นอย่างยิ่งสำหรับโครงการ 90%

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

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

โดยปกติจะมีปัญหาสองประเภทที่สร้างขึ้นด้วยวิธีนี้:

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

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

ฉันมีนักพัฒนาของฉันเป็นระเบียบเรียบร้อยรหัสของพวกเขาก่อนที่จะเช็คอิน (โค่นล้ม) หรือผสานกับสาขาการพัฒนาหลัก (Git)

ฉันให้พวกเขาทำต่อไปนี้:

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

สำหรับโครงการขนาดใหญ่รหัสจะได้รับการตรวจสอบอย่างเป็นทางการก่อนที่จะรวมจากสาขาการพัฒนาไปยังสาขาหลัก

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

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

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

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

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

ไม่ชัดเจนหากคุณหมายถึงแบบฝึกหัด clean-the-code เพิ่มเติมเป็นระยะ ๆ ในแง่นั้นใช่ เราปฏิบัติตามสิ่งที่เคยปฏิบัติมาความเสื่อมโทรมเกิดขึ้นเสมอ

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

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

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

• เพื่อนระวัง CRing
• การเขียนการทดสอบหน่วยพร้อมกับรหัสเอง
• ใช้แนวทางการเข้ารหัส
• ใช้ตัวจัดรูปแบบอัตโนมัติและ linters (แต่ YMMV)
• เป็นต้น

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

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

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

หลังจากผ่านไปสองสามเดือนของการทำงานประเภทนี้หัวหน้าทีมฝ่ายปฏิบัติการของเราบอกฉันว่าทุกอย่างราบรื่นดีแค่ไหน

แต่ละรายการอาจดูเหมือนไม่มาก แต่ก็เหมือนกับหนี้ทั้งหมดมันโฆษณา

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

นี่อาจเป็นเป้าหมายในท้ายที่สุด แต่คุณอาจมีทีมที่อยู่ไกลจากการใช้สิ่งนี้

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

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

ในที่สุดคุณไม่ควรต้องตั้งเวลา

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

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

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