หลายๆ ต่อหลายครั้ง เมื่อพูดคุยเกี่ยวกับการ refactor code
เพื่อทำให้ code มีโครงสร้างการทำงานที่ดีขึ้นกว่าเดิม
คำถามที่มักจะเกิดขึ้นมา คือ งาน refactor code นี้
มันควรเป็น Story หนึ่งที่อยู่ใน backlog หรืองานจะต้องทำหรือไม่
มาดูคำตอบของผมว่าเป็นอย่างไร
คำตอบของผมคือ มันไม่ควรนำมาใส่ใน Backlog หรือ ใบงานเลย
เหตุผลเป็นดังนี้ โดยไปเจอการอธิบายในทำนองเดียวกันที่ xprogramming.com
ซึ่งอธิบายไว้อย่างละเอียดดังนี้
เริ่มต้นกันเลยดีกว่า
ถ้าเราดูตั้งแต่เริ่มต้นระบบงาน จะพบว่า code ของเรามันสะอาดและดูดีมากๆ
ทุกๆ อย่างมันดูดีมากมาย เป็นไปได้อย่างสายหรู ดังรูป
เมื่อเราเพิ่มความสามารถต่างๆ เข้าไป
ในช่วงนี้จะเป็นไปอย่างราบรื่น
อาจจะเกิด code ที่อาจจะไม่สวยงามเล็กน้อย แต่มันก็ยังดูดีอยู่นะ
เราจะรีบเร่งในการผลิตงานออกมาอย่างมาก
โดยที่ไม่มีตั้งข้อสังเกต หรือ การสะกิดเตือนว่า code มันน่าจะไปในทางที่ผิดนะ
แสดงได้ดังรูป
เมื่อเราสร้างระบบงานขึ้นมาเรื่อยๆ จะพบว่า
มันเริ่มแบ่งการทำงานออกเป็นส่วนๆ หรือ modular
ซึ่งมันก็ดู ok นะ ว่าป่ะ ดังรูป
เมื่อทำการเพิ่มความสามารถใหม่ๆ เข้าไป บน code เดิม ก็ดูดีนะ ไม่แย่อะไรนะ
เราไปต่อกันได้เลย ตามรูป
เวลาผ่านไปเรื่อยๆ
ระบบที่สร้างเริ่มมีความสามารถเยอะขึ้น แบ่งเป็นระบบย่อยๆ จำนวนพอสมควรดังรูป
มาถึงตรงนี้ เมื่อเราต้องการเพิ่มความสามารถต่างๆ เข้าไป
มันเริ่มเกิดอาการแปลกๆ เช่น เราส่งมอบหรือพัฒนาช้าลง
เราเริ่มให้ความระวังในการพัฒนามากขึ้น
เนื่องจากเริ่มหวาดกลัวว่า สิ่งที่แก้ไขหรือเพิ่มเข้าไปมันจะกระทบส่วนอื่นๆ หรือไม่
โดยส่วนต่างๆ ของระบบ เริ่มหนาแน่นขึ้น
ขั้นตอนการทำงานเริ่มยุ่งยากขึ้น ดังรูป
มาถึงตรงนี้ระบบงานและความสามารถในส่วนต่างๆ เริ่มเพิ่มขึ้น ด้วยอัตราเร็วที่ช้าลงไปมาก
เราเจอปัญหานะ แต่ต้องรีบทำด้วยเวลาที่จำกัดบน code ของระบบที่มีปัญหา
มาถึงตรงนี้ เริ่มเกิดปัญหาเรื่องการดูแลรักษา code ที่พัฒนาขึ้นมาแล้วสิ
แต่ยังต้องเพิ่มความสามารถต่างๆ ไปให้มันไม่มีหยุดหย่อน ดังรูป
ปัญหาต่างๆ ในการพัฒนาระบบ ยิ่งเพิ่มมากขึ้นเรื่อยๆ
และส่งผลกระทบต่อเวลาในการพัฒนา เพิ่ม แก้ไข ความสามารถใหม่ๆ เข้ามา
ซึ่งมาถึงตอนนี้ ทีมพัฒนาเริ่มโหยหาวิธีการ refactor code
เพื่อทำให้ code กลับมาดูดี สะอาด อีกครั้งหนึ่ง
โดยสิ่งที่ทีมมักจะทำก็คือ การพยายามขอเวลาจากเจ้าของ product ( Product Owner/Stackholder )
เพื่อทำการ refactor code
แต่คำตอบที่มักจะได้กลับมาคือ ไม่ได้นะฮ่ะคุณ
ถ้าโดนถามเรื่องเวลาในการ refactor code ทั้งหมดนั้นจะใช้เวลาเท่าไร
หนึ่งอาทิตย์ หลายอาทิตย์ หนึ่งเดือน …
เชื่อเถอะว่า ทำเท่าไรมันก็ไม่ดีขึ้นหรอก หรือเสร็จทั้งหมดหรอกนะ
เพราะว่า มันเป็นการ refactor code ที่ใหญ่มากๆ
มันยากมากๆ ที่คุณจะขายให้เจ้าของ product ซื้อหรือเลือกในสิ่งที่คุณพยายามจะเสนอ
หรือถ้าขายได้ ก็ไม่ได้ตามที่คุณตั้งความหวังหรือคำมั่นสัญญาไว้หรอกนะ
ดังนั้น วิธีการนี้คงไม่ใช่ทางเลือกที่ดีอย่างแน่นอน
มันจะได้ผลดังรูปนะ คือ เลอะเทอะน่าดู
แล้วเราควรทำอย่างไรดีล่ะ ?
วิธีการที่เรียบง่ายที่สุด คือ
เมื่อเราต้องเพิ่มความสามารถใหม่ๆ เข้าไปยังระบบ แทนที่เราจะพัฒนาเพื่ออ้อมส่วนต่างๆ ของระบบ
ให้พยายามเข้าไปแก้ไขตรงที่ระบบมันควรจะทำงานด้วยจริงๆ
มันจะทำให้เราเห็นว่า code ส่วนนั้นมันแย่นะ
ดังนั้นก็ทำการแก้ไขและปรับปรุงมันให้ดีขึ้นซะ
ซึ่งมันเป็นวิธีการดีที่สุดสำหรับการพัฒนา software
โดยทำมันไปแบบนี้ทุกๆ ครั้งไป แล้วมันจะช่วยทำให้ระบบเราดีขึ้นเอง
ส่งผลให้เราทำงานได้รวดเร็วขึ้นอีกด้วย
แสดงดังรูป
ดังนั้นเราจะทำการ refactor code ไปทีละเล็กๆ ตามงานที่รับเข้ามา
ซึ่งเราจะใช้เวลาไปกับมันไม่มาก ดีกว่า เอาเวลาไปสร้างสิ่งที่ผิดๆ ขึ้นมา
โดยเวลาที่ใช้ไปอาจจะน้อยกว่าที่คิดก็ได้นะเออ
เพราะว่า บางงานต้องกลับมาใช้ code ส่วนที่เราทำการ refactor ให้ดีไปแล้ว ดังรูป
แนวทางนี้จะเรียกว่า Incremental Refactoring นะ
ซึ่งน่าจะพอทำให้เห็นแล้วนะครับว่า การ refactor code มันไม่ใช่งาน
แต่มันคือสิ่งที่นักพัฒนาทุกๆ คนควรทำอยู่แล้ว
และต้องทำอยู่เป็นปกติด้วย
ให้จำไว้ว่า Later is Never ครับ
โดยสรุปแล้ว
สิ่งที่เราสร้างขึ้นมามันควรดีกว่าเดิมอยู่เสมอ
Code ควรสะอาดและดีดีอยู่เสมอ หรือ ยึดแนวคิด Clean Code ไว้
แล้วมันจะทำให้เรา สามารถผลิตและส่งมอบงานได้ตรงและมากขึ้นกว่าเดิม
ซึ่งมันทำให้ชนะกันทุกๆ ฝ่ายครับ
