มีกรณีศึกษาจริง ๆ เกี่ยวกับการเขียนอัตราความสำเร็จ / ความล้มเหลวของซอฟต์แวร์ใหม่หรือไม่?

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

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

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

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

ควันหลง: โอเคหลังจากค้นหาเพิ่มเติมฉันได้พบสามบทความที่น่าสนใจเกี่ยวกับกรณีศึกษา:

1. เขียนหรือนำมาใช้ใหม่ พวกเขาทำการศึกษาเกี่ยวกับแอป Cobol ที่ถูกแปลงเป็น Java
2. อื่น ๆ ที่อยู่ในซอฟท์แว Reuse: นักพัฒนาประสบการณ์และการรับรู้
3. การใช้ซ้ำหรือเขียนซ้ำการศึกษาค่าใช้จ่ายในการบำรุงรักษาอีกครั้งกับการเขียนซ้ำ

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

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

ฉันไม่รู้เกี่ยวกับกรณีศึกษา แต่ฉันคิดว่าคำตอบมาตรฐานสำหรับวิธีการน่าจะเป็น "เพิ่มการทดสอบหน่วยและ refactor"

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

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

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

ฉันอ่านการทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกโดย Michael Feathersสักพักแล้วและพบว่ามันนำเสนอข้อมูลเชิงลึกที่ดีเกี่ยวกับวิธีปฏิบัติในโลกแห่งความเป็นจริงในการรักษารหัสดั้งเดิมรวมถึงการทดสอบการเขียน (แม้ว่าคุณจะไม่รู้ว่า การสร้าง / การเขียนซ้ำของหลักสูตร มันค่อนข้างเก่าไปหน่อย แต่ติดอันดับสูงใน Amazon

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

แนวคิดนี้ว่าระบบสามารถแบ่งออกเป็นชิ้น ๆ และเข้าใจเป็นรายบุคคลมีข้อบกพร่อง ในบางช่วงเวลาบุคคลเดียวหรือหลายคนต้องสามารถเข้าใจปัญหาทั้งหมดได้อย่างครบถ้วน หากปัญหานั้นเป็นปัญหาทางธุรกิจและเทคโนโลยีที่ขับเคลื่อนพวกเขา อาจต้องใช้บุคคลใน บริษัท เป็นเวลาหลายปีเพื่อทำความเข้าใจระบบทั้งหมดให้อยู่ในระดับที่สามารถแทนที่พวกเขาได้โดยไม่เกิดภัยพิบัติ นี่เป็นกรณีของ บริษัท ของฉันเมื่อฉันเข้ารับตำแหน่งผู้อำนวยการฝ่ายเทคโนโลยี หากไม่ใช่เพราะความจริงที่ว่าฉันเป็น coder ฉันจะไม่สามารถเข้าใจรายละเอียดทั้งหมดของการจัดระบบที่ไม่ดีควบคู่ไปกับสถาปัตยกรรมที่ถูกผูกไว้อย่างแน่นหนาและการรวมเทคโนโลยี หากมีขนาดเล็กซ่อนอยู่รายละเอียดที่ไม่มีเอกสารเช่น"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" ถูกมองข้ามผลลัพธ์ที่สามารถหายนะและวิธีเดียวที่จะรู้ว่านี่คือการค้นพบมันช้าทั้งหมด

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

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

มีการสร้างคุกกี้ซอฟต์แวร์ (ควร) ออกแบบมา

มีตัวอย่างมากมายของ บริษัท ที่เสียชีวิตจากการเขียนซ้ำเช่น Netscape นอกจากนี้ยังมี บริษัท ที่รอดชีวิตจากการเขียนซ้ำโดยไม่มีปัญหาใหญ่อย่างทวิตเตอร์

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

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

ฉันคิดว่าการเขียนใหม่ทำให้เข้าใจได้ง่ายขึ้นในทุกวันนี้เพราะเรากำลังเขียนโค้ดบนไหล่ของการพัฒนากรอบการทำงานที่รวดเร็วเช่น Rails, Grails, AngularJS หากคุณต้องการย้ายจาก js ธรรมดาไปยัง Angular การเขียนซ้ำเป็นเรื่องเกี่ยวกับสิ่งที่คุณทำได้ มันอาจทำให้รู้สึกตัน หากคุณกำลังแทนที่การใช้งาน diy หนึ่งรายการด้วยวิธีอื่น (เช่นตัวอย่างทั้งหมดในบทความของ Joel Spolsky ) คุณอาจจะบ้า

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

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

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

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

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