วิธีแก้ไขโครงการที่ไม่มีโครงสร้างโดยทั่วไป

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

ข้อมูลเฉพาะของโครงการ: เป็นโปรแกรมการขายที่เขียนขึ้นเกือบทั้งหมดใน Visual Basic Classic (VB6) ที่มีแบ็คเอนด์ MySQL และเครื่องมือการรายงานที่เขียนใน C # โมดูลการรายงาน C # นั้นมีความสุขที่ได้ทำงานมันเป็นเพียงการเขียนในช่วงสองสามปีที่ผ่านมาและก่อนหน้านั้นรายงานทั้งหมดได้ทำใน Crystal Reports 9 (ใช่เรายังมีรายงานบางส่วนที่ต้องใช้)

อย่างไรก็ตามโปรแกรมจริงนั้นเป็นหายนะที่สมบูรณ์ มีทั้งหมด LOC ค่อนข้างไม่เกิน 90k และความคิดเห็นประมาณ 10k บรรทัด (ส่วนใหญ่ไม่ใช่เอกสาร แต่เป็นรหัสเก่าที่แสดงความคิดเห็น) 158 ไฟล์ฟอร์มและ 80 ไฟล์โมดูล ฉันไม่ทราบเลยว่ามีการใช้งานจริงกี่รายการเพราะคุณสมบัติบางอย่างของโปรแกรมนั้นถูกคัดค้านและ (เอ่อบางครั้ง) ตั้งข้อสังเกตเช่นนี้โดยไม่ต้องลบรหัสที่เกี่ยวข้องออกจากโปรแกรม ฉันเดาว่ารหัส 50% เท่านั้นที่ใช้งานได้จริง

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

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

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

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

ดังนั้นฉันจะเริ่มแก้ไขโครงการนี้จริง ๆ ได้อย่างไร ลองเครื่องมือ VB6 ด้วยภาษาอื่นหรือไม่? ลองและเขียนโปรแกรมใหม่ในเวลาว่างหรือไม่? หรือเป็นสิ่งที่สิ้นหวังโดยสิ้นเชิง?

ปรับปรุง

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

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

ตอนนี้มันอยู่ในการควบคุมของแหล่งที่มาคุณสามารถกำจัดรหัสความเห็นออก

ฉันเริ่มที่นี่ในสถานการณ์ที่คล้ายกัน (แอป 80KLOC VB6 ที่ไม่มีการควบคุมแหล่งที่มาไม่มีโครงสร้างจริงเกือบทุกอย่างทำในตัวจัดการเหตุการณ์)

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

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

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

ฉันคิดว่าทางออกที่ดีที่สุดของคุณคือใช้แนวทางต่อไปนี้:

1. เรียนรู้ทุกบิตในรายละเอียดที่ระทมทุกข์ สิ่งนี้ทำให้มีโอกาสน้อยที่คุณจะทำลายบางสิ่งบางอย่างโดยไม่ตั้งใจ
2. Refactor อย่างไร้จุดหมายเพื่อปรับปรุงการแยกและโครงสร้าง แต่อย่าพยายามใช้วิธีการใหม่เช่นการเขียนโปรแกรมเชิงวัตถุใน VB6 เพียงแค่ดูดมัน
3. ถือว่าเป็นประสบการณ์การเรียนรู้ คุณจะรู้วิธีที่แตกต่างได้อย่างไรจะดีกว่าถ้าคุณไม่เคยเห็นวิธีที่ด้อยกว่า?
4. อย่ารบกวนการเขียนใหม่ในภาษา / กรอบ / แพลตฟอร์มใหม่ยกเว้นว่าคุณมีโมดูลที่สำคัญในการเขียน ถึงอย่างนั้นให้พิจารณาอย่างรอบคอบ

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

มีนักเขียนโปรแกรมภาษาโคบอลจำนวนมากที่คาดว่าจะมีการรักษารหัสจำนวนมากไว้ ฉันสงสัยว่าพวกเขาทำงานกันอย่างบ้าคลั่งเพื่อเขียนมันใหม่ในภาษาใหม่ :)

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

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

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

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

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

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

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

บางคำตอบที่ดีที่นี่แล้วฉันต้องการเพิ่มสิ่งหนึ่ง แทนที่จะพยายามเขียนทุกอย่างใหม่บางทีคุณอาจมีโอกาสพอร์ตอย่างน้อยบางส่วนของโมดูลที่ 1: 1 ถึง VB.NET (แน่นอนคุณต้องระวังให้มากเมื่อทำเช่นนี้) จากประสบการณ์ของฉันการย้ายพอร์ตดังกล่าวสามารถทำได้โดยใช้ความพยายามน้อยกว่า 5-10 ครั้งกว่าการพยายามสร้างฟังก์ชันการทำงานที่มีอยู่ทั้งหมดใหม่ทั้งหมดตั้งแต่เริ่มต้น และหลังจากที่คุณได้พอร์ตแล้วคุณสามารถเริ่ม refactor - ด้วยเครื่องมือทั้งหมดที่มีอยู่ใน. NET โลกเช่นเครื่องมือทดสอบหน่วยที่ดีเครื่องมือ refactoring อัตโนมัติ OOP จริง ฯลฯ

ฉันอยู่ในสถานการณ์ที่คล้ายกันซึ่งเราต้องย้ายโปรแกรม 16 บิต C ++ เก่า (150k LOC) ไปสู่โลก 32 บิตซึ่งกรอบ GUI ดั้งเดิมที่ใช้ไม่สามารถใช้ได้อีกต่อไป เราใช้เวลาพอสมควรที่จะเข้าใจว่าการเขียนใหม่นั้นไม่สมจริง แต่หลังจากเราตัดสินใจที่จะย้ายสิ่งนั้นไปยังโลก NET โดยใช้ C ++, C ++ / CLI และ C # เราต้องใช้เวลาประมาณ 9 เดือนในการทำให้มันเกิดขึ้น ทำงานเต็มเวลาในโครงการนั้น) และเราไม่มีการทดสอบหน่วยสำหรับส่วน GUI ที่ใช้ได้ทำการทดสอบทุกส่วนของชิ้นส่วนเหล่านั้นด้วยตนเอง

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

ลองดู:

Steven C. MCCONNELL: ทำงานอย่างมีประสิทธิภาพด้วยรหัสดั้งเดิมรุ่นที่สอง Microsoft Press, มิถุนายน 2004

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