อ่าน ERP ที่ยังมีชีวิต: จากหน้าเว็บกลับไปหาความหมาย
ฝึกอ่านระบบโดยไม่เริ่มจากการตัดสินว่า code เก่าผิด แต่เริ่มจากผู้ใช้กำลังทำงานอะไรและหลักฐานใดพิสูจน์ได้
โจทย์กรณีศึกษา
ระบบมีตาราง User, Module, ModuleGroup, UserModule, UserLog และ AddressEmp แต่ไม่มี foreign key และตัวพิมพ์เล็ก–ใหญ่ของรหัสพนักงานไม่สม่ำเสมอ ผู้เรียนต้องสร้างแผนที่สิทธิ์และเมนูโดยไม่ทำให้ประวัติหาย
คำถามนำ
User.UserIDเป็น account identity หรือ employee identity?UserModule.Authority=1..6หมายถึง CRUD ตรง ๆ หรือเป็นระดับข้อมูลลับด้วย?- ทำไม
UserLog.ModuleIDยาว 4 แต่Module.ModuleIDยาว 10? - คนลาออกแต่มีประวัติใช้งานควรถูกลบหรือยังคงเป็น historical actor?
วิธีทำ Evidence Ledger
| Claim | Evidence | ระดับความมั่นใจ | การตัดสินใจ |
|---|---|---|---|
| รหัสผู้ใช้เชื่อมพนักงาน | ตัวอย่าง SR036/BP015 ปรากฏทั้งสองตาราง | สูง แต่ case ต่างกัน | สร้าง normalized key และเก็บ legacy value |
| Authority 4–6 คือ Super User | UI เดิมแยกหัวข้อข้อมูลลับ | สูง | ห้ามลดเหลือ CRUD 3 ระดับ |
| เมนูเรียงตามฝ่าย | ModuleGroupID และพฤติกรรม top menu | สูง | รักษา order by ID |
Lab: Trace หนึ่ง feature ให้ครบ
- เลือกหน้า “กำหนดสิทธิผู้ใช้ระบบ” และบันทึก input/output ที่ผู้ใช้เห็น
- ค้นหา route และ SQL ทุกจุดที่อ่าน/เขียน
UserModule - สร้าง data-flow diagram ตั้งแต่ checkbox ถึง row ที่เปลี่ยน
- ทดสอบ authority ทั้ง 6 ค่า รวม user ที่ไม่มี AddressEmp
- ออกแบบ schema ใหม่โดยเก็บ
legacy_user_id,legacy_module_idและ audit - เขียน reconciliation query: จำนวนสิทธิ์เดิมต้องเท่าจำนวนสิทธิ์ใหม่รวม orphan
ห้ามทำ
ห้าม join แบบเดาแล้วทิ้ง row ที่ไม่ match ห้าม hash password ซ้ำโดยไม่ทราบ encoding chain และห้ามตีความผู้ใช้หมดอายุว่าเป็นพนักงานลาออกเสมอผลส่งมอบ
- Context diagram 1 หน้า
- Evidence ledger อย่างน้อย 12 claims
- Field map source → target พร้อม transform rule
- รายการ unknown และคำถามที่จะถามเจ้าของระบบ
- SQL reconciliation ก่อน/หลัง migration