คุณเคยมีส่วนร่วมในการเขียนใหญ่หรือไม่? [ปิด]

Joel Spolskyพูดถึงหนึ่งในกระทู้ที่โด่งดังของเขา:

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

Chad Fowlerเขียนว่า:

คุณเคยเห็นวิดีโอโพสต์ในเว็บบล็อกและโฆษณาและคุณตัดสินใจว่าคุณจะนำผลิตภัณฑ์ของคุณไปใช้ใหม่ใน Rails (หรือ Java หรือ. NET หรือ Erlang เป็นต้น)

ระวัง. นี่เป็นเส้นทางที่ยาวกว่าหนักกว่าและมีแนวโน้มที่จะเกิดความล้มเหลวมากกว่าที่คุณคาดไว้

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

ฉันมีส่วนร่วมในการเขียนไม่กี่อาชีพของฉันและพวกเขาทั้งหมดภัยพิบัติ ฉันคิดว่าพวกเขาทั้งหมดล้มเหลวด้วยเหตุผลเดียวกัน

• ต้องใช้ความพยายามที่ต่ำกว่าความเป็นจริงมากเกินไป: ทุกครั้งที่มีคนต้องการเขียนใหม่อาจเป็นเพราะระบบเก่าใช้เทคโนโลยีเก่าและบำรุงรักษายาก สิ่งที่พวกเขาล้มเหลวในการพิจารณาคือเนื่องจากอายุอาจมีความพยายามในการพัฒนา 30-40 ปี การคิดว่าคุณสามารถเขียนสิ่งใหม่ทั้งหมดใน 6 เดือนด้วยทีมงาน 5 คนนั้นมันไร้สาระ
• ความรู้ที่หายไป: ระบบเก่า ๆ มีมานานแล้วมันทำสิ่งต่าง ๆ มากมายและติดอยู่ในทุกสิ่ง ไม่มีเอกสารที่เป็นปัจจุบันและไม่มีจุดอำนาจเดียวที่รู้ถึงทุกสิ่งที่ระบบทำ จะมีชิ้นส่วนของความรู้กับผู้ใช้เฉพาะในแผนกเฉพาะและค้นหาพวกเขาทั้งหมดเป็นเรื่องยากหรือเป็นไปไม่ได้
• การตัดสินใจการจัดการที่ไม่ดี: การเขียนซ้ำที่ฉันมีส่วนเกี่ยวข้องมีความคาดหวังที่คล้ายกันจากการจัดการ: ระบบใหม่ควรจะ 'เสร็จสิ้น' และระบบเก่าสามารถปิดได้ในวันที่กำหนด ไม่มีตัวเลือกอื่นที่ยอมรับได้ ฉันคิดว่าพวกเขาได้รับสิ่งนี้ในหัวของพวกเขาเพราะพวกเขาใช้จ่ายเงินทั้งหมดนี้เพื่อจ้างคนใหม่สำหรับโครงการขนาดใหญ่นี้ ในความเป็นจริงแล้วกลยุทธ์การลดความเสี่ยงที่ดีกว่าคือการเขียนฟังก์ชั่นหลักของระบบเดิมเขียนรับมือ 50-75% ของระบบเก่าสำหรับการเปิดตัวครั้งแรกและดูวิธีการทำงาน! เนื่องจาก # 1 และ # 2 ข้างต้นสิ่งนี้อาจได้ผลดีกว่ามากเมื่อเราค้นหาคุณลักษณะบางอย่างที่พลาดไปและสิ่งที่จำเป็นในการปิดระบบเก่า

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

โครงการ 1

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

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

โครงการ 2

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

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

โครงการ 3

ฉันต้องรวมความล้มเหลวที่นี่ เราสนับสนุนลูกค้าที่ต้องการเครื่องมือการจัดการข้อมูลเพื่อใช้ในสถานการณ์ภัยพิบัติ / วิกฤต เราสืบทอดแอปพลิเคชัน Java Swing ที่นักพัฒนาดั้งเดิมเขียนโดยไม่เข้าใจ Swing อย่างแท้จริง โดยที่ฉันหมายความว่าพวกเขาไม่ปฏิบัติตามคำแนะนำของ Sun ในการจัดการกับ Swing และจัดการ UI อย่างถูกต้องดังนั้นคุณจะเข้าสู่ลูปเหตุการณ์ที่ไม่มีที่สิ้นสุดและปัญหาที่แปลกและยากต่อการติดตามอื่น ๆ ผลก็คือมันเต็มไปด้วยข้อบกพร่องปัญหาส่วนติดต่อผู้ใช้ ฯลฯ นี่เป็นแอปพลิเคชันที่ซับซ้อนมาก เพื่อรักษาสติของเราเราพยายามที่จะเขียนแอพ Swing ที่เขียนไม่ดีลงในแอพ Swing ที่เขียนได้ดี

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

ข้อสรุป

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

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

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

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

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

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

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

