ความซับซ้อนของจุดไม่กลับมา คุณเรียกว่าอะไร

ในฐานะนักพัฒนาซอฟต์แวร์หนึ่งในภารกิจหลักของฉันคือรักษาความซับซ้อนภายใต้การควบคุม

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

ช่วงเวลาที่เฉพาะเจาะจงนี้มีชื่อในภาษาโปรแกรมเมอร์หรือไม่

--edit--

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

มันเป็นปัญหาของการบำรุงรักษามากกว่าความซับซ้อน

ปรากฏการณ์นี้ถูกเรียกว่า "หนี้ทางเทคนิค" และเมื่อถึงระดับวิกฤตโครงการก็กำลังจะล้มละลาย

นั่นคือสิ่งที่คุณหมายถึงอะไร

"จุดที่ซับซ้อนเกินกว่า" ถูกอ้างถึงเป็นภาษาอังกฤษว่า:

โอ้พระเจ้าของฉันปูนี้คืออะไร

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

ดังนั้นการแยกบางสิ่งที่ซับซ้อนออกจากสิ่งที่น่ากลัวมากนั้นอาจเป็นเรื่องยาก

HOWEVER: สิ่งที่เกิดขึ้นจริงกับซอฟต์แวร์ทั้งหมดคือการประมวลผลแบบนี้:

ขั้นตอนที่ 1: มีสเป็คที่ดีทำการออกแบบที่ดีใช้สิ่งที่ดี ทุกคนมีความสุข

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

ขั้นตอนที่ 2: ทำการเปลี่ยนแปลงบางอย่างสิ่งต่าง ๆ เพิ่มฟังก์ชั่นใหม่รวมอยู่ด้วย สถาปัตยกรรมและโครงสร้างจากขั้นตอนที่ 1 ทำให้กระบวนการนี้ค่อนข้างเจ็บปวด [แต่โอ๊ะโอ "cruft factor" เพิ่มขึ้นเล็กน้อย]

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

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

ในตอนท้ายของขั้นตอนที่ 3: นักพัฒนาแสดงความยินดีกับความสง่างามที่ยอดเยี่ยมของการออกแบบของพวกเขาและหายไปจากความคิดที่ค่อนข้างมีความสุข "Gee สถาปัตยกรรมนี้ค่อนข้างดีที่จะอนุญาตให้มีการเปลี่ยนแปลงมากมาย เกี่ยวกับ X และ Y และ Z พวกเขาสามารถทำความสะอาดได้ในตอนนี้ แต่ !!! Ahhh !!! ฉันฉลาดที่ได้ทำเบี้ยเลี้ยงเหล่านั้นทั้งหมดในขั้นตอนที่ 1 มันดีมากฉันมีมรดกที่ยอดเยี่ยมที่นี่สำหรับ คนอื่นจะเพิ่มสิ่งต่าง ๆ ในอนาคตมันจะวิเศษและโลกจะเป็นสถานที่ที่ดีกว่า "

ขั้นตอนที่ 4: เช่นเดียวกับขั้นตอนที่ 3 ยกเว้น:

ในตอนท้ายของขั้นตอนที่ 4: นักพัฒนาคิดว่า: "สิ่งนี้เป็นสิ่งที่ดีเพื่อให้ UGLY รักษาไว้มันต้องการการเปลี่ยนแปลงที่จริงจังจริง ๆ ฉันไม่ชอบการทำงานนี้จริง ๆ แล้วมันต้องการ refactoring ฉันสงสัยว่าเจ้านายเป็นใคร จะบอกว่าเมื่อฉันบอกเขาว่าต้องใช้เวลา 6 สัปดาห์และจะไม่มีอะไรให้ผู้ใช้เห็นในตอนท้าย ... แต่ฉันจะมีขอบเขตการดัดแปลงในอนาคตอีก 5 ปีด้วยการทำเช่นนี้ .... hmmm .. เวลาที่จะไปผับเพื่อดื่มเบียร์.

ขั้นตอนที่ 5: ต้องทำการเปลี่ยนแปลงจำนวนมาก

และในระหว่างขั้นตอนที่ 5 นักพัฒนาพูดกัน: "รหัสนี้แย่มากใครเขียนสิ่งนี้พวกเขาควรถูกยิงมันน่ากลัวเราต้องเขียนซ้ำ"

