จาก “คนเขียนโค้ด” สู่ “มืออาชีพ”: สรุป 5 กฎเหล็กจากหนังสือคลาสสิก The Pragmatic Programmer

ถ้าคุณอยู่ในวงการพัฒนาซอฟต์แวร์ น่าจะเคยได้ยินชื่อหนังสือ “The Pragmatic Programmer” ของ Andrew Hunt และ David Thomas ผ่านหูมาบ้าง นี่คือหนังสือระดับขึ้นหิ้งที่ไม่ได้สอนว่าภาษาไหนเขียนยังไง แต่สอน “วิธีคิดและวินัย” ที่จะเปลี่ยนเราจากแค่คนรับบรีฟเขียนโค้ด ให้กลายเป็นวิศวกรซอฟต์แวร์ที่ใครๆ ก็อยากร่วมงานด้วย

สำหรับใครที่ไม่มีเวลาอ่านเล่มเต็ม วันนี้เราสรุป 5 กฎเหล็กหนีตายที่จะช่วยให้ชีวิตการเป็น Dev ของคุณง่ายขึ้น (และปวดหัวน้อยลง) มาฝากกันครับ

1. Don’t Live with Broken Windows (อย่าปล่อยให้หน้าต่างแตก)

ในทางอาชญวิทยา มีทฤษฎีหนึ่งบอกว่า “ถ้าตึกหนึ่งบานมีกระจกแตก แล้วไม่มีใครซ่อม ไม่นานกระจกบานอื่นๆ จะถูกทุบตาม และตึกนั้นจะพังยับเยินในที่สุด”

การเขียนโค้ดก็เหมือนกันครับ บั๊กเล็กๆ โค้ดแย่ๆ (Bad Code) หรือคอมเมนต์ // TODO: เดี๋ยวกลับมาแก้ ที่เราปล่อยทิ้งไว้ คือหน้าต่างที่แตกบานแรก ถ้าเราไม่รีบซ่อม คนอื่นในทีม (หรือแม้แต่ตัวเราในอนาคต) ที่มาทำต่อ ก็จะรู้สึกว่า "อ้าว ตรงนั้นยังเละได้ ตรงนี้ฉันเขียนลวกๆ บ้างคงไม่เป็นไร"

Pragmatic Tip: เจอโค้ดแย่ตรงไหน ให้แก้ทันที อย่าผลัดวันประกันพรุ่ง คลีนบ้านอยู่เสมอ ก่อนที่มันจะกลายเป็นกองขยะซุปเปอร์สปาเก็ตตี้ที่ไม่มีใครกล้าแตะ

2. DRY: Don’t Repeat Yourself (ไม่ใช่แค่เรื่อง Copy-Paste)

เราทุกคนรู้ดีว่าไม่ควร Copy โค้ดไปแปะซ้ำๆ แต่แนวคิด DRY ในหนังสือเล่มนี้มองลึกกว่านั้น มันคือเรื่องของ “Knowledge” (องค์ความรู้) ในระบบ

ทุกๆ ลอจิก หรือความจริงในระบบ ควรมีตัวแทนเพียงหนึ่งเดียว (Single Source of Truth) ลองนึกภาพว่าถ้าคุณต้องเปลี่ยนเงื่อนไขการคำนวณภาษีของระบบ แล้วต้องตามไปแก้ทั้งใน Frontend, Backend, Database มัลติเวิร์สแบบนี้แหละที่จะทำให้เกิดบั๊ก

Pragmatic Tip: ออกแบบระบบให้โค้ดแต่ละส่วนแยกออกจากกันเป็นอิสระ (Orthogonality) การแก้ไขจุด A ต้องไม่ทำให้จุด B พังโดยไม่ตั้งใจ

3. Crash Early (เจ็บสั้นดีกว่าเจ็บยาว)

Dev หลายคนชอบเขียน try-catch คลุมโค้ดไว้หนาๆ หรือพยายามรีเทิร์นค่า null หรือค่าว่างกลับไป เพื่อไม่ให้โปรแกรมมันแครช (Crash) บน Production

