See the original English version of this article here
บทความนี้ได้รวม 7 ความผิดพลาดด้าน Software Architecture ที่เกิดขึ้นได้แม้กับ Senior Engineer จาก Overengineering, เลือก Tech ผิด, Config ยืดหยุ่นเกินไป ไปจนถึง ข้าม Monitoring พร้อมบทเรียนจริงและแนวทางแก้ที่ช่วยลด Technical Debt และสร้างระบบที่ยืดหยุ่นกว่าเดิม
แม้จะอยู่ในสาย Software Developer มานานหลายปี คำว่า “Senior Engineer” ก็ไม่ได้หมายความว่าเราจะไม่ทำพลาด ในทางกลับกัน ประสบการณ์ที่มากอาจทำให้เรามั่นใจเกินไป และนั่นคือจุดเริ่มต้นของ Overcomplicated Architecture หรือการตัดสินใจที่ย้อนมาสร้าง Technical Debt ให้ทีม นี่คือ 7 ความผิดพลาดที่หลายคนเคยเจอ และบทเรียนที่ได้กลับมา โดย Vinod Pal
1. Overengineering เพื่อ Scale ที่ยังไม่มาถึง
ครั้งหนึ่งคุณ Vinod ทำระบบ Loan Approval ที่ใช้ Node.js และ PostgreSQL โดยเขาได้เสนอให้เพิ่ม Apache Kafka เข้ามาระหว่าง Services โดยให้เหตุผลว่า “เราต้องพร้อมเมื่อมี Request หลักพันต่อนาที”
แต่ตอน Launch ระบบจริงกลับมีไม่ถึง 50 Requests ต่อวัน ดังนั้น Kafka กลายเป็นภาระ ทั้งในแง่การดูแลและการ Debug จนมี Developer คนหนึ่งที่ได้ฉายาว่า “Kafka Babysitter”
บทเรียน: อย่าสร้างปัญหาที่ระบบยังไม่ต้องเจอ เริ่มจาก Synchronous Call ง่าย ๆ ก็เพียงพอ แล้วค่อยเพิ่ม Complexity เมื่อมี Data ที่พิสูจน์ว่าจำเป็นจริง
2. เลือก Tech ที่คิดว่าเจ๋ง แต่ไม่เหมาะกับงาน
ทีมของคุณ Vinod กำลังสร้าง Analytics Dashboard ที่ต้อง Query หลายตารางและ Join ข้อมูลเยอะ ซึ่ง
PostgreSQL ทำได้ดีอยู่แล้ว แต่ผมอยากลอง MongoDB เพราะคิดว่า Document Storage จะยืดหยุ่นกว่า
ผลคือ Query ง่าย ๆ กลายเป็น 20-stage Aggregation Pipeline ซึ่ง Performance แย่ลง, Index จัดการยาก, และทีมหมดความมั่นใจ สุดท้ายต้องย้ายกลับมาใช้ Postgres เหมือนเดิม
บทเรียน: เลือกเทคโนโลยีที่ ทำให้ Case ใช้งานหลักง่ายขึ้น ไม่ใช่ที่ “ดูเจ๋งกว่า”
3. ทำให้ทุกอย่าง Configurable (จนพังทั้งระบบ)
ใน Logistics Project บน Spring Boot คุณ Vinod ทำให้ทุก Shipping Rule ปรับได้ผ่าน YAML โดยตอนแรกคิดว่า Flexible ดี จนวันหนึ่ง Partner เปลี่ยนค่า maxShipmentWeight จาก 50 เป็น 5000 ทำให้ระบบเลย “อนุญาต” ให้รถบรรทุกของเราขนเกินจริงแบบไร้เหตุผล
บทเรียน: Flexibility ที่ไม่มี Guardrail คือ Chaos ทำ Configurable เฉพาะสิ่งที่จำเป็นจริง ๆ และ Validate ทุกค่าเสมอ ส่วนค่าคงที่อื่น ๆ ใช้ Hardcode พร้อม Test ดีกว่า
4. แยก Monolith ออกเป็น Microservices ทั้งที่ยังไม่พร้อม
คุณ Vinod มีระบบ .NET Monolith ที่ดูแล Orders, Payments, และ Notifications เขาจึงตัดสินใจแยกเป็น Microservices แต่ละตัว Run ใน Docker และ Deploy ผ่าน Azure DevOps ซึ่งบนกระดาษมันดูดี แต่ในทางปฏิบัติ Call เดียว “Place Order” ต้องผ่าน Network 5 Hops เราต้องเพิ่ม Jaeger เพื่อ Trace ปัญหา และทุกครั้งที่ที่มีการ Deploy เหมือน Launch ยาน NASA
บทเรียน: สิ่งที่ขาดคือ Monitoring, Versioning และ Pipeline ที่ Mature พอ อย่าแยกระบบออกก่อนที่ทีมและ Tooling จะพร้อมรองรับ
5. ข้ามการเขียน Document เพราะ Code มันอธิบายตัวเองได้
คุณ Vinod เคยเขียน Python + Airflow DAG ที่ดึงข้อมูลจาก 3 API แล้วแปลงไปลง S3 ตอนนั้นคิดว่าถ้าคนอื่นอ่าน Code ก็เข้าใจได้เอง จนวันหนึ่งเขาลาหยุด แล้ว API ตัวหนึ่งเปลี่ยน Schema เพื่อนในทีมใช้เวลา 2 วันไล่หาว่าเกิดอะไรขึ้น ก่อนจะเจอ Hardcode Field Rename ซ่อนอยู่ใน Logic ของเขา
บทเรียน: Code บอกว่า “เกิดอะไรขึ้น” แต่ไม่บอกว่า “ทำไมถึงทำแบบนั้น” ดังนั้น เขียน Comment และ Documentation ไว้เสมอ มันคือประกันราคาถูกสำหรับอนาคต
6. ชะลอการทำ Logging และ Monitoring
ตอนเราสร้าง SaaS ด้วย React + Node.js เพื่อให้ Go-live เร็วขึ้น เราข้าม Datadog ไปก่อน ซึ่งผลคือ Bug ใน Payment Webhook ทำให้ Renewal Fail ไป 12% โดยไม่มีใครรู้ ซึ่งไม่มี Log, ไม่มี Alert, ไม่มี Metric จนกว่าจะมีอีเมลลูกค้าร้องเรียนในเช้าวันจันทร์
บทเรียน: Monitoring ไม่ใช่ Optional มันคือส่วนหนึ่งของ Architecture ถ้าข้ามมันไปก็เหมือนบินเครื่องบินแบบไม่มีเรดาร์
7. ยึดติดกับ “Clever Solution” มากกว่า “Correct Solution”
คุณ Vinod เคยทำระบบ Cart ใน E-commerce โดยใช้ Event Sourcing ซึ่งดูเท่และล้ำมาก โดยมี Replayable History, Audit Log และ Future-proof Scaling แต่สำหรับระบบที่ Cart หมดอายุในไม่กี่ชั่วโมง มันคือความสิ้นเปลือง Storage บวม, Query ช้า, Developer ใหม่ไม่กล้าแตะ สุดท้ายทีมเปลี่ยนกลับมาใช้ Single Table ธรรมดา
บทเรียน: คุณไม่ได้ถูกจ้างมาให้ “ทำเท่” แต่ให้ “แก้ปัญหา” Architecture ที่ดีคือ สิ่งที่แก้ไขได้ง่าย ไม่ใช่สิ่งที่ซับซ้อนที่สุด
สรุป
ทุกความผิดพลาดเริ่มต้นจากความตั้งใจที่ดี “อยากให้ระบบดีขึ้น” แต่ประสบการณ์ที่แท้จริงคือการรู้ว่า เมื่อไหร่ควรเพิ่มความซับซ้อน และเมื่อไหร่ควรรักษาความเรียบง่าย เพราะสุดท้ายแล้ว Architecture ที่ดี ไม่ใช่ระบบที่ “สมบูรณ์แบบที่สุด” แต่คือระบบที่คุณสามารถแก้ ปรับ หรือเปลี่ยนได้ โดยไม่ต้องกลัวว่าจะพังทั้งหมด
คุณเคยเจอความผิดพลาด ในการออกแบบระบบแบบนี้ไหม?
และทั้งหมดนี้ก็คือ 7 Mistakes ด้าน Software Architecture ที่แม้แต่ Senior Engineer ยังพลาด
เมื่อ หางาน IT ให้ ISM Technology Recruitment เป็นอีกหนึ่งตัวช่วย เพื่อให้คุณได้ “ชีวิตการทำงานในแบบที่คุณต้องการ” เพียงส่ง Resume มาที่นี่
ISM เชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ ได้เปิดทำการมาแล้วกว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
Source: https://medium.com/@vndpal/