ในปี 2015 นี้ คุณในฐานนะที่เป็นนักพัฒนา software นั้น ถ้าให้เลือกทำ technical practice อย่างใดอย่างหนึ่ง เพื่อทำให้การพัฒนา software ดีขึ้น คุณอยากจะทำอะไร
refactoring Archive
แนวทางในการ Refactoring พวก Legacy code (Empirical Refactoring)
หลังจากที่ไปเรียนวิชา Working Effectively with Legacy code มา พบว่าสิ่งหนึ่งที่สำคัญมากๆ ในการอยู่ร่วมกับ Legacy code คือ การ refactoring code ซึ่งมิใช่การ rewrite code นะครับ ก่อนที่จะทำการ refactor พวก Legacy code นั้น เราควรที่จะมองไปที่ code เหล่านั้นก่อนเสมอ ว่าส่วนไหนที่มีปัญหาบ้าง และ ส่วนไหนไม่มีปัญหา อย่าลงมือ refactor code ทันทีที่ได้รับมอบหมายล่ะ เดี๋ยวจะซวย !!
Refactoring :: ทำไมเราต้อง Extract method ด้วยล่ะ ?
หลังจากทำการอธิบายการ Refactoring ด้วยวิธี Constructor Overloading ไปแล้ว เราไปดูวิธีการอื่นๆ บ้างว่ามีอะไรอีก ผมเชื่อว่า developer หลายๆ คน นั้นชอบที่จะสร้าง method เล็กๆขึ้นมา และมักจะสร้าง method ขึ้นมาเรื่อยๆ จนมั่นใจว่า code ที่อยู่ใน method นั้นมันสัมพันธ์ หรือ เป็นไปตามชื่อของ method หรือ อาจจะสร้าง method ใหม่ขึ้นมา เมื่อเจอ code ที่มันซ้ำซ้อนกัน เพื่อลดความซ้ำซ้อน ซึ่งวิธีการนี้ เป็นวิธีการหนึ่งในการ Refactoring code ชื่อว่า Extract Method ผมเชื่อว่า developer ทุกๆ คนทำใช่ไหม
Refactoring :: ง่ายๆ กับ Overload Constructor
หลังจากที่อธิบายเรื่อง Refactoring มาพอสมควรแล้ว ซึ่งการ Refactoring ควรทำแบบค่อยเป็นค่อยไป แต่ทำบ่อยๆ ถ้าเมื่อไรก็ตามที่ใช้เวลาในการ Refactoring นาน แสดงว่า code ของคุณนั้นไม่เคยทำการ Refactoring หรือ Review อะไรเลย ดังนั้นขอแนะนำให้ทำแบบเล็กๆ แต่บ่อยๆ ตัวอย่างการ Refactoring แรกที่จะแนะนำก็คือ Overload constructor
[แปล] Refactoring Manifesto
พอดีไปอ่านเจอ พบว่ามี Refactoring Manifesto ด้วย เขียนโดย Lasse Koskela และ Bas Vodde โดยได้รับแรงบันดาลใจมาจาก Repair Manifesto ดังนั้น จึงเอามาแปลในแบบของผม เผื่อใครสนใจจะเอาไปลองทำตามดูได้นะ มันสำคัญมากๆ สำหรับการพัฒนา Software
สัญญาณเตือน … ว่าทีมต้อง Refactoring code แล้วนะ
ในการพัฒนา software นั้น มักมีสิ่งที่เราไม่ต้องการเกิดขึ้นมาเสมอ นั่นก็คือ Technical Debt หรือ หนี้ทางเทคนิค เพราะว่า นักพัฒนาไม่ได้ทำตามแนวปฎิบัติของการเขียน code ที่ดี รวมทั้งไม่มีการทำ Refactoring code และ Code review อยู่อย่างเสมอ แต่เราจะรู้ได้อย่างไรว่าสิ่งที่พัฒนาอยู่มันเริ่มมีปัญหาแล้ว ดังนั้น เรามาดูสัญญาณเตือน ที่จะบอกว่า ทีม คุณต้องทำการ Refactoring code แล้วนะ !!!
เราควรนำการ Refactor code ไปใส่ใน Backlog หรือเปล่านะ
หลายๆ ต่อหลายครั้ง เมื่อพูดคุยเกี่ยวกับการ refactor code เพื่อทำให้ code มีโครงสร้างการทำงานที่ดีขึ้นกว่าเดิม คำถามที่มักจะเกิดขึ้นมา คือ งาน refactor code นี้ มันควรเป็น Story หนึ่งที่อยู่ใน backlog หรืองานจะต้องทำหรือไม่ มาดูคำตอบของผมว่าเป็นอย่างไร
Java :: มาลดความซ้ำซ้อนของการทำงานใน DAO ( Data Access Object )
ในการ review code ของทีม พบว่า ปัญหาเรื่องความซ้ำซ้อนของ code มีอยู่มากมาย หนึ่งในนั้นก็คือ code ที่ซ้ำซ้อนในส่วนของการติดต่อกับฐานข้อมูล ในโลกของภาษา Java นั้น เป็นปัญหาที่น่าจะเจอมากมาย สำหรับคนที่ยังใช้งานผ่าน JDBC (Java Database Conectivity) แบบเดิมๆ แต่ถ้าใครใช้งานผ่านพวก OR mapping และ Spring framework ก็น่าจะไม่ค่อยมีปัญหา แต่สิ่งที่น่าถามคือ คุณรู้หรือไม่ว่าด้านหลังมันทำงานหรือสร้างอย่างไร ? แต่ในบทความนี้จะเน้นเรื่องการ refactor code ส่วนของการติดต่อฐานข้อมูลผ่าน JDBC แบบเดิม ซึ่งมักจะถูกเรียกว่า DAO ( Data Access Object ) หรือว่า Repository ดังนั้นมาดูกันว่ามีขั้นตอนการลดความซ้ำซ้อนของ code ลงอย่างไร
ข้อแตกต่างระหว่าง Refactoring กับ Rewrite
ได้อ่านเอกสารเรื่อง Refactoring :: When Do i Start ? ของคุณ J. B. Rainsberger แล้วคิดว่าน่าจะมีประโยชน์ จึงได้ทำการสรุปออกมา โดยเน้นย้ำเรื่องของ refactoring คืออะไร และอธิบายความแตกต่างระหว่าง refactoring กับ rewrite ส่วนเรื่องอื่นๆ เอาไว้สรุปกันวันอื่น
แนวทางการ Refactoring Legacy Code
เนื่องจากเห็นว่ามีงานที่น่าสนใจคือ Legacy Code Retreat ดังนั้นจึงลองไปดูว่างานนี้มันเป็นอย่างไร รวมทั้งยังมีเทคนิคต่างๆ ในการจัดการกับ Legacy code อีกด้วย ดังนั้นมาลองดูกันว่าเราจะเริ่มต้นทำอะไรได้บ้าง