เป้าหมาย:ใช้ระบบเอกลักษณ์องค์กรที่สามารถรับรองความถูกต้องของบัญชีใน 4 โดเมนและจัดการบัญชี (ด้วยตนเอง) เต็มรูปแบบใน 1 โดเมน เนื่องจาก. Net มีการใช้งานบนดาวเทียมอยู่แล้วไซต์ asp แบบคลาสสิคที่ทำหน้าที่เป็น "lead-in" จะต้องถูกเขียนใหม่การจัดการข้อมูลประจำตัวที่เพิ่มเข้ามาและไซต์ทั้งหมดจะต้องทำการทดสอบการถดถอยเพื่อให้แน่ใจว่าไม่มีผลกระทบต่อบริการ

ทรัพยากร:สถาปนิกหลัก 3 คน - โปรแกรมเมอร์, การจัดการข้อมูลประจำตัว, ผู้จัดการโครงการ นักพัฒนาประมาณ 20 คนนักวิเคราะห์ 10 คนผู้ทดสอบ 10 คน

ระยะเวลาดำเนินการ (เริ่มจนแล้วเสร็จ): 1.5 ปี

เริ่มต้นความสำเร็จ:ใกล้ความล้มเหลว

ความสำเร็จที่ยืนยาว:ยอดเยี่ยม

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

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

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

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

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

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

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

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

มันเป็นแอปพลิเคชันภายใน - แอปพลิเคชันธุรกิจหลักที่จริง

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

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

กลยุทธ์ที่ไม่ดี : ฉันดูแลนักเรียน 4 คนเป็นกลุ่ม:

• นักเรียน # 1 - เขียนการเข้าถึงฐานข้อมูล / แบบสอบถามเพื่อให้ปลอดภัย
• นักเรียน # 2 - ย้าย CSS ทั้งหมด "ขึ้น"
• นักเรียน # 3 - ทำทุกหน้าให้รองรับ w3c
• นักเรียน # 4 - แก้ไขข้อบกพร่องที่ค้างอยู่ทั้งหมด
• ตัวเอง: ลบคำเตือน PHP และสิ่งเส็งเคร็งทั้งหมด (รหัสซ้ำและอื่น ๆ )

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

กลยุทธ์ที่ดี :

• ศึกษาเว็บไซต์ทั้งหมดสร้างเอกสารข้อกำหนดผลิตภัณฑ์ที่ดี
• ออกแบบฐานข้อมูลอีกครั้งอย่างถูกต้อง
• เริ่มต้นจากศูนย์ด้วยกรอบของฉันเอง
• ออกแบบไซต์ใหม่
• ทำหลายภาษา

เวลาที่ใช้: สองเดือน ( อาจน้อยกว่านี้ )

• รหัสที่ดี
• การบำรุงรักษาที่ดี
• ผลผลิต
• ไม่มีคำตอบเช่น "เราไม่สามารถทำเช่นนี้เว็บไซต์ไม่สามารถจัดการกับผลิตภัณฑ์ดังกล่าว"

ดังนั้นคำพูดสุดท้ายของฉัน: ทุกอย่างขึ้นอยู่กับความซับซ้อนของสิ่งที่คุณต้องเขียนใหม่

อย่าลังเลที่จะแก้ไขโพสต์ของฉันเพื่อให้เป็นภาษาอังกฤษที่เหมาะสมโปรดขอบคุณมาก

Olivier Pons

บริษัท ที่ฉันทำงานเพื่อเริ่ม refactor สำคัญของ codebase

ครึ่งหนึ่งของทีมถูกตั้งค่าให้ทำงานกับ refactor และอีกครึ่งหนึ่งยังคงรักษาและปรับปรุงผลิตภัณฑ์ที่มีอยู่

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

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

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

ฉันเขียนใหม่ครั้งใหญ่ในช่วง 3 ปีที่ผ่านมา เราคาดว่าโครงการดั้งเดิมจะใช้เวลา 2 ปี แนวคิดพื้นฐานคือการแทนที่ฮาร์ดแวร์ใช้ระบบปฏิบัติการที่มีอยู่เขียนตรรกะทางธุรกิจ (จาก c ถึง CPP) สร้างการ์ด IO ใหม่และเขียน UI ใหม่

ระหว่างทางเราทำการตัดสินใจที่แย่มาก เราไม่มีประสบการณ์จริงใน CPP และไม่มีที่ปรึกษาให้สอนได้ดี เราพยายามสร้างกรอบ UI ของเราเองโดยใช้ win32 ฮาร์ดแวร์ราคาถูกและ BSP มีข้อบกพร่อง ซอฟต์แวร์มีความยืดหยุ่นสูง แต่ยากต่อการดูแลรักษา เมื่อปีที่แล้วเราได้พัฒนา UI ที่ปลูกในบ้านและพัฒนา UI ใน. net เรายังเขียนกลไกการคงอยู่และโปรโตคอลการสื่อสารข้อมูลของเราอีกครั้ง

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

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

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

ฉันเขียนเครื่องมือเขียนบล็อกใน 3 สัปดาห์ ฉันเขียนใหม่ใน 8 ชั่วโมง

การวางแผนล่วงหน้าเป็น กุญแจสำคัญในการเขียนใหม่ที่ประสบความสำเร็จ การรู้จักระบบภายในและภายนอกก็เป็นประโยชน์เช่นกัน

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