อ่านบทความเรื่อง Honest Code ซึ่งเขียนมาตั้งแต่ปี 2005 มีใจความสำคัญว่า Code ส่วนไหนที่ไม่ถูกเรียกใช้งานจากส่วนอื่นก็ควรลบทิ้งไปซะ Code ส่วนไหนที่ไม่ถูกใช้งานจากผู้ใช้งานก็ควรลบทิ้งไปซะ ให้เหลือ code ที่จำเป็นเท่านั้นจริง ๆ จะได้ไม่ต้องมาเสียเวลากับ code ที่ไม่ใช้งาน ดังนั้นจึงนำมาแปลและสรุป ตลอดจนหาข้อมูลเพิ่มเติมบ้าง
มีคำถามที่น่าสนใจมาก ๆ คือ เราต้องทำอย่างไรบ้างเพื่อดูแลรักษาคุณภาพของ code ? เราต้องทำอย่างไรบ้างเพื่อปรับปรุงคุณภาพของ code ให้ดีขึ้น ? ลองมาหาตอบคำถามกันหน่อยสิ
ค่ำนี้อ่าน slide เรื่อง Idiomatic Go Tricks จากงาน Go UK Conference ซึ่งมีคำแนะนำดี ๆ เกี่ยวกับการเขียน code มากกว่าการเขียน code ให้เสร็จ ๆ ไป เพื่อทำให้ code ดูแลรักษาได้ง่าย ประกอบไปด้วยสิ่งต่าง ๆ ดังต่อไปนี้
อ่านเจอบทความเรื่อง 3R principles of programming เป็นแนวปฏิบัติ 3 อย่างเพื่อช่วยทำให้ code ที่เหล่านักพัฒนา software สร้างขึ้นมา มีความ clean มีความง่ายต่อการอ่าน มีความง่ายตอการทำความเข้าใจ มีความง่ายต่อการดูแลรักษา ไม่ซับซ้อนมากนัก จึงทำการแปลและสรุปส่วนที่น่าสนใจมานิดหน่อย
ปัญหาอย่างหนึ่งสำหรับการเขียน code ของเหล่านักพัฒนาคือ เมื่อติดปัญหาหนึ่ง ๆ แล้วมักจะลากยาว จากนั้นก็จะจมอยู่กับปัญหานานมาก จนสุดท้ายพบว่า code ที่เขียนออกมาเพื่อแก้ไขปัญหา มันอ่านไม่รู้เรื่องเลย มันอ่านยากมาก มันทำความเข้าใจยากมาก มันดูแลยากมาก มีข้อดีอย่างเดียวคือ แก้ไขปัญหาได้เท่านั้นเอง หรือบ่อยครั้งไม่สามารถแก้ไขปัญหาได้ แต่ก็ไม่สามารถลบ code ชุดนั้นทิ้งได้ !!
นั่งดู VDO เรื่อง Code Quality Lessons Learned จาก CodeClimate.com ตั้งคำถามที่น่าสนใจเกี่ยวกับ Code Quality ไว้ดังนี้ Code Quality คืออะไร ? ใช้อะไรวัดค่าความซับซ้อนของ code ? ทำไม code ของ project เก่า ๆ ถึงดูแลยากนักล่ะ ? ขนาดของ code ในแต่ละ Pull request สำหรับการ review ควรเป็นเท่าไรดี ? เมื่อไรที่ code แย่ ๆ ไม่ใช่ปัญหา ? อะไรบ้างที่เป็นตัวขัดขวาง Clean code ? เท่านี้ก็น่าสนใจแล้ว จึงทำการสรุปไว้นิดหน่อย ส่วนตัวเต็ม ๆ ลองไปฟังจาก VDO ได้ครับแค่ 1 [&hellip
เมื่อวานนั่งดู Code การพัฒนา iOS ด้วยภาษา Swift โจทย์เดียวกันจาก developer 4 คน แต่โครงสร้างของ code ที่ออกมานั้นเหมือนกัน นั่นคือเป็น MVC(Model View Controller) ในรูปแบบของ Apple ซึ่งส่วนใหญ่จะนำไปสู่ MVC ที่ย่อมาจาก Massive ViewController มากกว่านะ !! และนั่นคือความหายนะที่กำลังมาเยือนนักพัฒนาโดยทั้งรู้และไม่รู้ตัว
อ้างอิงข้อความจากคุณ Phil Karlton There are only two hard things in Computer Science: cache invalidation and naming things. รวมทั้งข้อมูลจากผลสำรวจเรื่อง The hardest problem in programming is what to name your variables and functions พบว่าเรื่องที่ยากที่สุดสำหรับนักพัฒนา software คือ การตั้งชื่อของตัวแปร function/method, class และอื่น ๆ อีกมากมาย โดยรวมคือการตั้งชื่อให้สื่อความหมายนั่นเอง (Meaningful Name)
จากบทความเรื่อง Why it happens to your code again and again? อธิบายการพัฒนาระบบ web application ด้วย RoR (Ruby on Rails) ซึ่งเป็น framework หลักของการพัฒนาระบบด้วยภาษา Ruby โดยในช่วงแรกของการพัฒนาระบบนั้นจะราบรื่นและรวดเร็ว ไม่ว่าจะเป็นการเพิ่ม gem หรือ library ต่าง ๆ เข้าไป ทุกอย่างมันแจ่มมาก ๆ แต่เมื่อเวลาผ่านไปเรากลับพบว่า
มาดูตัวอย่างของภาพที่ Developer หลาย ๆ คนอาจจะเห็นและพบจนชิน เมื่อ Developer เปิด source code บน IDE หรือ Editor ต่าง ๆ แล้วทำการ compile และ run อาจจะพบเจอกับ Warning หรือ คำเตือนต่าง ๆ จาก compiler จำนวนมาก !! คำถามที่น่าสนใจคือ จะทำอย่างไรต่อไปดีล่ะ ? จะทำการแก้ไข ? จะปล่อยไว้อย่างนั้น ? จะไม่สร้างมันขึ้นมาอีก ? Developer จะทำอย่างไรต่อไป