การแพร่กระจายรหัสที่มีความคิดเห็น refactoring เป็นความคิดที่ดี?


11

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

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

class RefactoredClass {
    private SingletonClass xyz;

    // I know SingletonClass is a Singleton, so I would not need to pass it here.
    // However, I would like to get rid of it in the future, so it is passed as a
    // parameter here to make this change easier later.
    public RefactoredClass(SingletonClass xyz) {
        this.xyz = xyz;
    }
}

หรือเค้กอีกชิ้น:

// This might be a good candidate to be refactored. The structure is like:
// Version String
//    |
//    +--> ...
//    |
//    +--> ...
//          |
//    ... and so on ...    
//
Map map = new HashMap<String, Map<String, Map<String, List<String>>>>();

นี่เป็นความคิดที่ดีหรือไม่? ฉันควรจำอะไรเมื่อทำเช่นนั้น?



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

2
HashMap <String, Map <String, Map <String, List <String> >>>: o
margabit

5
ความคิดเห็นที่บอกฉันว่าทำไมโค้ดบางส่วนถึงมีกลิ่นเหม็นเป็นที่นิยมอย่างมาก ฉันอาจไม่เข้าใจ codebase ของคุณดังนั้นฉันแค่จะเห็นปัญหาและคิดว่า "What fuck?" แต่ความคิดเห็นอธิบายว่าทำไมมันเป็นเพราะมันจะช่วยให้ฉันได้รับรหัสเร็วขึ้น ใช่ทำอย่างนี้มาก (สมมติว่าคุณไม่สามารถแก้ไขรหัสให้ไม่ใช่ WTF แน่นอน!)
Phoshi

คำตอบ:


13

การแพร่กระจายรหัสที่มีความคิดเห็น refactoring เป็นความคิดที่ดี?

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

ฉันควรจำอะไรเมื่อทำเช่นนั้น?

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


2

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


[แก้ไข] BTW: นี่เป็นความคิดที่ดี:

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

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


ข้อมูลโค้ดในคำถามอ่านเช่น Java ทำไมคุณถึงแนะนำ Doxygen
ริ้น

ฉันรู้ว่า doxygen รองรับ @todo - สำหรับ javadoc ฉันไม่แน่ใจ - แต่ภาษานั้นสำคัญจริงๆเหรอ? จากมุมมองของฉันตัวอย่าง java แสดงปัญหาที่ลึกกว่า
Wolf

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