Step back from requirement

สมมติเราทำระบบบัญชีระบบนึง มีประเภทของ Transaction 3 แบบ คือ X,Y,Z

ถ้า Requirement แรกบอกว่าทุกๆ “รายการ Transaction ทุกอันต้องหักเงินในบัญชีลูกค้า”

account.debit(transaction.amount);

แล้วพอทำไปซักพักเขาบอกว่า “รายการทุกรายการนั่นแหละ ยกเว้น Transaction ประเภท X ต้องหักเงินลูกค้า”

หลายๆ ครั้ง ฟังแล้วเราอาจจะ Implement เป็น

if (transaction.type == TransactionType.X) return;
account.debit(transaction.amount);

แล้วถ้าตรงข้าม Stakeholder บอกว่า “รายการประเภท Y,Z ให้หักบัญชีลูกค้านะ ส่วนรายการประเภท X ไม่ต้องหักบัญชี”

หลายๆ ครั้งเขาบอกแบบนี้ เราก็จะ Implement กันแบบนี้

switch (transaction.type) {
   case TransactionType.X: break;
   case TransactionType.Y:
   case TransactionType.Z:
      account.debit(transaction.amount);
      break;
}

สิ่งที่น่าคิดคือ Requirement 2 ตัวนี้ จริงๆ เหมือนกันทุกประการ ต่างกันแค่วิธีการบอกของลูกค้า

คำถามคือ

• แบบแรกกับแบบหลัง อันไหนอ่านง่ายกว่ากัน และ Maintain ง่ายกว่ากัน
• ทำไมสิ่งที่เหมือนกันเราถึง Implement เป็น 2 แบบ
• ความง่ายของการ Maintain software ของเราขึ้นอยู่กับลำดับและวิธีเล่าเรื่องของลูกค้า หรืออยู่ในกำมือเรากันแน่

ทุกคนอาจจะตอบคำถามว่าแบบไหนดีกว่ากันไม่เหมือนกัน และผมจะไม่ขอกล่าวถึงว่าอันไหนดีกว่าอันไหนในบทความนี้

เพราะไม่ว่าคุณจะคิดว่าอันแรกดีกว่าหรืออันหลังดีกว่าก็ตามแต่

สิ่งที่ต้องระวังที่ผมอยากสื่อคือ

เราต้องมีสติรู้ว่า Implement แบบไหนทำให้ Maintain ง่าย

มิใช่ปล่อยให้ Implementation มันไหลไปตามการเล่าเรื่องของลูกค้า

ถอยหลังออกมาดูภาพรวมบ้างนะครับ