"Don't Repeat Yourself" เป็นความคิดมีค่าจากหนังสือมีค่าที่อ่านในอาชีพ software development ถ้า refactor duplicate code หาย คุณผลิต code ที่ general และ stable มากขึ้น แตตอนเริ่ม DRY up code จะเจอปัญหา: code จัดการ edge cases ไมดี code generalized เกินไปอ่านยาก หรือ code หายาก ถ้า refactoring ไปทาง DRY ไม่ได้ทุกครั้ง รู้ยังไงว่าควร refactor?
Too-DRY code มาจาก misunderstanding เกี่ยวกับ duplication ประเภทไหนที่ควร refactor ต้องแยก essential duplication และ accidental duplication
Essential duplication คือโค้ดที่แก้ class ของปัญหาที่ทำอยู่ duplication ประเภทนี้ ต้อง kill ทันที
Accidental duplication คือ duplication ไม่เกี่ยวกับปัญหา "duplication by coincidence" ถ้าทำความสะอาด accidental duplication aggressive เกินไป จะได้ brittle code ที่ต้อง un-refactor ตอนเพิ่ม cases ใหม่
แตแยกได้ยังไง? ด้วยประสบการณ์ อาจดีขึ้น แตหลายทศวรรษเขียนโค้ด ยังทำไม่ถูกครึ่งหนึ่ง โชคดีมี general rule ช่วยเยอะ: Three Strikes and You Refactor
ครั้งแรกทำ ให้ทำไปเลย
ครั้งที่สองทำคล้ายกัน หนาวใจที่ duplication แตทำ duplicate อยู่ดี
ครั้งที่สามทำคล้ายกัน Refactor
เห็นไหมว่าทำไมช่วย? ครั้งที่สาม ควรเริ่มเห็น patterns ควรมีไดอะว่า duplicate code ไหน necessary สำหรับแก้ปัญหา และไหนแค่ coincidentally เหมือนกัน เริ่ม generalize (DRY up) แค่ code ที่ fundamentally เหมือนกันทุก instance ของปัญหา
คิดดูคราวสุดท้ายที่ refactoring ทำเจ็บปวด คุณพยายาม DRY up สิ่งที่ duplicate ระหว่าง 2 copies แต copy ที่ 3 แค่ต่างนิดหน่อย?
และครั้งต่อไปที่รู้สึกต้อง duplicate code ลองรอ copy ที่ 3 ก่อน refactor (มันยากและรู้สึกแย่ แตปิดตาลองดู) แล้วคิดตอน DRY up คุณ refactor ต่างจากตอน refactor ทันทีหลัง copy ที่ 2 ไหม?
