มีรูปแบบการต่อต้านสำหรับซอฟต์แวร์ที่โตขึ้นมาในอดีตหรือไม่? [ปิด]

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

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

เหตุผลอาจเป็นได้ว่านักพัฒนาซอฟต์แวร์นั้นเต็มไปด้วยระบบและไม่เข้าใจว่ามันทำงานอย่างไรและจากนั้นก็เพิ่ม / ติดรหัสของเขาในตอนท้ายสุด (แทนที่จะเปลี่ยนรหัสใหม่และเปลี่ยนมัน)

ดังนั้นเมื่อเวลาผ่านไปมันก็ยากขึ้นเรื่อย ๆ ในการรักษาระบบ

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

คุณอ้างถึงหนี้ทางเทคนิค

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

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

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

การจัดการหนี้ทางเทคนิค

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

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

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

คำอธิบายของคุณเหมาะกับBig Ball of Mud Foote และ Yoder :

ในช่วงหลายปีที่ผ่านมาผู้เขียนจำนวนหนึ่ง ... ได้นำเสนอรูปแบบที่แสดงถึงสถาปัตยกรรมซอฟต์แวร์ระดับสูง ... ในโลกอุดมคติระบบทุกระบบจะเป็นแบบอย่างของรูปแบบระดับสูงอย่างน้อยหนึ่งรูปแบบ กระนั้นก็ไม่เป็นเช่นนั้น สถาปัตยกรรมที่จริงทุกข์ยากในทางปฏิบัติยังไม่ได้มีการหารือที่: BIG BALL โคลน

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

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

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

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

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