หนังสือบอกว่า นั่นคือความคิดที่ผิด! การฝืนให้โปรแกรมรันต่อไปทั้งที่ข้อมูลข้างในมันเพี้ยนไปแล้ว เปรียบเหมือนการขับรถที่พวงมาลัยพังแต่ยังเหยียบคันเร่งต่อ สุดท้ายมันจะไปสร้างความเสียหายในจุดที่ลึกกว่าเดิม (เช่น ข้อมูลใน Database พัง) แถมยังหาต้นตอของบั๊กยากขึ้นด้วย

Pragmatic Tip: ถ้าโปรแกรมจะพัง จงปล่อยให้มันพังทันที (Crash Early) ตั้งแต่เนิ่นๆ ระบบที่ตายอย่างรวดเร็วและมี Log ชัดเจน ปลอดภัยกว่าระบบที่รันต่อแบบเอ๋อๆ เสมอ

4. Don’t Provide Excuses, Provide Options (เลิกหาข้อแก้ตัว แต่จงหาทางออก)

ในฐานะมืออาชีพ เมื่อเกิดข้อผิดพลาดขึ้น (เช่น ระบบล่ม, งานส่งไม่ทัน) สิ่งที่ลูกค้าหรือทีมต้องการไม่ใช่คำอธิบายแก้ตัวว่า “เป็นเพราะสเปกเครื่องครับ” หรือ “โค้ดเก่าคนอื่นเขียนไว้ไม่ดี”

ก่อนที่คุณจะเดินไปบอกหัวหน้าหรือลูกค้าว่าเกิดปัญหา ให้หยุดคิดสักนิด แล้วเตรียม “ทางเลือกเพื่อแก้ไข” (Options) ไปเสนอด้วยเสมอ

• ❌ “งานไม่เสร็จตามกำหนดครับ เพราะ API ฝั่งนู้นช้า”
• ✅ “งานมีแนวโน้มจะเลทเพราะ API ฝั่งนู้นช้าครับ แต่ผมเตรียมแผน B ไว้แล้ว คือเราจะจำลอง (Mock) ข้อมูลขึ้นมาเทสก่อน เพื่อให้ฝั่งหน้าบ้านรันต่อได้ พี่เห็นด้วยไหมครับ?”

5. ลงทุนใน Knowledge Portfolio (ความรู้คือพอร์ตหุ้น)

เทคโนโลยีเปลี่ยนผ่านไวมาก สิ่งที่เราเชี่ยวชาญในวันนี้ อาจไม่มีใครใช้แล้วในอีก 3 ปีข้างหน้า หนังสือแนะนำให้เราบริหารความรู้เหมือนการลงทุนในกองทุนหุ้น:

• ลงทุนสม่ำเสมอ: เรียนรู้สิ่งใหม่ๆ เล็กๆ น้อยๆ ทุกวันจนเป็นนิสัย
• กระจายความเสี่ยง: อย่ากระจุกตัวเองอยู่กับแค่ Language หรือ Framework เดียว ลองเรียนรู้ภาษาใหม่ๆ ที่คิดต่างออกไปทุกปี (เช่น ถ้าเซียน OOP ลองไปจับ Functional Programming ดูบ้าง)
• ทบทวนและปรับพอร์ต: หมั่นอัปเดตเทรนด์และประเมินว่าสิ่งที่เราเรียนรู้ยังตอบโจทย์ตลาดอยู่ไหม

สรุปส่งท้าย

สิ่งสำคัญที่สุดที่ได้จาก The Pragmatic Programmer ไม่ใช่สูตรสำเร็จในการเขียนโค้ดให้เร็วที่สุด แต่คือคำว่า “ความรับผิดชอบและพร้อมปรับตัว” การใส่ใจในรายละเอียดเล็กๆ น้อยๆ และไม่ยอมปล่อยผ่านงานที่ไม่ได้คุณภาพ คือจุดเริ่มต้นของการเป็นโปรแกรมเมอร์ที่ยอดเยี่ยมครับ

…แล้วเพื่อนๆ ล่ะครับ ใน 5 ข้อนี้ มีข้อไหนที่ตรงกับประสบการณ์ตรง หรือกำลังพยายามปรับปรุงในโปรเจกต์ปัจจุบันกันอยู่บ้าง? มาคอมเมนต์แชร์กันได้เลย! 👇