คำถามติดแท็ก legacy-code

ฉันเป็นนักพัฒนาในทีม 5 คนและฉันเชื่อว่าโครงการของเรามุ่งเน้นไปที่ภัยพิบัติ ฉันจะอธิบายว่าทำไมในอีกสักครู่ แต่คำถามของฉันคือ: ฉันจะทำงานได้อย่างไร กำหนดเส้นตายใน 1.5 เดือนและฉันรู้สึกว่าไม่ว่าเราจะทำอะไรโครงการนี้จะล้มเหลว ฉันเห็นว่าเราควรยุติโครงการและหยุดการสูญเสียเวลา แต่ในทางการเมืองฉันคิดว่ามันเป็นไปไม่ได้ที่ผู้จัดการของเราจะทำเช่นนั้น ฉันควรทำอย่างไรในกรณีนี้? ฉันควรจะใช้ความพยายามพิเศษหรือควรใช้ง่ายไหม? และฉันควรพูดกับผู้จัดการอย่างไร เหตุผลที่โครงการนี้มุ่งหน้าไปสู่ความล้มเหลว: ด้วยกำหนดเส้นตายที่กำลังจะมาถึงคุณสมบัติที่ต้องมีมากมายยังไม่เสร็จสิ้น แอปพลิเคชันไม่เสถียรและใช้งานยากมาก ระบบมีความซับซ้อนมากรหัสยากที่จะเข้าใจยากมากที่จะเปลี่ยนแปลง - โมเดลข้อมูลถูกขับเคลื่อนโดยฐานข้อมูลเชิงสัมพันธ์ที่ซับซ้อน (100+ ตาราง) ความเป็นผู้นำที่ไม่ชัดเจน ผู้จัดการตอบกลับข้อมูลใหม่พร้อมการเปลี่ยนแปลงครั้งสำคัญ เกือบจะไม่มีการทดสอบอัตโนมัติหรือการทดสอบหน่วย อย่างหนักขึ้นอยู่กับระบบอื่น ๆ แต่ยังไม่มีการทดสอบการรวม ในความเป็นจริงเราเพิ่งได้รับโครงการนี้ (พร้อมกับระเบียบ) ประมาณ 1-2 เดือนที่ผ่านมาจากทีมพัฒนาอื่นภายใต้ผู้จัดการเดียวกันซึ่งทำงานในโครงการนี้มาสองสามเดือน

335 project-management  team  project  failure  legacy-code 

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

86 estimation  legacy-code 

ผมมักจะพยายามที่จะทำตามคำแนะนำของหนังสือเล่มนี้ทำงานอย่างมีประสิทธิภาพกับมรดกค้อจ ฉันทำลายการพึ่งพาย้ายส่วนต่าง ๆ ของรหัสไปยัง@VisibleForTesting public staticวิธีการและไปยังคลาสใหม่เพื่อให้รหัส (หรืออย่างน้อยก็บางส่วนของมัน) ทดสอบได้ และฉันเขียนการทดสอบเพื่อให้แน่ใจว่าฉันจะไม่ทำลายสิ่งใดเมื่อฉันแก้ไขหรือเพิ่มฟังก์ชั่นใหม่ เพื่อนร่วมงานคนหนึ่งบอกว่าฉันไม่ควรทำเช่นนี้ เหตุผลของเขา: รหัสต้นฉบับอาจทำงานไม่ถูกต้องตั้งแต่แรก และการเขียนการทดสอบทำให้การแก้ไขและการแก้ไขในอนาคตยากขึ้นเนื่องจาก devs ต้องเข้าใจและแก้ไขการทดสอบด้วย หากเป็นโค้ด GUI ที่มีตรรกะ (ตัวอย่างเช่น ~ 12 บรรทัด, 2-3 if / else บล็อก) การทดสอบจะไม่คุ้มกับปัญหาเนื่องจากรหัสนั้นเล็กน้อยเกินไปที่จะเริ่มต้น รูปแบบที่ไม่ดีที่คล้ายกันอาจมีอยู่ในส่วนอื่น ๆ ของ codebase เช่นกัน (ซึ่งฉันยังไม่ได้เห็นฉันค่อนข้างใหม่); มันจะง่ายกว่าในการทำความสะอาดพวกเขาทั้งหมดใน refactoring ใหญ่ การแยกตรรกะออกอาจทำให้ความเป็นไปได้ในอนาคตลดลง ฉันควรหลีกเลี่ยงการแยกส่วนที่สามารถทดสอบได้ออกมาและเขียนการทดสอบหรือไม่หากเราไม่มีเวลาสำหรับการเปลี่ยนโครงสร้างใหม่ให้สมบูรณ์? มีข้อเสียใด ๆ ที่ฉันควรพิจารณาหรือไม่?

