Code ที่ดีนั้นอาจจะไม่ได้สร้างหรือส่งมอบ product ที่ดีเสมอไป
แต่ code ที่ดีมันกลับทำให้คนที่ดูแลง่าย และ มีชีวิตที่สงบสุขมากขึ้น
คำว่า Code ที่ดีนั้นมีหลายรูปบบ หลายความหมาย
ตามแต่ประสบการณ์ ความรู้ และ สิ่งแวดล้อม
แต่มุมมองที่น่าสนใจคือ
Code ที่ดีมันน่าจะต้องเพิ่มหรือปรับปรุง productivity ให้กับเราสิ

จากที่ได้พูดคุยกับเหล่านักพัฒนาก็แนะนำดังนี้

Code ที่เขียนทดสอบหรือไม่ ? ถ้าไม่ทดสอบมีโอกาสพังสูงนะ

การทดสอบแบบไหนก็ได้
ไม่จำเป็นต้องเป็นแบบอัตโนมัติ
แต่ขอให้ทุกการเปลี่ยนแปลง ต้องทำการทดสอบทั้งหมด (regression test)
ในกรอบเวลาที่เร็วและชัดเจน

การทดสอบมีหลายรูปแบบ
จากเล็ก ๆ ในระดับ Unit test ไปจนถึงระดับ End-to-End test
เวลาก็จะสูงขึ้นเริ่ม ตามระดับที่สูงหรือใหญ่ขึ้น
ถ้าทำได้ก็ควรทำในทุกกระดับ
เริ่มตั้งแต่ระดับเล็ก ๆ เพื่อทำให้มั่นใจว่า แต่ละส่วนการทำงานยังคงทำงานถูกต้อง
จากนั้นเริ่มสูงขึ้นมา เช่น integrate test เพื่อนำส่วนการทำงานต่าง ๆ มาทำงานร่วมกัน
รวมกันไปเรื่อย ๆ จนถึง End-to-End test
มันจะช่วยให้เรารู้ปัญหาได้อย่างรวดเร็ว ไม่ต้องมา debug กัน

เลือกใช้ชื่อที่เหมาะสมและสื่อความหมายในสิ่งที่ต้องการ

จากหนังสือ Clean Code จะเน้นในเรื่องการการตั้งชื่อมาก ๆ
นักพัฒนาก็ควรเรียนรู้การตั้งชื่อที่เหมาะสม
เพราะว่า ชื่อมันคือ abstraction layer หรือประตูบานแรก
ที่จะอธิบายว่า code ทำงานอะไรบ้าง
ส่วนทำงานอย่างไรค่อยเข้าไปดูในรายละเอียดต่อไป
เปรียบเสมือแผนที่การเดินทางนั่นเอง
จะไปทางไหน อย่างไร ค่อยว่ากันต่อไป

ชื่อที่ดีทำให้เราอ่านได้อ่าน เข้าใจได้ง่าย
ดังนั้นก็จะดูแลรักษาได้ง่ายขึ้น

ลูกอีช่าง Log …

ใครบ้างที่เขียน code สำหรับเก็บ log มากกว่าเขียน code ของระบบอีก ?
Log เป็นสิ่งที่ดี เพราะว่า มันช่วยทำให้เรารู้ว่า
มีอะไรเกิดขึ้นในระบบบ้าง
แต่ก่อนที่จะเขียน log นั้นช่วยสรุปก่อนว่า เราต้องการจะถามหรือรู้อะไรจากระบบ
เช่นเหตุการณ์ต่าง ๆ ขั้นตอนการทำงานหลักของระบบ และ error ที่เกิดขึ้น เป็นต้น
บ่อยครั้งพบว่าเราเก็บ log มากจนเกินไป
รวมทั้งชอบเขียนลงไฟล์ แล้วมา tail -f log กันอีก
แบบนี้ไม่น่าช่วยทำให้ productivity ดีขึ้นเลย กลับแย่กว่าเก่า

ดังนั้นเปลี่ยนมาเขียน log ลงระบบที่ช่วยจัดการดีกว่าไหม ?
เช่นระบบ centralize log ที่มีการจัดการที่ดี
มีระบบ dashboard มีระบบ alert เมื่อมีสิ่งที่แปลก ๆ เกิดขึ้นมา

เรื่องของ Single Responsibility Principle (SRP) ของแต่ละ class และ method สำคัญมาก ๆ

แต่ละ class และ method ควรมีหน้าที่การทำงานที่เฉพาะเจาะจงไปเลย
ชื่อของ class และ method ก็จะต้องสื่อถึงการทำงานที่เจาะจง
ส่งทำให้จำนวน code น้อยลง
นั่นทำให้การอ่านง่าย หา bug ได้ง่าย แก้ได้ง่าย

เพื่อความปลอดภัย อย่าลืมดัก exception/error ที่ไม่คาดฝัน หรือ ไม่ต้องการไว้ด้วย
เนื่องจาก code ที่เราพัฒนาขึ้นมานั้น
มันอาจจะเกิดสถานการณ์ที่เราไม่คาดฝัน หรือไม่ต้องการขึ้นมาได้
การทดสอบอาจจะยากมาก ๆ
ดังนั้นสิ่งที่ควรทำคือ การดัก exception เหล่านั้นซะ

แต่ถ้าเราสามารถจำลองสถานการณ์ได้
ก็จัดการมันซะ อย่าปล่อยไว้
ส่วนสิ่งอื่น ๆ ที่อาจจะเกิดขึ้นแต่ไม่สามารถจำลองได้ ก็ต้องดักไว้เช่นกัน
เพื่อช่วยให้ระบบงานไม่พังง่ายจนเกินไป

วันนี้ code ที่เราเขียนอยู่เป็นอย่างไรบ้าง ?
มันช่วยทำให้เรามี productivity ที่สูงขึ้นหรือไม่ ?