รหัสคือ "มรดก" เมื่อใด [ปิด]

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

สรุปคำตอบ

เมื่อมองผ่านคำตอบที่ฉันเห็นสี่รูปแบบทั่วไป นี่คือที่ฉันเห็นรายละเอียด:

1. รหัสใด ๆ ที่ถูกส่ง: 6
2. ระบบที่ตายแล้ว: 2.5
3. ไม่มีการทดสอบหน่วย: 2
4. นักพัฒนาไม่ได้อยู่ที่: 1.5

ฉันค่อนข้างบางส่วนกับบทสรุปของ Wikipediaเอง:

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

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

แต่มันยังคงใช้ในระบบการผลิต - ดังนั้นมันจึงเป็นมรดกจริงๆ และอะไรทำให้เป็นมรดก

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

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

มีสาเหตุหลายประการที่ระบบหรือรหัสอาจเป็นมรดก:

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

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

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

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

สิ่งใดที่ทำให้ช้าหรือหยุดการอัปเดตรหัสฐานอาจทำให้ฐานรหัสนั้นกลายเป็นมรดก

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

เราควรหลีกเลี่ยงการติดฉลากที่ไม่มีเหตุผลรับรองของรหัสการทำงานที่สมบูรณ์แบบนี้หรือไม่?

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

ในบางกรณีไม่มีอะไรผิดปกติกับรหัสดั้งเดิม มันไม่ได้เป็นคำที่ไม่ดี รหัส / ระบบดั้งเดิมไม่ใช่ Evil พวกเขาได้รวบรวมฝุ่นบางครั้งเล็กน้อยบางครั้งมาก

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

โดยปกติจะหมายถึงการเขียนเป็นภาษาหรือตามระบบที่คุณไม่ได้พัฒนาขึ้นมาใหม่

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

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

1. ความสำคัญ "ค่อนข้าง" มีจุดมุ่งหมายเพื่อถ่ายทอดรหัสดั้งเดิมนั่นหมายความว่าคุณกำลังทำงานกับมันแม้ว่าคุณจะไม่ชอบก็ตาม ฉันไม่แน่ใจว่ามีความสำคัญเพียงพอ เหตุผลที่อาจแตกต่างกันไป บางอันมีขนาดใหญ่เกินไปและซับซ้อนเกินกว่าที่จะมาแทนที่ ส่วนอื่น ๆ เป็นส่วนต่อประสานกับระบบอื่น คนอื่น ๆ ยังถูกขับเคลื่อนด้วยการเมืองและบุคลิกภาพ (ตัวอย่างเช่นรหัสนั้นแย่มาก แต่บูธเบ็นน่าทึ่งมาก)
2. อีกประเด็นหนึ่งที่ฉันอาจไม่ได้เน้นอย่างเพียงพอคือในขณะที่คุณภาพของรหัสอาจเป็นปัจจัยหนึ่ง แต่ก็ไม่ค่อยมีปัจจัยเดียว แต่อย่างใดและไม่ค่อยมีความสำคัญเป็นพิเศษ
3. ฉันคิดว่าผู้คนที่ผลักดันการทดสอบหน่วยเป็นปัจจัยกำหนดแต่เพียงผู้เดียวก็เหมือนกับผู้ชายที่กำลังมองหาแสงจากดวงดาวสำหรับต่างหูภรรยาของเขาหลุดบล็อกไป แสงอาจจะดีกว่า แต่คุณยังคงมองในที่ผิด คิดก่อนที่จะดื่ม Kool-Aid
4. (ข้อพิสูจน์ถึง 3. ) สำหรับฉันดูเหมือนว่าบางคนกำลังพูดถึงเพิ่มเติมเกี่ยวกับวิธีที่พวกเขาต้องการสิ่งต่าง ๆ มากกว่าที่พวกเขาเป็นจริง ถ้าจอห์น Conways ' เกมชีวิตสำหรับแอปเปิ้ล IIc พลัสไม่ได้เป็นมรดกก็เพราะมันเป็นพอขนาดเล็กและง่ายว่ามันเป็นเรื่องง่ายที่จะดำเนินการอีกครั้งจากพื้นดินขึ้น การทดสอบหน่วยที่สมบูรณ์แบบที่สุดที่เคยเขียนจะไม่เปลี่ยนที่เดียวส่วนน้อยนิด

ประเด็นสุดท้ายนำไปสู่อีกสองประเด็นที่ฉันคิดว่ามักเป็นจริง

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

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