72 unit-testing  refactoring  legacy-code 

เรามีฐานรหัสดั้งเดิมขนาดใหญ่ที่มีรหัสไม่ดีซึ่งคุณไม่สามารถจินตนาการได้ ตอนนี้เรากำหนดมาตรฐานคุณภาพบางอย่างและต้องการให้ได้มาตรฐานที่สมบูรณ์ใน codebase ใหม่ที่สมบูรณ์ แต่ถ้าคุณแตะรหัสเดิม และเราบังคับใช้กับ Sonar (เครื่องมือวิเคราะห์รหัส) ซึ่งมีการละเมิดหลายพันครั้งแล้ว ตอนนี้การสนทนาขึ้นมาเพื่อลดการละเมิดเหล่านั้นสำหรับมรดก เพราะมันเป็นมรดก การสนทนาเป็นเรื่องเกี่ยวกับกฎของการอ่าน ชอบจำนวน ifs ที่ซ้อนกัน / for .. มันสามารถมีได้ ตอนนี้ฉันจะเถียงกับการลดคุณภาพการเข้ารหัสของเราลงบนรหัสดั้งเดิมได้อย่างไร

28 code-quality  static-analysis  legacy-code 

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

28 terminology  history  software  legacy-code 

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

28 design  terminology  anti-patterns  technical-debt  legacy-code 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันกำลังทำงานในการพัฒนาโครงการเก่าที่เขียนใน Java เรามีมากกว่า 10 ล้าน LOC และยิ่งกว่านั้นมากกว่า 4,000 ทดสอบการทำงาน การทดสอบที่กำหนดโดยฮัดสันนั้นล้มเหลวอย่างบ้าคลั่งเมื่อมีการเปลี่ยนแปลงรหัสที่ใหญ่กว่าทุกครั้ง การตรวจสอบความล้มเหลวในการทดสอบ - หากเป็นปัญหาในผลิตภัณฑ์หรือในการทดสอบใช้เวลาเป็นเดือน เราไม่สามารถลบการทดสอบเก่าออกได้เพราะเราไม่รู้ว่าเป็นการทดสอบอะไร! เราทำอะไรได้บ้าง วิธีดำเนินการกับการทดสอบแบบดั้งเดิมจำนวนเท่าใด

22 integration-tests  legacy-code  jenkins 

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

18 learning  skills  maintenance  legacy-code 

