ฉันต้องการถามคำถามเกี่ยวกับรหัสสกปรก มีผู้เริ่มต้นบางคนที่เขียนรหัสในโครงการขนาดกลาง รหัสเป็นลูกบอลโคลนขนาดใหญ่มาก พวกเขาไม่ใช่โปรแกรมเมอร์ขั้นสูง พวกเขารู้วิธีใช้คีย์บอร์ดเล็กน้อยเกี่ยวกับจาวา พวกเขาเพิ่งเขียนโค้ดที่มี 12,000 บรรทัดในชั้นเรียนหลัก แต่ 6,000 บรรทัดเป็นของ NetBeans

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

ตอนนี้ฉันมีคำถามต่อไปนี้:

1. เราควรซ่อมแซมรหัสและเปลี่ยนเป็น OOP หรือไม่ ตอนนี้เรากำลังแก้ไขข้อบกพร่อง
2. รหัสไม่มีความคิดเห็นไม่มีเอกสารไม่มีรูปแบบการเขียนโปรแกรมเฉพาะและอื่น ๆ การเปลี่ยนมันมีราคาแพงและใช้เวลามาก เราจะทำอะไรได้บ้างกับเรื่องนี้?
3. ฉันจะสอนพวกเขาให้ปฏิบัติตามกฎทั้งหมดได้อย่างไร (ความคิดเห็น OOP คุณภาพของโค้ดที่ดี ฯลฯ )
4. รหัสผิดพลาดและเกิดข้อผิดพลาดได้ง่าย อะไรที่พวกเราสามารถทำได้? การทดสอบ? เราเกือบจะเขียนกระดาษ A4 สองหรือสามเล่มเพื่อแก้ไข แต่ดูเหมือนไม่มีที่สิ้นสุด

ฉันต้องบอกว่าฉันใหม่กับพวกเขา ฉันคิดว่าฉันได้ทำผิดกฎเกี่ยวกับการเพิ่มคนสายเกินไปในโครงการเช่นกัน คุณคิดว่าฉันต้องจากไปหรือไม่?

ขั้นตอนที่ 0: สำรองข้อมูลไปยัง SCM

เพราะตามคำแนะนำของ JBRWilkinson ในความคิดเห็นการควบคุมเวอร์ชันเป็นด่านแรกของคุณในการป้องกันภัยพิบัติ (ย้อนกลับไม่ได้)

ทำรายละเอียดการกำหนดค่าซอฟต์แวร์สำรองข้อมูลขั้นตอนการสร้างสิ่งส่งมอบ ฯลฯ ...

ขั้นตอนที่ 1: ทดสอบก่อน

จากนั้นเริ่มต้นด้วยการเขียนแบบทดสอบ :

• สำหรับสิ่งที่ทำงาน
• และสำหรับสิ่งที่ล้มเหลว

ไม่ว่าคุณจะตัดสินใจทำอะไร ตอนนี้คุณสามารถ:

• เริ่มจากศูนย์และเขียนใหม่
• หรือแก้ไขมัน

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

ขั้นตอนที่ 2: ตรวจสอบและตรวจสอบ

ตั้งค่าระบบการรวมอย่างต่อเนื่อง (เพื่อเติมเต็มขั้นตอนที่ 0และขั้นตอนที่ 1 ) และระบบการตรวจสอบอย่างต่อเนื่อง (เพื่อเตรียมการสำหรับขั้นตอนที่ 4 )

ขั้นตอนที่ 3: ยืนบนไหล่ของยักษ์

(ตามที่คุณควร ... )

• การปรับโครงสร้างรูปแบบใหม่
• Refactoring: ปรับปรุงการออกแบบของรหัสที่มีอยู่
• ทำงานอย่างมีประสิทธิภาพด้วยรหัสดั้งเดิม (ตามคำแนะนำของ Jason Baker )
• refactoring

ขั้นตอนที่ 4: ทำความสะอาด

การเรียงลำดับนั้นไปโดยไม่บอก แต่แทนที่จะอ่านรหัสตัวเองคุณอาจต้องการเรียกใช้ linters / static analyzers และเครื่องมืออื่น ๆ บน codebase ที่เสียหายเพื่อค้นหาข้อผิดพลาดในการออกแบบและการนำไปใช้งาน

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

ขั้นตอนที่ 5: ตรวจสอบ

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

ขั้นตอนที่ 6: พิสูจน์กระบวนการพัฒนาของคุณในอนาคต

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

แต่จริงๆการทดสอบ จำนวนมาก

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

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

หากซอฟต์แวร์ใช้งานไม่ได้จริง ๆ (มีข้อบกพร่องจำนวนมากข้อกำหนดที่ไม่ชัดเจน ฯลฯ ) ดีกว่าการเขียนใหม่ตั้งแต่ต้น เช่นเดียวกันถ้ามันค่อนข้างเล็ก

จุดในการปรับโครงสร้างใหม่ (เช่นเดียวกับในหนังสือของ Fowler และ Kerievsky หนึ่งhttp://www.industriallogic.com/xp/refactoring/ ) คือการทำให้ระบบใช้งานได้การซ่อมแซมอาจใช้เวลาสองครั้ง แต่ความเสี่ยงนั้นเป็นศูนย์

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

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

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

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

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

Nice Blog บอกว่าเพราะเหตุใด Netscape จึงหลวม

หากใช้งานได้ให้ทำการกำหนดใหม่ มีเครื่องมือที่จะช่วยคุณทำเช่นนั้น หากไม่ได้ผลให้ใช้คำสั่งการปรับปรุงรหัสเวทย์มนตร์เช่นdeltreeใน Windows resp rm -rfบน Linux

เราควรซ่อมแซมรหัสและเปลี่ยนเป็น OOP หรือไม่ ตอนนี้เรากำลังแก้ไขข้อบกพร่อง [... มีข้อผิดพลาดไม่มีเอกสาร ... ]

ฉันอยู่ที่นั่นคุณมีความเห็นอกเห็นใจของฉัน ฉันยังเขียนบทความเกี่ยวกับเรื่องนี้ซึ่งอาจช่วยให้คุณได้รับมุมมอง แต่ในระยะสั้น:

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

ฉันจะสอนพวกเขาให้ปฏิบัติตามกฎทั้งหมดได้อย่างไร

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

คำแนะนำของฉันคือการรวมกันของคำตอบของ @ duros & @Manoj R

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

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