ขั้นตอนที่ 5 เป็นอันตรายถึงชีวิต นี่คือสิ่งที่ปัจจัย cruft แย่มากจนโค้ดไม่สามารถเปลี่ยนแปลงได้อีกเพียงไม่กี่ครั้งมันต้องมีการเปลี่ยนแปลงครั้งใหญ่

ปัญหาในขั้นตอนที่ 5 คือความปรารถนาที่จะทิ้งมันและเริ่มต้นใหม่อีกครั้ง สาเหตุที่เป็นอันตรายถึงชีวิตคือ "ปัจจัย Netscape" ไปที่ google it บริษัท ตาย ณ จุดนี้เนื่องจากการเริ่มต้นอีกครั้งหมายความว่าคุณเริ่มต้นด้วยสมมติฐานประมาณ 50% แทนที่จะเป็นข้อเท็จจริงความกระตือรือร้น 150% แทนที่จะเป็นความรู้ความหยิ่ง 200% แทนที่จะเป็นความอ่อนน้อมถ่อมตน ("พวกนั้นโง่มาก!") และคุณแนะนำบั๊กใหม่ทั้งหมด

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

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

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

• ความซับซ้อนอยู่ในข้อกำหนดของเอกสาร
• เครื่องมือใหม่ใช้งานยากกว่าเว็บไซต์แฟลชที่สัญญาไว้
• ทีมใหม่ไม่ร้อนแรงอย่างที่คิด

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

ฉันไม่ได้รวมไว้ในกรณีนี้ที่มีการใช้การวัดเพื่อระบุโมดูลหรือการออกแบบที่มีปัญหา specfic ซึ่งถูกคัดและแทนที่แล้ว

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

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

ฉันไม่รู้ว่ามีชื่อ แต่ถ้าไม่มีฉันจะเสนอให้เรียกมันว่า "จุดหลอมละลาย"

นี่ไม่ใช่คำถามที่น่าสนใจมาก

แน่นอนมันเล็กน้อย

มันช่างน่ารำคาญเหลือเกินที่เราได้พัฒนาวิธีการมากมายในการรับมือ

1. วิธีการน้ำตก ผู้คนจำนวนมากใช้เวลาทบทวนข้อกำหนดและเอกสารการออกแบบเพื่อให้แน่ใจว่ามีการจัดการความซับซ้อน

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

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

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

• ไม่มีกำหนดเวลาในการวิ่งหรือลำดับความสำคัญของกรณีการใช้ที่เหมาะสมในวิธีการแบบ Agile พวกเขาไม่ได้มุ่งเน้นไปที่การนำสิ่งที่เผยแพร่สู่ผู้ใช้โดยเร็วที่สุด

ความซับซ้อนควรถูก จำกัด โดยการตั้งเป้าหมาย

มวยปล้ำที่มีความซับซ้อนหมายถึงเป้าหมายไม่ได้ถูกกำหนดไว้หรือไม่ได้รับการตอบแทนอย่างเหมาะสม

ไม่มี "จุดเปลี่ยน" หากการจัดการความซับซ้อนเป็นปัญหาอยู่แสดงว่ามีบางอย่างผิดปกติในองค์กร

มีวิธีการที่จะมองเห็นและติดตามความเสี่ยงของการเพิ่ม complexitiy สำหรับ (ใหญ่) โครงการและรหัส เมื่อพวกเขาถูกนำไปใช้อย่างมีเหตุผลหวังว่าจะไม่จำเป็นต้องใช้ชื่อใหม่สำหรับจุดที่ไม่ต้องการผลตอบแทน (มี MOOC ที่เกี่ยวข้องที่ openHPI คือhttps://open.hpi.de/courses/softwareanalytics2015/ )

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

วิธีการบางอย่างเพื่อลดความซับซ้อนของโครงสร้างคือhttp://www.buch.de/shop/home/suche/?fq=3540878890 :

• modularisation
• หลีกเลี่ยงข้อเสนอแนะลูป
• รูปสามเหลี่ยม

นอกจากนี้ยังมีแนวคิดของการออกแบบซึ่งเป็นจริง: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ ด้วยแนวคิดนี้ปัญหาที่น่าเชื่อถือเนื่องจากความซับซ้อนที่ไม่จำเป็นสามารถหลีกเลี่ยงได้

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