เพิ่ม API field แค่หนึ่งตัว ทำไมถึงกลายเป็น Rework ใหญ่ได้

คำขอเพิ่มข้อมูลเพียงหนึ่ง field อาจกระทบตั้งแต่ Database ไปจนถึง Business Logic และ Test เพราะต้นทุนจริงขึ้นอยู่กับความลึกของผลกระทบ ไม่ใช่ขนาดของคำขอ

ทำไมเพิ่ม API field แค่ 1 ตัว Developer ถึงบอกว่าต้องแก้หลายจุด?

บางครั้ง Business ขอเพิ่มข้อมูลใน API response แค่ 1 field

ฟังดูแล้วอาจเป็นงานเล็กมาก เหมือนเพิ่ม Code ไม่กี่บรรทัด

แต่ในความเป็นจริง ถ้าข้อมูลนั้นไม่เคยถูกเก็บไว้ในระบบตั้งแต่แรก งานนี้อาจไม่ได้กระทบแค่หน้า API

Developer อาจต้องแก้ตั้งแต่

Database schema
Migration
Data model
Query
Business logic
API contract
Test cases

และถ้า field ใหม่ไม่เข้ากับ Data design เดิม บางครั้งอาจต้องกลับไป redesign Flow หรือโครงสร้างข้อมูลบางส่วนของระบบเลย

สมัยนี้แล้ว งั้นใช้ AI ช่วยสิ

การ redesign ใหม่นี่แหละคือสิ่งที่ AI ทำไม่ได้ทั้งหมด

จริงอยู่ว่าทุกวันนี้ Developer ส่วนใหญ่ใช้ AI ช่วยเขียน Code แทบทั้งหมด แต่นั่นไม่ได้ทำให้งานส่วนที่ต้องตรวจสอบหรือติดตามคุณภาพ Code หายไป

Developer ยังต้องตรวจสอบสิ่งที่ AI เขียนหรือออกแบบมาให้ รวมถึงตัดสินใจเลือกวิธีการและ trade-off ที่เหมาะกับงาน

เพราะฉะนั้น Cost ของ Requirement change ไม่ได้ขึ้นอยู่กับว่าคำขอฟังดูเล็กแค่ไหน แต่ขึ้นอยู่กับว่ามันกระทบของเดิมลึกแค่ไหน

แต่เรื่องนี้ไม่ได้แปลว่าเราต้องออกแบบระบบให้รองรับทุกอย่างในอนาคต เพราะถ้าทำมากเกินไปก็จะกลายเป็น Over-engineering

สิ่งที่ช่วยลด Rework ได้จริง คือการคุย Requirement และวาง Data ให้ชัดก่อนเริ่มพัฒนา

ลองถามกันให้ชัดก่อนว่า

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

การทำ Requirement refinement ที่ดีไม่ได้ช่วยให้ Developer พิมพ์ Code เร็วขึ้น

แต่มันช่วยลดเวลาที่ Developer ต้องกลับมาแก้ของที่ทำเสร็จไปแล้ว

เพราะเวลาที่ Developer ต้องกลับมาแก้งานเดิม คือต้นทุนที่ธุรกิจต้องจ่ายเพิ่ม และทำให้ทีมมีเวลาและ Productivity สำหรับงานใหม่น้อยลง