วันนี้เจอ code ที่เขียนด้วยภาษา Swift ที่น่าสนใจ เกี่ยวกับการใช้งาน protocol แถมเจอบทความอธิบายเรื่องนี้ด้วย Protocol Composition เลยนำมาสรุปกับ code ที่พบเจอด้วยเลย โดย code เหมือนจะดูดีนะ แต่มีหลายเรื่องที่สามารถปรับปรุงให้ดีขึ้นได้ มาเริ่มกันเลย
clean-code Archive
วันนี้นักพัฒนาเขียน TODO และ FIXME ใน code แล้วหรือยัง ?
วันนี้นั่งดู code ช่วงบ่ายในขณะที่ฝนกำลังถล่ม กทม เจอชุด comment ที่น่าสนใจ ซึ่งนักพัฒนาทุกคนน่าจะเคยเห็นผ่านตามาแล้ว ทั้งเกิดจากการ generate แบบอัตโนมัติจาก IDE ทั้งเขียนจากคนอื่น รวมทั้งตัวเราเองด้วย นั่นคือ TODO และ FIXME คำถามที่น่าสนใจคือ มันคืออะไร ? เขียนไว้ทำไม ? ทำไมไม่มีใครมาลบมันออก ? มาหาคำตอบกัน
มาเขียน code ที่ดีกว่าเดิมกันดีกว่า
ช่วงวันหยุดยาวของผมคนเดียว ได้นั่งอ่าน นั่งเขียน code บ้างเล็กน้อย และเมื่อกลับไปอ่านและแก้ไข code เก่า ๆ ก็พบปัญหาต่าง ๆ มากมาย ทั้ง ๆ ที่เราคิดว่ามันดีแล้วนะ เมื่อลองนั่งคิดดูว่า นี่เป็น code ที่เราเขียนไว้ใช้งานเองยังขนาดนี้ ถ้าเป็น code ที่ดูแลกันหลายคนหรือเป็นทีม มันจะลำบากเพียงใด ดังนั้นจึงลองแก้ไข และ สรุปสิ่งที่ควรจะทำ เพื่อช่วยให้ code ของทีมดีขึ้น มาดูกันหน่อย
แค่คำว่า Good Enough มันคงยังไม่พอนะ !!
ในการพัฒนา software นั้น นักพัฒนาต้องการวิธีที่ เร็วที่สุดเท่าที่จะทำได้ สั้นที่สุดเท่าที่จะทำได้ ใช้ค่าใช้ง่ายน้อยที่สุดเท่าที่จะทำได้ แต่สิ่งที่ขาดไปไม่ได้เลยคือ คุณภาพที่ดี (ซึ่งมักถูกมองข้ามหรือตัดทิ้งไป) ยิ่งกับ source code ยิ่งสำคัญมาก ๆ คำถามที่น่าสนใจคือ เราให้ความสำคัญต่อคำว่าคุณภาพของ code ที่สร้างขึ้นมาหรือไม่ ? หรือว่าแค่ให้มันทำงานได้ดีก็พอแล้ว ? เราเห็นถึงความสำคัญของการดูแลรักษาในระยะยาวหรือไม่
ทำไม Developer ควรให้เวลากับการลบ code ของตัวเองทิ้งไปบ้าง ?
Developer ทุกคนต้องเขียน code Developer รู้ดีกว่าการเขียน code ที่ดีเป็นอย่างไร Developer รู้ดีกว่าการเขียน code ที่ไม่ดีเป็นอย่างไร ดังนั้น Developer จำเป็นต้องพัฒนาและปรับปรุงการเขียน code อยู่ตลอดเวลา แต่ Developer รู้ไหมว่า เวลาส่วนใหญ่ที่ใช้ไปนั้น กลับเป็นการกลับไปแก้ไขและลบ code เก่าที่เคยเขียนไว้ ? ถ้าเป็นแบบนี้จริง ๆ แสดงว่า เราสูญเสียเวลาไปมากมาย ให้กับ code ที่ต้องถูกลบทิ้ง หรือ เขียนใหม่ !!! ทำไมนะ
Clean Code หนังสือที่นักพัฒนาควรอ่าน
วันนี้มี developer มาถามเรื่องหนังสือเกี่ยวกับ programming ว่าควรจะอ่านหนังสืออะไรบ้าง ? เล่มแรกที่ผมแนะนำให้อ่านก็คือ Clean Code – A Handbook of Agile Software Craftsmanship ในหนังสือเล่มนี้อธิบายแนวปฏิบัติที่ดีสำหรับการพัฒนา software ถึงแม้ว่าหนังสือจะเก่าหน่อย แต่เนื้อหาส่วนใหญ่ยังแจ่มมาก ๆ ปล. เป็นหนังสือที่นักพัฒนาต้องอ่านกันเลยนะ ดังนั้นจึงทำการสรุปเนื้อหาหลัก ๆ ไว้นิดหน่อย
คำถาม :: Developer ทำการแบ่ง package ของระบบกันอย่างไร ?
จากบทความเรื่อง Package by feature, not layer อธิบายถึงการแบ่ง package ต่าง ๆ ในระบบงาน ซึ่งเป็นสิ่งที่สำคัญมาก ๆ เป็นงานที่ทีมพัฒนาต้องช่วยกัน เป็นงานที่ทีมพัฒนาต้องตัดสินใจร่วมกัน ว่าต้องการให้โครงสร้างของระบบเป็นอย่างไร ? แน่นอนว่า ส่งผลต่อการพัฒนาระบบอย่างแน่นอน
ลด ละ เลิก การสร้าง Logging application กันเถอะ !!
ในการสร้างระบบงานนั้น สิ่งหนึ่งที่ขาดไปไม่ได้เลยคือ logging การทำงานต่าง ๆ ของระบบ ดังนั้นทำให้เกิด code ที่เกี่ยวกับ logging จำนวนมาก เผลอ ๆ อาจจะมากกว่า code ส่วนอื่น ๆ ของระบบอีกต่างหาก ซึ่งผมชอบเรียกระบบเหล่านี้ว่า Logging application !! ผลที่ตามมาก็คือ code อุดมไปด้วย log อ่านยากมาก ๆ code จะทดสอบยากมาก ๆ บ่อยครั้งไม่สามารถเขียน unit test ได้เลย code ดูแลยากอีก !! ดังนั้นนักพัฒนาควรใส่ใจวิธีการจัดการ log มาก ๆ ด้วยนะ มาดูกันว่าทำอย่างไรได้บ้าง
5ส สำหรับการพัฒนา software
คิดว่า developer หลาย ๆ คนน่าจะรู้จักกับ 5ส หรือ 5S 5S was developed in Japan and was identified as one of the techniques that enabled Just in Time manufacturing ซึ่งประกอบไปด้วย Seiri หรือ Sort/Clearing/Classify หรือ สะสาง Seiton หรือ Systematic Arrangement/Streamline/Simplify/Configure หรือ สะดวก Seiso หรือ Shine/Cleanliness/Clean and check หรือ สะอาด Seiketsu หรือ Standardize/Conformity หรือ สร้างมาตรฐาน Shitsuke หรือ Sustain the [&hellip
Write clear code, NOT clever code
จากหนังสือ Practice of an Agile Developer มีคำแนะนำเกี่ยวกับวิธีการปรับปรุงความสามารถของ developer มากมาย ทั้ง soft skill และ technical skill แต่มีประโยคหนึ่งในหนังสือเล่มนี้ที่น่าจะโดนมาก ๆ คือ Write clear code, NOT clever code เป็นความสามารถที่สำคัญมาก ๆ ของ developer ควรจะมีไว้