อะไรคือวิธีที่ดีในการทำความสะอาดโครงการเก่า


11

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


การตัดสินใจแบบไหนที่คุณไม่เห็นด้วยในวันนี้?

คำตอบ:


21

คุณมีสามตัวเลือกพื้นฐาน:

  1. หากแอพมีขนาดเล็กมากและยุ่งมากการเริ่มต้นใหม่อาจเป็นทางออกที่ดีที่สุดของคุณ

  2. refactor

  3. อยู่กับความยุ่งเหยิงและแฮ็คในคุณสมบัติเพิ่มเติม

โดยทั่วไปตัวเลือก (2) เป็นทางออกที่ดีที่สุดของคุณ

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

  1. มีเวลา / งบประมาณเท่าไหร่
  2. คุณคาดหวังว่าจะมีการปรับเปลี่ยนในอนาคตเท่าไหร่
  3. ใครบ้างที่จะเห็นรหัส (เช่น. รหัสยุ่งจะทำลายชื่อเสียงของคุณหรือไม่)
  4. ทุกคนคาดว่าจะรักษารหัสหรือไม่
  5. มีเครื่องมือการปรับโครงสร้างใหม่ใดที่พร้อมให้ความช่วยเหลือแก่คุณ
  6. คุณมีประสบการณ์ในการปรับโครงสร้างใหม่อย่างไร
  7. คุณจะได้รับประสบการณ์อะไรบ้างจากการเปลี่ยนโครงสร้าง?
  8. การปรับโครงสร้างชนิดใดจะให้ประโยชน์มากที่สุดแก่คุณ
  9. มีการทดสอบอัตโนมัติใดอยู่แล้ว จะต้องมีการเขียน?
  10. การทดสอบด้วยตนเองจะต้องใช้เท่าไหร่?
  11. คุณจะรู้สึกอย่างไรถ้าคุณปล่อยรหัสตามเดิม?

จากประสบการณ์ของฉันมันเป็นเรื่องง่ายมากที่จะเข้าไปยุ่งเหยิงอย่างเหมาะสมในระหว่างการฟื้นฟู บทเรียนที่สำคัญที่สุดที่ฉันได้เรียนรู้คือ:

  1. ทำสิ่งหนึ่งในเวลา
  2. ทำตามขั้นตอนเล็ก ๆ
  3. ใช้ประโยชน์จากแหล่งควบคุมของคุณ (เช็คอินบ่อย ๆ + รวมความคิดเห็น)
  4. ใช้ประโยชน์จากเครื่องมือการเปลี่ยนโครงสร้างอัตโนมัติ
  5. รู้จัก IDE

6
ฉันยังต้องการที่จะเพิ่มเพื่อหลีกเลี่ยงการเสียสถานะนานเกินไป ฉันเคยเห็นโครงการโอเพ่นซอร์สหลายโครงการกำลังจะตายอย่างรวดเร็วในระหว่างการเขียน / ออกแบบใหม่ที่มีความทะเยอทะยาน โครงการที่ไม่ทำหน้าที่ฆ่าแรงจูงใจได้อย่างรวดเร็ว
LennyProgrammers

2
อย่างแน่นอน เกี่ยวกับการเขียน / ออกแบบใหม่ที่มีความทะเยอทะยานฉันตกหลุมนี้มากกว่าหนึ่งครั้ง ตอนนี้ฉันพยายามทำสิ่งต่าง ๆ เป็นขั้นตอนเล็ก ๆ ฉันได้เพิ่มข้อเสนอแนะนี้ในคำตอบของฉัน
Kramii

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

1
@TMN: ตามหลักแล้วใช่ อย่างไรก็ตามคุณไม่จำเป็นต้องทำการทดสอบอัตโนมัติเสมอไป (1) หากรหัสได้รับการพัฒนาโดยไม่มีการทดสอบแบบอัตโนมัติมันอาจจะไม่ง่าย / เป็นไปได้ที่จะทำการทดสอบย้อนหลังจนกว่าคุณจะทำการปรับโครงสร้างใหม่แล้ว (2) การเขียนแบบทดสอบอาจมีค่าใช้จ่ายสูงก่อนทำการเปลี่ยนแปลงเล็กน้อย (3) เครื่องมือ refactoring อัตโนมัติ + คุณสมบัติ IDE สามารถช่วยป้องกันการแตกหักของรหัสอันเป็นผลมาจากการ refactoring
Kramii

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

5

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


1
นี่คือกฎ Boyscout ที่มีชื่อเสียง: ปล่อยให้รหัสอยู่ในสถานะที่ดีกว่าที่คุณพบ
Jörg W Mittag

2

เวลานี้ในขณะที่แก้ไขสิ่งต่าง ๆ ให้แน่ใจว่าเอกสาร ครั้งต่อไปคุณจะเห็นรหัสมันจะง่ายกว่ามากในการจำสิ่งต่าง ๆ


1

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.