ในโลกของการพัฒนาซอฟต์แวร์ เรามักจะเห็นเส้นขนานสองเส้นเสมอ ด้านหนึ่งคือ “ทฤษฎีในอุดมคติ” (Clean Code, Design Patterns, 100% Test Coverage, Microservices) ส่วนอีกด้านหนึ่งคือ “ความจริงในโลกธุรกิจ” (Deadline, Budget, Requirements ที่เปลี่ยนตลอดเวลา)
นักพัฒนาจำนวนมากตกหลุมพรางของการพยายามทำทุกอย่างให้สมบูรณ์แบบตามตำรา (Purist / Idealist) แต่ในความเป็นจริง ซอฟต์แวร์ที่ออกแบบดีที่สุดในโลก จะไม่มีคุณค่าเลยถ้ามัน “เสร็จไม่ทันเวลา” หรือ “ไม่ได้แก้ปัญหาให้ผู้ใช้”
นี่คือจุดที่ Pragmatic Developer Mindset (วิถีนักพัฒนาสายปฏิบัตินิยม) เข้ามามีบทบาท
Pragmatic Developer คืออะไร?
Pragmatic Developer ไม่ใช่นักพัฒนาที่เขียนโค้ดลวก ๆ หรือสุกเอาเผากิน แต่คือคนที่ “เข้าใจบริบท” รู้ว่าเมื่อไหร่ควรใช้โซลูชันแบบไหน และพร้อมจะประนีประนอม (Trade-off) ระหว่างความสมบูรณ์แบบของโค้ดกับเป้าหมายทางธุรกิจ
“Pragmatism คือการเลือก Tool, Architecture และ Process ที่เหมาะกับข้อจำกัดในปัจจุบัน โดยไม่สร้างภาระให้ตัวเองในอนาคตจนเกินไป”
หัวใจสำคัญของ Pragmatic Mindset
Business Value Comes First (มูลค่าทางธุรกิจต้องมาก่อน)
โค้ดไม่ได้มีไว้เพื่อโชว์ความสวยงาม แต่มีไว้เพื่อส่งมอบ คุณค่า (Value) ให้ผู้ใช้หรือองค์กร นักพัฒนาสาย Pragmatic จะตั้งคำถามเสมอว่า
- ฟีเจอร์นี้ช่วยแก้ปัญหาให้ User จริงไหม?”
- “การเสียเวลา refactor ตรงนี้อีก 3 วัน ทำให้ธุรกิจได้ประโยชน์คุ้มค่าหรือไม่?”
Understand the Trade-offs (เข้าใจผลได้อย่างเสีย)
ในโลกซอฟต์แวร์ไม่มีโซลูชันไหนที่ดีที่สุด 100% มีแต่ “ความคุ้มค่าที่เหมาะกับสถานการณ์”
- Microservices ช่วย scaling ได้ดี แต่เพิ่มความซับซ้อนในการดูแล (Infrastructure/Ops)
- Monolith ดูไม่เท่ แต่สร้างง่าย ส่งมอบไว เหมาะกับระบบเริ่มต้นหรือทีมขนาดเล็ก นักพัฒนาสาย Pragmatic จะประเมิน Cost vs. Benefit เสมอ ไม่ไล่ตามเทรนด์เพียงเพราะมันกำลังฮิต
Keep It Simple, Stupid (KISS) & YAGNI
- KISS: เขียนโค้ดให้อ่านง่าย แก้ไขง่าย ดีกว่าเขียนโค้ดที่ซับซ้อนฉลาดล้ำแต่คนอื่นในทีมอ่านไม่รู้เรื่อง
- YAGNI (You Ain’t Gonna Need It): อย่าเพิ่งสร้าง Architecture หรือ Abstraction layer มารองรับสิ่งที่ คาดว่า จะเกิดขึ้นในอีก 2 ปีข้างหน้า ให้แก้ปัญหาของวันนี้ให้ดีที่สุดโดยเผื่อโครงสร้างให้ขยายได้ง่ายก็พอ
Pragmatic Clean Code & Testing
- Clean Code: ปรับปรุงเมื่อต้องแตะ (Boy Scout Rule) ไม่จำเป็นต้องร่ายเวทมนตร์ย้อนหลังปรับโค้ดทั้งโปรเจกต์ถ้ามันยังทำงานได้ดีและไม่ได้ถูกแก้ไขบ่อย ๆ
- Testing: เน้นเขียน Test ในจุดที่เป็น Core Business Logic หรือจุดที่มีความเสี่ยงสูง (Critical Path) การดัน Test Coverage ให้ได้ 100% โดยการ mock ทุกอย่างจนโค้ดเปราะบาง ไม่ใช่เป้าหมายของ Pragmatic Developer
Good Enough is Perfect (ดีพอดีคือสมบูรณ์แบบ)
คำว่า “เสร็จ” (Done) ของ Pragmatic Developer คือ
- ทำงานได้ถูกต้องตามโจทย์ (Correctness)
- มีความเสถียรและปลอดภัย (Stability & Security)
- อ่านเข้าใจและดูแลต่อได้ (Maintainability)
- เสร็จทันเวลาที่กำหนด
ตารางเปรียบเทียบ: Dogmatic vs. Pragmatic Developer
| หัวข้อ | Dogmatic / Idealist | Pragmatic Developer |
| เป้าหมายหลัก | โค้ดต้องสมบูรณ์แบบตามทฤษฎี | ส่งมอบโซลูชันที่แก้ปัญหาได้จริงและทันเวลา |
| การเลือก Tech Stack | ใช้ของใหม่ล่าสุด / เทรนด์ฮิตที่สุด | ใช้ Tool ที่ทีมถนัดและเหมาะกับโจทย์ |
| การออกแบบ Architecture | เผื่อการเติบโต 10 เท่าตั้งแต่วันแรก | ออกแบบให้เรียบง่าย แต่ขยายต่อได้เมื่อถึงเวลา |
| มุมมองต่อความผิดพลาด | พยายามป้องกันทุกวิถีทางจนล่าช้า | วางระบบ Monitoring, Log และ Recovery ให้พร้อมแก้ |
สรุป
การเป็น Pragmatic Developer ไม่ได้แปลว่าให้ละทิ้งหลักการหรือเขียนโค้ดแย่ ๆ แต่มันคือการพัฒนา “วิจารณญาณ” ในการสมดุลระหว่าง ความประณีตทางเทคนิค กับ ความจริงของธุรกิจ
ทฤษฎีเปรียบเสมือนเข็มทิศที่บอกทิศทาง แต่ Pragmatic Mindset คือทักษะในการเดินเรือท่ามกลางมรสุมจริง—คนที่รู้ว่าเมื่อไหร่ควรกางกางเรือเต็มที่ และเมื่อไหร่ควรผ่อนเครื่องเพื่อให้เรือไปถึงเป้าหมายได้อย่างปลอดภัย
อ่านเพิ่มเติม