บางทีตัวอย่างที่จะช่วย: สมมติว่าโปรแกรมมีไลบรารีUI ที่มีการทดสอบหน่วยที่ยอดเยี่ยมและหลายโปรแกรมที่ใช้ไลบรารีนั้น ใครบางคนในฝ่ายบริหารระดับสูงมีความเชื่อมั่นว่า "การเปิดใช้งานเว็บ" มีความสำคัญ (และเพื่อเหตุผลในการโต้แย้งลองสมมติว่าในกรณีนี้เขาพูดถูกจริง ๆ ) หลังจากการตรวจสอบอย่างรอบคอบผู้จัดการระดับกลางพบว่าการทดสอบหน่วยปัจจุบันของพวกเขาเพียงพอที่พวกเขาสามารถเปลี่ยนจากส่วนต่อประสานผู้ใช้ที่แสดงผ่านความสามารถในการทำหน้าต่างของระบบปฏิบัติการท้องถิ่นเพื่อแสดงผลจากระยะไกลผ่าน HTML / CSS / AJAX

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

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

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

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

ฉันทำงานกับรหัสเดิมตลอดเวลา ฉันจะบอกว่าลักษณะคือ:

• ไม่สามารถขยายได้หากไม่มีความพยายามอย่างมาก
• ไม่สามารถย้ายไปยังฮาร์ดแวร์ใหม่ได้อย่างง่ายดาย
• มันสำคัญเกินไปที่ธุรกิจจะถูกแทนที่ได้อย่างง่ายดาย

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

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

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

มัน "ก่อนที่เวลาของคุณ" แต่ "ยังคงปวดหัวของคุณ"

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

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

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

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

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

มรดกสร้างมรดก รหัสดั้งเดิมคือรหัสที่คุณสืบทอดมาจากในอดีต เป็นรหัสดั้งเดิมแม้ว่าคุณจะเขียนด้วยตัวเองมาก่อน!

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

ความคิดเห็นของฉันคือสิ่งที่ถือว่าเป็นรหัสดั้งเดิมนั้นขึ้นอยู่กับหลายสิ่งและแท็ก 'ดั้งเดิม' อาจเป็นเฉพาะองค์กร

หากฮาร์ดแวร์ / ระบบปฏิบัติการนั้นทำงานอยู่นั้นเก่าและถูกยกเลิกโดยผู้จัดจำหน่าย - การนัดหยุดงาน 1

ถ้ามันเป็นงานมากกว่าที่จะพยายามที่จะแก้ไขมากกว่าที่จะเขียนมันด้วยเหตุผลใดก็ตามเพราะ

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

ทำเช่นนั้น

• แหล่งที่มาดั้งเดิมไม่สามารถใช้ได้อีกและ / หรือขาดหายไป

สไตรค์ 2

การรวมกันของหลาย ๆ องค์กรเป็นหนึ่งเดียว - Strike 3 - ด้านหนึ่งน่าจะได้รับการติดแท็กเป็นมรดก

มีทางเลือกที่ดีกว่าและราคาถูกกว่าขายเป็นแอปพลิเคชันและ / หรือบริการของบุคคลที่สามหรือไม่ - Strike 4

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

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

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

ฉันเชื่อว่าแต่ละองค์กรต้องกำหนดว่า 'รหัสดั้งเดิม' มีความหมายอย่างไรกับพวกเขา ฉันเคยดูคลาสสิฟายด์ของThe Sunday Timesทุกสัปดาห์เพื่อดูว่าองค์กรใดกำลังมองหา ที่เคยเป็นบารอมิเตอร์ของฉันสำหรับสิ่งที่ไม่เกี่ยวข้องอีกต่อไป (นั่นคือมรดก) ดีเดอะซันเดย์ไทคือไม่เกี่ยวข้อง :-) และเราสามารถพูดคุยว่าเป็นมรดก COBOL, ASP คลาสสิกเป็นมรดก ฯลฯ ... แต่ผมเชื่อว่าแต่ละองค์กรมีการตัดสินใจเมื่อโปรแกรมการพิจารณามรดกสำหรับมัน

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

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

ฉันคิดว่ารหัสดั้งเดิมไม่มีส่วนเกี่ยวข้องกับอายุเท่าไหร่ หนึ่งสามารถเขียนรหัสดั้งเดิมตั้งแต่เริ่มต้น