“ขอเพิ่มผู้อนุมัติอีกชั้นได้ไหม?”
ลองนึกถึงระบบวันลาที่เปิดใช้งานแล้ว ทุกคนส่งคำขอได้ หัวหน้าอนุมัติได้ รายงานออกครบ แต่พอองค์กรปรับโครงสร้าง คำขอสั้น ๆ นี้กลับต้องแก้ทั้งหน้าฟอร์ม ฐานข้อมูล และอีเมลแจ้งเตือน
การเปลี่ยนกติกามีต้นทุนเสมอ คำถามคือ ทำไมเรื่องที่ควรอยู่ในจุดเดียวถึงกระจายไปหลายส่วน และทีมจะมั่นใจได้อย่างไรว่าการแก้ครั้งนี้ไม่กระทบงานเดิม
เรื่องนี้ควรคุยกันตั้งแต่ก่อนเริ่มเขียนโค้ด
เริ่มจากกติกาที่คนใช้เข้าใจตรงกัน
ก่อนเลือกภาษา โปรแกรม หรือฐานข้อมูล ลองเขียนขั้นตอน “ยื่นคำขอ → ตรวจสอบ → อนุมัติ → บันทึกผล” ให้คนทำงานจริงอ่าน แล้วถามถึงวันที่ทุกอย่างไม่ได้เป็นไปตามปกติ
ถ้าหัวหน้าไม่อยู่ ใครอนุมัติแทน? ถ้าพนักงานย้ายฝ่ายระหว่างรออนุมัติ คำขอควรไปหาใคร? ถ้ากดส่งซ้ำเพราะอินเทอร์เน็ตช้า จะมีคำขอสองรายการหรือไม่?
คำตอบเหล่านี้กำหนดพฤติกรรมของระบบ ถ้ายังตกลงกันไม่ได้ การวาดหน้าจอเพิ่มก็ไม่ช่วยให้กติกาชัดขึ้น
เอกสารเริ่มต้นจึงไม่จำเป็นต้องยาว แต่ควรมีตัวอย่างที่ทุกฝ่ายเห็นตรงกัน เช่น “ผู้ยื่นถอนคำขอได้ก่อนอนุมัติ หากอนุมัติแล้วต้องใช้ขั้นตอนยกเลิกแยกต่างหาก” ประโยคนี้ใช้คุยกับผู้ใช้ ออกแบบหน้าจอ และกำหนดสิ่งที่ต้องทดสอบได้ทันที
Clean Architecture ช่วยตรงไหน
แนวคิดสำคัญของ Clean Architecture คือให้โค้ดส่วนกติกาของระบบเป็นอิสระจากรายละเอียดของหน้าจอ ฐานข้อมูล และเครื่องมือภายนอก โดยจัดทิศทางการพึ่งพาของโค้ดเข้าหากติกาส่วนนี้
ในตัวอย่างวันลา กติกาว่า “ใครอนุมัติได้” ควรอยู่ในส่วนที่รับผิดชอบการอนุมัติ ส่วนหน้าจอมีหน้าที่รับข้อมูลและแสดงผล การบันทึกข้อมูลกับการส่งอีเมลเป็นงานอีกส่วนหนึ่ง
เมื่อเพิ่มผู้อนุมัติ ทีมจึงมีจุดเริ่มต้นในการแก้ที่ชัดเจน และตรวจได้ว่าต้องปรับข้อมูล หน้าจอ หรือการแจ้งเตือนส่วนไหนเพิ่มเติม การแยกส่วนไม่ได้ทำให้ทุกการเปลี่ยนแปลงเหลือไฟล์เดียว แต่ช่วยให้ตามผลกระทบได้ง่ายขึ้น
สำหรับระบบขนาดเล็ก อาจเริ่มจากแยกหน้าที่ภายในแอปเดียวให้ดี ยังไม่จำเป็นต้องแตกเป็นหลายบริการ คู่มือสถาปัตยกรรมของ Microsoft อธิบายทั้งการแบ่งชั้นในแอปเดียวและต้นทุนความซับซ้อนของ microservices ไว้ด้วย
สิ่งที่ควรถามทีมพัฒนาคือ “ถ้ากติกานี้เปลี่ยน ต้องแก้ตรงไหนบ้าง?” คำตอบที่ชี้ไปยังโค้ดและการทดสอบได้ บอกอะไรได้มากกว่าชื่อโฟลเดอร์สวย ๆ
ทดสอบกติกา แล้วค่อยทดสอบทั้งระบบ
ถ้าจะเปลี่ยนผู้อนุมัติ อย่าเริ่มตรวจด้วยการเปิดทุกหน้าจอแล้วกดไล่ไปเรื่อย ๆ อย่างเดียว ให้เริ่มจากกติกาที่เปลี่ยนก่อน
สำหรับตัวอย่างนี้ เราอาจกำหนดกรณีทดสอบว่า ผู้มีสิทธิ์อนุมัติทำรายการได้ ผู้ไม่มีสิทธิ์ถูกปฏิเสธ และคำขอที่ยกเลิกแล้วอนุมัติซ้ำไม่ได้ จากนั้นค่อยตรวจการบันทึกข้อมูลกับขั้นตอนใช้งานตั้งแต่ต้นจนจบ
การทดสอบกติกาแยกจากฐานข้อมูลช่วยให้ได้ผลตอบกลับเร็ว แต่ยังต้องมีการทดสอบว่าระบบเชื่อมต่อและบันทึกข้อมูลได้จริง หลักการแยกการทดสอบแต่ละระดับอ่านต่อได้ใน The Practical Test Pyramid ของ Ham Vocke
เรื่องสิทธิ์ต้องตรวจที่ฝั่งเซิร์ฟเวอร์ด้วย การซ่อนปุ่มอนุมัติช่วยให้หน้าจอใช้งานง่ายขึ้น แต่ผู้ใช้ยังอาจส่งคำขอไปยังระบบโดยตรงได้
การทดสอบที่มีประโยชน์ควรตอบคำถามว่า “งานสำคัญของผู้ใช้ยังทำได้ไหม?” ไม่ใช่เพียงบอกว่ารันครบกี่รายการ
วันส่งมอบต้องมีมากกว่าไฟล์โค้ด
ลองสมมติว่าผู้ดูแลระบบคนใหม่เข้ามาวันจันทร์ เขาควรรู้ว่าจะเริ่มระบบที่ไหน ตั้งค่าตรงไหน และถ้าปล่อยเวอร์ชันใหม่แล้วมีปัญหาจะย้อนกลับอย่างไร
คู่มือจึงควรมีขั้นตอนติดตั้ง ตัวอย่างค่าตั้งต้นที่ไม่มีรหัสลับ วิธีนำขึ้นใช้งาน และข้อจำกัดที่ยังเหลืออยู่ พร้อมระบุว่าใครเป็นผู้ดูแลบัญชีบริการและสิทธิ์เข้าถึง
ส่วนข้อมูลต้องคุยให้ชัดทั้งการสำรองและการกู้คืน ควรทดลองกู้คืนในสภาพแวดล้อมแยก พร้อมตรวจว่าข้อมูลที่ได้กลับมาครบและระบบเปิดใช้งานต่อได้ การมีไฟล์สำรองอย่างเดียวตอบคำถามนี้ไม่ได้
อีกเรื่องที่ควรส่งต่อคือเหตุผลของการตัดสินใจ เช่น ทำไมเลือกแอปเดียว ทำไมยังไม่ทำงานแบบออฟไลน์ หรือทำไมต้องเก็บประวัติการอนุมัติ ทีมถัดไปจะได้รู้ว่าส่วนไหนเป็นข้อจำกัดจริง และส่วนไหนปรับได้
ห้าคำถามก่อนเริ่มโปรเจกต์
ก่อนตกลงขอบเขตงาน ลองคุยห้าเรื่องนี้ให้ครบ:
- งานไหนต้องทำได้ในเวอร์ชันแรก? เลือกขั้นตอนที่ผู้ใช้ต้องทำให้จบ แทนการนับจำนวนหน้าจอ
- กติกาไหนยังไม่มีข้อสรุป? ระบุผู้ตัดสินใจและวันนัดคุยให้ชัด
- ถ้ากติกาเปลี่ยน ทีมจะตรวจผลกระทบอย่างไร? ขอให้ยกตัวอย่างจากงานที่กำลังจะทำ
- ก่อนนำขึ้นใช้จริง จะตรวจอะไรบ้าง? ตกลงกรณีใช้งาน สิทธิ์ ความเร็ว และการเข้าถึงที่เหมาะกับผู้ใช้ของระบบ
- หลังส่งมอบ ใครดูแลเรื่องไหน? รวมถึงโค้ด บัญชีบริการ ข้อมูลสำรอง และค่าใช้จ่ายประจำ
ระบบที่ดูแลต่อได้เริ่มจากการตัดสินใจเล็ก ๆ เหล่านี้ กติกาที่เขียนชัด โค้ดที่ตามเรื่องได้ และวิธีกู้คืนที่ลองทำแล้ว ล้วนช่วยให้การเปลี่ยนแปลงครั้งถัดไปมีหลักให้ยึด
ถ้ากำลังวางแผนระบบใหม่ ลองเริ่มจากขั้นตอนที่ทีมเสียเวลามากที่สุดหนึ่งเรื่อง แล้วเขียนให้เห็นทั้งวันที่ทุกอย่างราบรื่นและวันที่มีข้อยกเว้น แค่นั้นก็มีเรื่องที่เป็นรูปธรรมพอจะ คุยกับทีมพัฒนา ได้แล้ว