เพราะการออกแบบและการสร้างซอฟต์แวร์นั้นเต็มไปด้วยสมมติฐาน รีไควเม้นต์และสเปคต่างๆที่เขียนขึ้นมาก็มีพื้นฐานมาจากความน่าจะเป็นทั้งสิ้นระหว่างการถกเถียงแลกเปลี่ยนความคิดเห็นกันในเรื่องนี้ คำถามที่ผมได้ยินบ่อยๆคือ
“คิดว่ายูเซ่อร์จะทำแบบนี้มั้ย?” — “ไม่แน่ใจเหมือนกันหวะ” … เพราะเราไม่ใช้ยูเซ่อร์ของระบบ เพราะเราไม่เข้าใจกระบวนการทำงานอย่างลึกซึ้ง มันก็ไม่แปลกที่จะไม่มีคำตอบที่ชัดเจนให้กับคำถามนี้
“งั้นเราบล็อกไม่ให้ยูเซ่อร์ทำแบบนี้จะได้มั้ย?” — คำถามนี้ตอบยาก มันเป็นส่วนผสมของขอบเขต (Boundaries) จุดสังเกต (Landmarks) และเส้นทาง (Paths) … ผมเชื่อว่าหน้าที่ของเราคือการออกแบบและกำหนดขอบเขตและจุดสังเกตที่สำคัญก่อน
ขอบเขต (Boundaries) หมายถึงวัตถุประสงค์หลักของการมีอยู่ซึ่งซอฟต์แวร์ของเรา หน้าที่หลักของมันคือทำอะไรได้และที่สำคัญ … ทำอะไรไม่ได้
จุดสำคัญ (Landmarks) หมายถึงองค์ประกอบ (จะเรียกฟีเจอร์ก็ได้) สำคัญที่ประกอบกันขึ้นมาเป็นซอฟต์แวร์ เช่น ส่วนจัดการยูเซ่อร์ ส่วนซื้อขายของ ส่วนแชร์บนโซเชี่ยล หรือส่วนออกรายงาน
เส้นทาง (Paths) หมายถึงกระบวนการใช้งานจุดสังเกตต่างๆ เปรียบเหมือนการเดินทางจากตึกเอไปตึกบี จากสนามบินซีไปห้างสรรสินค้าดี … รูปแบบการใช้งานซอฟต์แวร์ของเรานั้นออกแบบได้แต่ควบคุมและบังคับยาก
กับคำถามข้างบน “งั้นเราบล็อกไม่ให้ยูเซ่อร์ทำแบบนี้จะได้มั้ย?” — ถ้าการบล็อกครั้งนี้คือบล็อกในส่วนของเส้นทาง คำตอบดีฟ้อลท์ของผมคือ “ไม่ได้หวะ เราบังคับพวกเขาแบบนั้นไม่ได้” นอกจากจะมีเหตุผลที่หนักแน่นในเรื่องความปลอดภัยของระบบ (พาสเวิร์ดซ้ำกับยูเซ่อร์เนม) หรือเป็นการป้องกันความสับสนในการใช้งาน (หนึ่งอีเมลอ้างถึงสองยูเซ่อร์)
หลักการในการออกแบบเพื่อการมีวิวัฒนาการคือเลือกขอบเขตที่ชัดเจน กำหนดจุดสำคัญที่เหมาะสม สร้างเส้นทางหลักไว้ให้พร้อมและสุดท้ายสำคัญมากคือต้องเหลือพื้นที่ว่างให้ความจริงในการใช้งานเปิดเผยตัวตนออกมา เมื่อนั้นเราจะมีข้อมูลมากขึ้นในการตอบคำถามที่ว่า “คิดว่ายูเซ่อร์จะทำแบบนี้มั้ย?” ได้อย่างมั่นใจมากขึ้น 😇