เนื่องจากทำการ review code ของระบบที่พัฒนาด้วยภาษา Swift แล้วพบว่าการสร้าง object บางตัวนั้น สามารถสร้างได้หลายแบบ ทำให้มี constructor จำนวนมาก !! ซึ่งมันเป็น Code Smell อย่างหนึ่ง ดังนั้นได้เวลาปรับปรุง code ให้ดีขึ้นแล้วนะ
refactoring Archive
เมื่อนักพัฒนาไม่สามารถควบคุมความซับซ้อนของ code ได้ !!
จากบทความเรื่อง Why it happens to your code again and again? อธิบายการพัฒนาระบบ web application ด้วย RoR (Ruby on Rails) ซึ่งเป็น framework หลักของการพัฒนาระบบด้วยภาษา Ruby โดยในช่วงแรกของการพัฒนาระบบนั้นจะราบรื่นและรวดเร็ว ไม่ว่าจะเป็นการเพิ่ม gem หรือ library ต่าง ๆ เข้าไป ทุกอย่างมันแจ่มมาก ๆ แต่เมื่อเวลาผ่านไปเรากลับพบว่า
วิวัฒนาการจาก Spaghetti Driven Development ถึง Test-Driven Development
Spaghetti Driven Development มันเป็นอย่างไร ? เป็นอีกหนึ่งวิธีการของการพัฒนา software !! โดยมีขั้นตอนดังนี้ เขียน code โครตแย่ออกมา ทำการ refactor code ให้ code ดีขึ้นและเข้าใจได้ง่ายขึ้น ทำการเขียนชุดการทดสอบ ฟังแล้วมันดูดีมาก แต่ส่วนใหญ่มักจะทำเพียงขั้นตอนแรกเท่านั้น จึงทำให้เกิด Spaghetti code ออกมาจำนวนมาก และไม่มีใครกล้าแตะต้องมัน ใจร้ายกันมาก ๆ
ทำไม Developer ต้องทำการ Refactor Test ด้วย ?
ผมเชื่อว่า Developer ทุกคนทำการทดสอบสิ่งที่ตัวเองสร้าง แต่ Developer บางคนอาจจะไม่เขียน test ขึ้นมา (Manual test) แต่ Developer หลายคนอาจจะเขียน test ขึ้นมา ( Automated test ) เพื่อทำการตรวจสอบสิ่งที่กำลังแก้ไข ว่าทำงานได้อย่างถูกต้อง เพื่อทำให้มีความมั่นใจต่อระบบที่กำลังพัฒนา แต่ปัญหาที่มักพบเจอมาก ๆ สำหรับ Testa ก็คือ Developer มักจะไม่ค่อยสนใจ test มากเท่าไร Developer มักจะไม่ทำการ refactor test เลย Developer ไปสนใจเพียง production code เท่านั้น สุดท้าย test มันกลับก่อให้เกิดปัญหาตามมา ดังนั้น เรามา refactor test กันหน่อยดีไหม
Developer ควรรู้ว่าเมื่อใดต้องทำการ refactor code
เมื่อระบบงานมีจำนวน feature มากขึ้น Developer ก็ยิ่งเขียน code มากขึ้นเท่านั้น ส่งผลให้ code ในระบบมีความซับซ้อนขึ้นอย่างต่อเนื่อง ดังนั้น เราควรหยุดคิด และ พิจารณา code กันหน่อยไหม เนื่องจากยิ่งนับวันค่าใช้จ่ายสำหรับการดูแลจัดการ code ยิ่งสูงขึ้น ทั้งจาก code ที่มันแย่ ๆ ทั้งจาก code ที่มันดูสวยหรู หรือ เกินจริง กรณีที่เราพบเห็นได้ทั่วไปก็คือ การนำ design pattern มาใช้กันตั้งแต่เริ่มต้น บ่อยครั้งมันคือ การที่ออกแบบเกินกว่าความต้องการจริงหรือว่าการเผื่อนั่นเอง
Eventual crappiness มันคืออะไร และ จะป้องกันอย่างไรดี ?
วันนี้ได้อ่านบทความเรื่อง How to prevent eventual crappiness ซึ่งได้อธิบายไว้ว่า Eventual crappiness – eventually all software will become crap มาดูกันว่ามันคืออะไร ? มีข้อเสียอะไรบ้าง ? และเราสามารถป้องกันได้อย่างไร
Compose Method คือสิ่งที่ developer ควรรู้ และ นำไปใช้งาน
ช่วงนี้ทำการ review code ของทีมพัฒนาบ้างเล็กน้อย จึงมีคำแนะนำ สำหรับการ Refactor code หรือปรับปรุงโครงสร้าง code ให้ดีขึ้น ทั้งเรื่องของการตั้งชื่อและโครงสร้างที่เหมาะสม โดยวิธีการพื้นฐานที่ง่ายสุด ๆ สำหรับการ Refactor code คือ Compose Method ดังนั้น มาทำความรู้จักกันหน่อยว่ามันเป็นอย่างไร
คำถาม :: ทำการ Refactor พวก Legacy code เมื่อไรดี ?
สิ่งเล็ก ๆ ที่เรียกว่า Legacy code นั้น มักเป็นสิ่งที่ไม่มีใครชอบ แต่แปลกนะว่า มักจะมีคุณค่า หรือ สร้างรายได้ให้กับองค์กร !! จำนวนของ Legacy code นั้นมักมีจำนวนมากมาย เกินกว่าที่เราจะจัดการมันได้ ดังนั้นเราจะตัดสินใจอย่างไรว่า code ส่วนไหน ต้องทำการ refactor ? code ส่วนไหน ไม่จำเป็นต้อง refactor ? ถ้าระบบงานมันทำงานได้ดีอยู่แล้ว จะต้องทำการ refactor หรือไม่ ? ยิ่งกว่านั้นการ refactor code มันมีความเสี่ยง และ ค่าใช้จ่ายสูง ดังนั้น เราต้องการมีตัวช่วยหน่อยสิว่า เมื่อไรควรที่จะ refactor ดี
Duplication code มันโหดร้ายนะ มาลดกันเถอะ !!
คุณ Robert C. Martin หรือ Uncle Bob กล่าวไว้ว่า “Duplication may be the root of all evil in software.” ดังนั้นในฐานนะของนักพัฒนา software เมื่อพบเจอว่า code ส่วนไหนที่มัน duplicate หรือ ซ้ำซ้อน กัน ก็ควรกำจัด code ส่วนนั้นออกไปจากระบบ แต่สิ่งที่เราพบเจอในโลกความเป็นจริง คือ ทุกๆ ระบบมี code ที่มัน duplicate จำนวนมากมาย มันหมายความว่าอะไรกัน
ตัวอย่างการ refactoring ด้วย Rule of Three
จาก blog เรื่องของ Refactoring Rule of Three นั้น อธิบายไปอาจจะเห็นภาพไม่ชัดเจนเท่าไรนัก ดังนั้น เรามาลองเขียน code กันดีกว่า … โดยเป้าหมายคือ จะทำการแยกส่วนการทำงานที่มันซ้ำกัน 3 ครั้งออกไปจาก code ของเรา มาเริ่มกันเลย !!