Photo by Tanguy Sauvin on Unsplash

สำหรับคนที่พึ่งเขียนโค้ดใหม่ๆ ผมแนะนำว่าให้พยายามเขียนโค้ดทีละนิด อย่าเขียนรวดเดียวครับ

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

แต่ละรอบ เค้าจะแก้โค้ดแค่ไม่เกินห้าบรรทัด

ตัวอย่างเช่น ผมอยากจะเขียน API เพื่อรับค่าจาก Array มาคำนวนแล้วส่งค่า Sum กลับไป ผมจะเขียนแต่ละรอบดังนี้

  1. เขียน API เพื่อรับค่า Array แล้ว print ค่าที่รับไปออกมา แล้วเขียนโค้ดเพื่อเทสต์ดูว่าค่าถูกต้อง ชนิดของตัวแปรที่รับเข้ามาเป็นตัวเลข ก่อนจะไปต่อ
  2. ลอง return ค่า 0 กลับไปดู แล้วเรียก API อีกรอบ ดูว่าได้ค่าที่รีเทิร์นตรงไหม
  3. วนลูปแล้วลองพิมพ์ค่าใน Array ออกมาในว่าเราวนลูปถูกไหม
  4. คำนวนค่า Sum แล้ว return กลับ
  5. ลองเทสต์พวก Edge case ทีละตัว (เช่น Array ว่างเปล่า หรือมีค่าแค่ตัวเดียว)

คนที่ใช้ TDD (Test Driven Development) จะคุ้นกับการทำงานในลักษณะนี้ ดูคร่าวๆเหมือนจะช้ากว่า แต่ในทางปฏิบัติ ผมรู้สึกว่ามันเร็วกว่าเพราะถ้าผมทำอะไรผิดนิดนึง ผมรู้เลยว่ามันต้องผิดใน 2-3 บรรทัดที่ผมพึ่งใส่เข้าไป จะหาบั๊กได้เร็วมาก

ถ้าผมคล่องภาษาหรือเฟรมเวิร์คที่ใช้ ผมอาจจะรวบทำข้อ 1-2 กับ 3-4 เข้าด้วยกัน แต่ผมจะไม่เขียนรวดเดียวหมด

เพราะจากประสบการณ์ ผมมั่นใจว่าถ้าผมเขียนโค้ดรวดเดียวเกิบสิบบรรทัด ผมน่าจะทำผิดที่ไหนสักแห่ง พอผิดแล้วก็รันไม่ผ่าน เวลาแก้ ก็จะไม่แน่ใจว่าโค้ดผิดตรงไหน (เทสต์โค้ด, ตัว Parameter ถูกชนิดและถูกค่าไหม, For loop, Sum logic, return) เวลาดีบั๊กก็จะยากกว่า ใช้เวลาโดยรวมนานกว่า

แน่นอนว่าผมก็เจอคนที่เทพในระดับเขียนยี่สิบบรรทัดรวดเดียวถูกหมด แต่ผมรู้สึกว่าโลกนี้มีคนที่เก่งขนาดนั้นแค่หยิบมือเดียว (ส่วนใหญ่มักจะเป็นพวกคอมพิวเตอร์โอลิมปิค) หรือเค้าเขียนโค้ดแนวเดียวกันเป็นประจำจนชินแล้ว

สำหรับกรณีทั่วไป ผมแนะนำให้ค่อยๆเขียน ค่อยๆแก้ครับ เหมือนนิทานเรื่องกระต่ายกับเต่า เขียนไปทีละนิดแต่ไม่ให้ติดบั๊กที่หายาก ดีกว่าไปรวดเดียวแล้วติด ต้องหาบั๊กนานๆ


---

ติดตามบทความสำหรับโปรแกรมเมอร์ทั้งด้านได้ที่ Facebook page Not about code หรือ Twitter @notaboutcode บทความของเพจจะเน้นเนื้อหาที่นำไปใช้ได้กับชีวิตจริง แต่ไม่ยึดติดกับเทคโนโลยีหรือภาษา เช่น System Design, Continuous Delivery, Testing, Career, etc.

สำหรับท่านที่อยากสนับสนุนผู้เขียน รบกวนช่วยแชร์โพสต์ในเฟสบุ้คให้กับเพื่อนๆที่น่าจะสนใจหัวข้อพวกนี้ด้วยครับ