จะปรับเวลาในการปรับรหัสให้ใหม่ได้อย่างไร

มีโครงการขนาดใหญ่กว่า 70k LOC

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

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

เมื่อทำงานกับแอปพลิเคชันแบบดั้งเดิมหรือแบบบราวน์ฟิลด์มันเป็นการดึงดูดให้ทำ "การทำความสะอาดในฤดูใบไม้ผลิ" โดยหวังที่จะสร้างสิ่งต่าง ๆ ให้เป็นรูปร่าง นั่นคือการใช้ทรัพยากรอย่างไม่มีเหตุผล ท้ายที่สุดแล้วการหยุดพัฒนาซอฟต์แวร์ที่ใช้งานได้ (เฉพาะรหัสการทำงานเท่านั้นที่สามารถได้รับการฟื้นฟู) jusitifiable? คุณสามารถรับประกันเวลาที่ใช้ใน Big Refactoring Phase ว่าจะชำระในภายหลังและไม่ทำให้โครงการเสื่อมหรือไม่

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

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

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

ถ้ามันไม่ได้เพิ่มทีละน้อยละก็มันจะไม่ได้รับการปรับปรุงใหม่ใช่มั้ย

คำตอบที่ดีทั้งหมดที่นี่ - แต่ขอให้ฉันเพิ่มมิติธุรกิจให้กับสิ่งนี้ ให้ฉันถามคุณว่าอะไร/ สิ่งที่? (คิดว่าเจ้านายผมแหลมของคุณ (PHB) :)

PHB: ทำไม
คุณ: มันจะทำให้การแก้ไขง่ายขึ้น
PHB: งั้นเหรอ?
คุณ: มันจะเพิ่มปริมาณงาน - เราจะได้งานสร้างใหม่เร็วกว่าประตูใช่ไหม
PHB: งั้นเหรอ?
คุณ: เอ่อ ... มีความสุขกับลูกค้าเหรอ?
PHB: WTF
คุณ: ฉันหมายถึงคำแนะนำที่เพิ่มขึ้นความพึงพอใจที่มากขึ้น 
     กำไรมากขึ้นเร็วขึ้นเนื่องจากการฟื้นตัวในระดับต่ำ
PHB: โอ้! เสียงดี. แต่มีเพียง "เสียง" ที่ดีที่ฉันเห็น
คุณ: WTF เหรอ?
PHB: แสดงเงินให้ฉัน! (เช่นหมายเลขโปรด)
คุณ: โอ้! Brb ... (ไปและใส่ตัวเลขลงในสเปรดชีตอย่างง่ายเพื่อทำให้กรณีของคุณ)

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

ถ้าคุณคิดว่าฉันจะวัดทุกอย่างลองหนังสือเล่มนี้

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

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

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

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

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

ลองนึกภาพว่าคุณอยู่ข้างหน้ากำแพงที่ยาวและใหญ่ คุณต้องไปอีกด้านหนึ่ง

ไม่ว่าคุณจะปรับโครงสร้างผนังใหม่เพื่อสร้างประตูหรือคุณไปรอบ ๆ

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

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

ขณะที่ฉันอ่านคำตอบข้อหนึ่งให้กินช้างตัวนี้ทีละตัว ฉันมีส่วนร่วมในการตรวจสอบโครงการระหว่างประเทศขนาดใหญ่ที่สมาชิกในทีมกระจายตัวทางภูมิศาสตร์ หลังจากสร้างซอฟต์แวร์สองเวอร์ชันแรกทีมตกลงว่าแนวทางของพวกเขารูปแบบของการเข้ารหัสและการสร้างโซลูชั่นนั้นไม่สอดคล้องกัน พวกเขาตกลงที่จะเขียนส่วนใหม่ของแอปพลิเคชันตามกฎและระเบียบใหม่และเมื่อ (และเท่านั้น) พวกเขาต้องเปลี่ยนรหัสเก่าบางส่วนพวกเขา refactor มันเพื่อให้ตรงกับการประชุมใหม่ ทุกอย่างทำงานได้ค่อนข้างดี กระบวนการ refactoring เกือบจะในเดือนที่ 5 ของรหัสบางส่วนจะได้รับการ refactored บางคนยังไม่ได้ มีการนำคุณลักษณะใหม่มาใช้ในเวลาที่ลูกค้ามีความสุขผู้พัฒนามีความสุขทีมงาน QA ก็มีความสุขเช่นกัน สถานการณ์ที่ชนะ :)

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

นอกจากนี้การปรับโครงสร้างใหม่ควรเป็นกระบวนการต่อเนื่องและเวลาที่ใช้ในการปรับโครงสร้างควรรวมอยู่ในงานพัฒนาด้วยตัวเอง การมี "ภารกิจการเปลี่ยนโฉมใหม่" เป็นพิเศษไม่ใช่ความคิดที่ดี