ขออภัยนี่จะใช้เวลานาน แต่ก็ขึ้นอยู่กับประสบการณ์ส่วนตัวของทั้งสถาปนิกและนักพัฒนาในหลาย ๆ โครงการที่เขียนใหม่
เงื่อนไขต่อไปนี้ควรทำให้คุณต้องพิจารณาการเขียนใหม่บางประเภท ฉันจะพูดเกี่ยวกับวิธีการตัดสินใจที่จะทำหลังจากนั้น
- เวลาในการเร่งความเร็วของนักพัฒนาซอฟต์แวร์นั้นสูงมาก หากใช้เวลานานกว่าด้านล่าง (ตามระดับประสบการณ์) เพื่อเพิ่มนักพัฒนาใหม่ระบบจะต้องได้รับการออกแบบใหม่ ตามเวลาที่ใช้ในการเร่งความเร็วฉันหมายถึงระยะเวลาก่อนที่ผู้พัฒนาใหม่พร้อมที่จะทำการส่งมอบครั้งแรก (ในคุณสมบัติเล็ก ๆ )
- สดใหม่จากวิทยาลัย - 1.5 เดือน
- ยังคงเป็นสีเขียว แต่ได้ทำงานในโครงการอื่นก่อนหน้า - 1 เดือน
- ระดับกลาง - 2 สัปดาห์
- มีประสบการณ์ - 1 สัปดาห์
- ระดับอาวุโส - 1 วัน
- การปรับใช้ไม่สามารถเป็นแบบอัตโนมัติได้เนื่องจากความซับซ้อนของสถาปัตยกรรมที่มีอยู่
- แม้แต่การแก้ไขข้อบกพร่องอย่างง่าย ๆ ก็ใช้เวลานานเกินไปเนื่องจากความซับซ้อนของรหัสที่มีอยู่
- คุณลักษณะใหม่ใช้เวลานานเกินไปและค่าใช้จ่ายมากเกินไปเนื่องจากการพึ่งพาซึ่งกันและกันของ codebase (คุณลักษณะใหม่ไม่สามารถแยกได้และมีผลต่อคุณสมบัติที่มีอยู่)
- รอบการทดสอบที่เป็นทางการใช้เวลานานเกินไปเนื่องจากการพึ่งพาซึ่งกันและกันของรหัสฐานข้อมูลที่มีอยู่
- มีการใช้งานเคสจำนวนมากเกินไปบนหน้าจอน้อยเกินไป สิ่งนี้ทำให้เกิดปัญหาการฝึกอบรมสำหรับผู้ใช้และนักพัฒนา
- เทคโนโลยีที่ระบบปัจจุบันต้องการอยู่
- นักพัฒนาคุณภาพที่มีประสบการณ์ด้านเทคโนโลยีหายากเกินไป
- มันเลิกใช้แล้ว (ไม่สามารถอัปเกรดเพื่อรองรับแพลตฟอร์ม / คุณสมบัติใหม่กว่า)
- มีเทคโนโลยีระดับสูงที่แสดงออกได้ง่ายกว่ามาก
- ค่าใช้จ่ายในการบำรุงรักษาโครงสร้างพื้นฐานของเทคโนโลยีเก่านั้นสูงเกินไป
สิ่งเหล่านี้ค่อนข้างชัดเจนในตัวเอง เมื่อใดที่ต้องตัดสินใจว่าการเขียนซ้ำทั้งหมดใหม่กับการสร้างใหม่ที่เพิ่มขึ้นนั้นเป็นเรื่องส่วนตัวมากขึ้นและมีค่าใช้จ่ายทางการเมืองมากขึ้น สิ่งที่ฉันสามารถพูดได้ด้วยความเชื่อมั่นคือการระบุอย่างชัดเจนว่าไม่ควรมีความคิดที่ผิด
หากระบบสามารถออกแบบใหม่ได้แบบค่อยเป็นค่อยไปและคุณได้รับการสนับสนุนอย่างเต็มที่จากการสนับสนุนโครงการสำหรับสิ่งนั้นคุณควรทำ นี่คือปัญหาแม้ว่า ระบบจำนวนมากไม่สามารถออกแบบใหม่เพิ่มเติมได้ ต่อไปนี้เป็นสาเหตุบางประการที่ฉันพบซึ่งป้องกันไม่ให้เกิดปัญหานี้ (ทั้งด้านเทคนิคและการเมือง)
- วิชาการ
- การมีเพศสัมพันธ์ของส่วนประกอบสูงมากจนไม่สามารถแยกองค์ประกอบเดียวออกจากส่วนประกอบอื่นได้ การออกแบบองค์ประกอบเดียวส่งผลให้เกิดการเปลี่ยนแปลงไม่เพียง แต่กับส่วนประกอบที่อยู่ติดกัน แต่เปลี่ยนไปเป็นองค์ประกอบทางอ้อมทั้งหมด
- สแต็คเทคโนโลยีมีความซับซ้อนที่การออกแบบของรัฐในอนาคตจำเป็นต้องมีการเปลี่ยนแปลงโครงสร้างพื้นฐานหลายอย่าง สิ่งนี้จะเป็นสิ่งจำเป็นในการเขียนใหม่ทั้งหมดเช่นกัน แต่ถ้าจำเป็นในการออกแบบที่เพิ่มขึ้นคุณจะเสียความได้เปรียบนั้นไป
- การออกแบบองค์ประกอบใหม่ส่งผลให้มีการเขียนส่วนประกอบนั้นใหม่อย่างสมบูรณ์เนื่องจากการออกแบบที่มีอยู่นั้นยอดเยี่ยมมากจนไม่มีอะไรน่าประหยัด อีกครั้งคุณจะสูญเสียความได้เปรียบหากเป็นกรณีนี้
- ในทางการเมือง
- ผู้สนับสนุนไม่สามารถเข้าใจได้ว่าการออกแบบที่เพิ่มขึ้นจำเป็นต้องมีพันธะสัญญาระยะยาวกับโครงการ ย่อมทำให้องค์กรส่วนใหญ่สูญเสียความกระหายในการใช้งบประมาณอย่างต่อเนื่องซึ่งการออกแบบที่เพิ่มขึ้นจะเกิดขึ้น การสูญเสียความกระหายนี้เป็นสิ่งที่หลีกเลี่ยงไม่ได้สำหรับการเขียนใหม่เช่นกัน แต่ผู้สนับสนุนจะมีแนวโน้มที่จะดำเนินการต่อไปมากกว่าเพราะพวกเขาไม่ต้องการแยกระหว่างระบบใหม่ที่สมบูรณ์บางส่วนและระบบเก่าที่ล้าสมัยบางส่วน
- ผู้ใช้ของระบบนั้นแนบมากับ "หน้าจอปัจจุบัน" หากเป็นกรณีนี้คุณจะไม่มีสิทธิ์ใช้งานเพื่อปรับปรุงส่วนสำคัญของระบบ (ส่วนหน้า) การออกแบบใหม่ช่วยให้คุณหลีกเลี่ยงปัญหานี้ได้เนื่องจากพวกเขาเริ่มต้นด้วยสิ่งใหม่ พวกเขาจะยังคงยืนยันในการรับ "หน้าจอเดียวกัน" แต่คุณมีกระสุนอีกเล็กน้อยที่จะผลักดันกลับ
โปรดทราบว่าค่าใช้จ่ายโดยรวมของการ redesiging เพิ่มขึ้นจะสูงกว่าการเขียนใหม่ทั้งหมด แต่ผลกระทบต่อองค์กรมักจะน้อยกว่า ในความคิดของฉันถ้าคุณสามารถพิสูจน์เขียนและคุณมีนักพัฒนาที่ยิ่งใหญ่แล้วทำมัน
ทำได้ก็ต่อเมื่อคุณมั่นใจได้ว่ามีเจตจำนงทางการเมืองที่จะเห็นมันให้สำเร็จลุล่วง ซึ่งหมายความว่าการซื้อของผู้บริหารและผู้ใช้ปลายทาง หากไม่มีมันคุณจะล้มเหลว ฉันสมมติว่านี่คือเหตุผลที่โจเอลบอกว่าเป็นความคิดที่ไม่ดี การซื้อแบบผู้บริหารและผู้ใช้ปลายทางดูเหมือนว่ายูนิคอร์นสองหัวต่อสถาปนิกหลายคน คุณต้องขายมันอย่างจริงจังและรณรงค์เพื่อความต่อเนื่องอย่างต่อเนื่องจนกว่าจะเสร็จสมบูรณ์ นั่นเป็นเรื่องยากและคุณกำลังพูดถึงการปักหลักชื่อเสียงของคุณในสิ่งที่บางคนไม่ต้องการเห็นความสำเร็จ
กลยุทธ์บางอย่างเพื่อความสำเร็จ:
- อย่างไรก็ตามถ้าคุณทำอย่าพยายามแปลงรหัสที่มีอยู่ ออกแบบระบบตั้งแต่เริ่มต้น มิฉะนั้นคุณจะเสียเวลา ฉันไม่เคยเห็นหรือได้ยินเกี่ยวกับโครงการ "การแปลง" ที่ไม่ได้จบลงอย่างน่าสังเวช
- โอนย้ายผู้ใช้ไปยังระบบใหม่ทีละทีม ระบุทีมที่มีอาการปวดมากที่สุดด้วยระบบที่มีอยู่และย้ายพวกเขาก่อน ให้พวกเขากระจายข่าวประเสริฐด้วยคำพูดจากปาก วิธีนี้ระบบใหม่ของคุณจะถูกขายจากภายใน
- ออกแบบกรอบงานของคุณตามที่คุณต้องการ อย่าเริ่มต้นด้วยกรอบการทำงานที่ใช้เวลา 6 เดือนซึ่งไม่เคยเห็นรหัสจริงมาก่อน
- รักษาเทคโนโลยีสแต็คของคุณให้เล็กที่สุดเท่าที่จะทำได้ อย่าออกแบบมากเกินไป คุณสามารถเพิ่มเทคโนโลยีได้ตามต้องการ แต่การนำออกไปทำได้ยาก ยิ่งคุณมีเลเยอร์มากเท่าไหร่ก็ยิ่งทำงานได้มากขึ้นสำหรับนักพัฒนาในการทำสิ่งต่าง ๆ อย่าทำให้มันยากจากการไป
- ให้ผู้ใช้มีส่วนร่วมโดยตรงในกระบวนการออกแบบ แต่อย่าให้ผู้ใช้กำหนดวิธีการ รับความไว้วางใจจากพวกเขาโดยแสดงให้พวกเขาเห็นว่าคุณสามารถให้สิ่งที่พวกเขาต้องการได้ดีกว่าถ้าคุณทำตามหลักการออกแบบที่ดี
