Software​ ​Design​ ​ก่อน​เขียน​โค้ด​ควร​มี​อะไร​บ้าง

Software Design คือการตัดสินใจว่าระบบจะตอบ Requirement อย่างไร ก่อนลงทุนเขียนโค้ดจำนวนมาก แบบที่ดีไม่จำเป็นต้องเป็นเอกสารหนา แต่ต้องทำให้ทีมเข้าใจเส้นทางงาน ข้อมูล กฎ และความเสี่ยงตรงกัน หากแบบตอบไม่ได้ว่า “เมื่อคำขอส่งซ้ำจะเกิดอะไรขึ้น” โค้ดก็มักตอบไม่ได้อย่างสม่ำเสมอ

เริ่มจากเส้นทางผู้ใช้และสถานะ

เลือกงานสำคัญหนึ่งเส้นทาง เช่น ส่งคำขอ ตรวจ อนุมัติ และปิดงาน วาดว่าใครทำอะไร ที่หน้าหรือช่องทางใด และระบบตอบอย่างไรเมื่อสำเร็จหรือไม่สำเร็จ กำหนดสถานะที่มีความหมายทางธุรกิจและการเปลี่ยนสถานะที่อนุญาต อย่าวาดเฉพาะทางที่ทุกอย่างทำงาน เพราะกรณีข้อมูลไม่ครบ ผู้ใช้ไม่มีสิทธิ์ หรือบริการภายนอกล่มมักกำหนดประสบการณ์จริง

ภาพที่ 1: เส้นทางผู้ใช้ ข้อมูล สิทธิ์ และการเชื่อมต่อควรถูกออกแบบสัมพันธ์กันก่อนแยกงานเขียนโค้ด

ข้อมูลและขอบเขตระบบ

ระบุข้อมูลหลัก เช่น คำขอ ผู้ใช้ ทีม และประวัติสถานะ พร้อมความสัมพันธ์และผู้เป็นเจ้าของข้อมูล อาจใช้ ER Diagram เมื่อข้อมูลหลายชุดสัมพันธ์กัน และ Sequence Diagram เมื่อหลายบริการสื่อสารกัน กำหนดสัญญา API เท่าที่มีการเชื่อมต่อจริง: ข้อมูลเข้า ผลลัพธ์ รหัสผิดพลาด และการลองใหม่ แบบต้องระบุสิทธิ์ระดับรายการ ไม่ใช่เพียงว่า Login ก่อนใช้งาน

การเลือก Diagram ควรมาจากคำถาม หากต้องอธิบายการอนุมัติให้ฝ่ายปฏิบัติการเข้าใจ Flowchart อาจเพียงพอ หากต้องอธิบายว่าฝั่งเว็บเรียก API แล้วฐานข้อมูลบันทึกเมื่อใด Sequence Diagram จะชัดกว่า

ตัวอย่างสมมติ: ออกแบบระบบรับคำขอ

Requirement ระบุว่าผู้ยื่นเห็นเฉพาะคำขอของตนและเจ้าหน้าที่เห็นงานในทีม แบบจึงต้องมีความสัมพันธ์คำขอกับเจ้าของและทีม มีตารางสิทธิ์สำหรับการอ่านและเปลี่ยนสถานะ และมีหน้ารายการที่กรองตามสิทธิ์ ฝั่งเซิร์ฟเวอร์ต้องตรวจซ้ำเมื่อเรียกข้อมูลด้วยรหัสโดยตรง หากไม่มีการตัดสินใจนี้แต่แรก อาจต้องแก้ทั้งฐานข้อมูล API และหน้าจอภายหลัง

แบบที่พอเริ่มได้และจุดที่ยังไม่แน่ใจ

ก่อนพัฒนา ให้ทีมตอบได้ว่าใครทำงานหลัก ข้อมูลใดเป็นแหล่งจริง กฎสำคัญอยู่ที่ใด จะตรวจรับอย่างไร และหากระบบพึ่งบริการภายนอกจะทำอย่างไรเมื่อเชื่อมไม่สำเร็จ เรื่องที่ยังไม่รู้ควรระบุเป็นสมมติฐานพร้อมวิธีทดลอง ไม่ต้องออกแบบทุกหน้าล่วงหน้าในรายละเอียดเดียวกัน แนวคิดนี้สอดคล้องกับการพัฒนาแบบ Iterative ที่ปรับแบบตามข้อมูลจริง

ในรายงาน ให้แสดงเหตุผลของทางเลือกและสิ่งที่แบบยังไม่ครอบคลุม แยก Diagram เชิงธุรกิจออกจาก Diagram เชิงเทคนิค และอธิบายว่าภาพแต่ละภาพตอบคำถามอะไร ไม่ใช้ภาพตกแต่งแทนข้อกำหนดที่ตรวจได้

อ่าน 5 Diagram สำคัญ และ Requirement Analysis หรือดู บริการพัฒนา Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

ลองกำหนดกรณีศึกษาเป็น ระบบอนุมัติคำขอที่มีผู้ขอและหัวหน้า และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้

หลักฐานที่ควรแสดงคือ User Flow, แบบข้อมูล, สถานะ, สิทธิ์ และสัญญา API ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ ทีมพัฒนาอธิบายทางปกติและทางผิดพลาดได้ก่อนเขียนโค้ด ส่วนข้อจำกัดที่ต้องระบุคือ ไม่จำเป็นต้องวาดทุกคลาสหรือทุกหน้าจอหากยังไม่มีผลต่อการตัดสินใจ หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• IBM: What is the software development life cycle? — บทบาทของขั้นออกแบบในวงจร
• Object Management Group: UML 2.5.1 — แบบจำลองมาตรฐานสำหรับโครงสร้างและพฤติกรรมระบบ