เรามีสถานที่ค่อนข้างมากในซอร์สโค้ดของแอปพลิเคชันของเราที่คลาสหนึ่งมีวิธีการมากมายที่มีชื่อเดียวกันและพารามิเตอร์ที่แตกต่างกัน วิธีการเหล่านั้นมักจะมีพารามิเตอร์ทั้งหมดของวิธี 'ก่อนหน้า' บวกอีกหนึ่ง มันเป็นผลมาจากวิวัฒนาการที่ยาวนาน (รหัสดั้งเดิม) และความคิดนี้ (ฉันเชื่อ): " มีวิธี M ที่ทำสิ่ง A. ฉันต้องทำ A + B ตกลงฉันรู้ ... ฉันจะเพิ่มพารามิเตอร์ใหม่ให้กับ M สร้างวิธีการใหม่เพื่อย้ายรหัสจาก M ไปยังวิธีใหม่ ด้วยพารามิเตอร์อีกหนึ่งตัวให้ทำ A + B ตรงนั้นแล้วเรียกวิธีการใหม่จาก M ด้วยค่าเริ่มต้นของพารามิเตอร์ใหม่ " นี่คือตัวอย่าง (ในภาษา Java-like-language): class DocumentHome { (...) public Document createDocument(String name) { // just calls another method with …

16 refactoring  clean-code  legacy-code 

ฉันกำลังปรับโครงสร้างคลาสรหัสเดิมอีกครั้ง Refactoring (ฉันเข้าใจ) สนับสนุนสิ่งนี้: เขียนแบบทดสอบสำหรับคลาสดั้งเดิม refactor heck ออกจากชั้นเรียน ปัญหา: เมื่อฉันปรับโครงสร้างห้องเรียนใหม่การทดสอบของฉันในขั้นตอนที่ 1 จะต้องมีการเปลี่ยนแปลง ตัวอย่างเช่นสิ่งที่ครั้งหนึ่งเคยเป็นวิธีดั้งเดิมตอนนี้อาจเป็นชั้นแยกต่างหาก อะไรคือวิธีการหนึ่งที่อาจมีหลายวิธี ภูมิทัศน์ทั้งหมดของชั้นเรียนดั้งเดิมอาจถูกลบล้างเป็นสิ่งใหม่ดังนั้นการทดสอบที่ฉันเขียนในขั้นตอนที่ 1 เกือบจะเป็นโมฆะ ในสาระสำคัญฉันจะเพิ่มขั้นตอนที่ 3 เขียนการทดสอบของฉันอย่างล้นเหลือ อะไรคือจุดประสงค์ในการเขียนแบบทดสอบก่อนที่จะสร้างใหม่? ฟังดูคล้ายกับแบบฝึกหัดทางวิชาการในการสร้างงานให้ตัวเองมากขึ้น ฉันกำลังเขียนแบบทดสอบสำหรับวิธีนี้และฉันกำลังเรียนรู้เพิ่มเติมเกี่ยวกับวิธีทดสอบสิ่งต่าง ๆ และวิธีการทำงานแบบเดิม เราสามารถเรียนรู้สิ่งนี้ได้โดยการอ่านรหัสดั้งเดิม แต่การทดสอบการเขียนนั้นคล้ายกับการถูจมูกของฉันและการบันทึกความรู้ชั่วคราวนี้ในการทดสอบแยกต่างหาก ด้วยวิธีนี้ฉันแทบจะไม่มีทางเลือกนอกจากเรียนรู้ว่าโค้ดทำอะไร ฉันพูดว่าชั่วคราวที่นี่เพราะฉันจะ refactor heck ออกจากรหัสและเอกสารและการทดสอบทั้งหมดของฉันจะเป็นโมฆะและเป็นโมฆะเป็นส่วนสำคัญยกเว้นความรู้ของฉันจะอยู่และอนุญาตให้ฉันสดใน refactoring นั่นคือเหตุผลที่แท้จริงในการเขียนการทดสอบก่อน refactor - เพื่อช่วยให้ฉันเข้าใจรหัสได้ดีขึ้น? จะต้องมีเหตุผลอื่น! กรุณาอธิบาย! บันทึก: มีโพสต์นี้: มันทำให้รู้สึกถึงการเขียนการทดสอบสำหรับรหัสดั้งเดิมเมื่อไม่มีเวลาสำหรับการปรับโครงสร้างที่สมบูรณ์? แต่มันบอกว่า "เขียนการทดสอบก่อน refactor" แต่ไม่ได้พูดว่า "ทำไม" หรือจะทำอย่างไรถ้า "การทดสอบการเขียน" ดูเหมือนว่า …

15 testing  refactoring  tdd  legacy-code 

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

14 project-management  programming-practices  team  project  legacy-code 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน4 ปีที่แล้ว ฉันเคยทำงานกับ บริษัท ผู้รับเหมาช่วงเล็ก ๆ (โปรแกรมเมอร์ 4 คนและเจ้านาย) จากนั้นเมื่อความเครียดและการเปลี่ยนแปลงที่ยาวนานบ่อยครั้งทำให้สถานการณ์ไม่สามารถทนได้ เวลาว่าง. อย่างไรก็ตามปัญหาคือส่วนใหญ่แล้วทุกอย่างจะถูกเข้ารหัสใน Classic ASP ที่เชื่อมต่อกับระบบจัดคิว C ++ แบบกำหนดเองที่เก็บทุกอย่างในระบบ AS400 เจ้านายของฉันเคยเป็นหนึ่งในนักพัฒนาซอฟต์แวร์ที่พยายามทำสิ่งนี้เป็นครั้งแรกและโดยธรรมชาติจะไม่อนุมัติการเปลี่ยนไปใช้ภาษา / เทคโนโลยีอื่น ๆ แม้จะมีความยากลำบากเพิ่มขึ้นที่แสดงถึงการพัฒนาความต้องการทางธุรกิจในปัจจุบัน ฉันติดรหัส Classic Classic ค่อนข้างมากในอนาคตอันใกล้และฉันพยายามหาวิธีที่จะทำให้มันน่าสนใจอย่างน้อยที่สุดเท่าที่ฉันเคยทำงานกับ. NET และ Java มาก่อนและฉันรู้สึกเหมือนกำลังจะไป ย้อนกลับ ... คำแนะนำใด ๆ

14 motivation  legacy-code  asp-classic 

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

10 agile  legacy-code  rewrite