การทำหรือเผา Data Dictionary ที่มีประสิทธิภาพ

ตอนนี้โปรเจคที่ผมกำลังเข้าช่วงโค้งสุดท้ายในการลงนาม ตรวจรับ สิ่งที่สำคัญที่สุด คือ การเผา เอกสารครับ ตอนนั้นมีเอกสารในส่วนของฐานข้อมูล ผมขอเรียกมันว่า Data-Dict นะครับ ตอนแรกทีมที่ทำก็อึ้งๆ เนื่องจากโปรแกรมมีมานานและ 20 กว่าปี แต่ไม่เคยมี Data-Dict ที่สมบูรณ์สักที ทำไมทำมาได้ 1100 Table เพราะ มีหนี้ทางเทคนิค Technical Debt ที่เกิดจาก

• งานเร่ง เผาให้สุก ที่เหลือช่าง
• งานจบ คนจบ หลุดพ้นแล้ว
• งานจบ งานใหม่รอ
• งานปรับ (Change) แต่ของเก่าไม่รู้ว่า คือ อะไร มันไม่รองรับ ทำใหม่ดีกว่า (อันนี้เป็นปัญหาของคนที่ไม่ใช่สาย IT เลย แต่เข้ามาเกี่ยวข้องกับ Software Development ชอบคิดว่าง่าย แต่จริงๆ มันมีที่มาซับซ้อน)

แต่งาน Customize เสริมยังดีที่มีการทำ Data-Dict มาแล้ว ก่อนตะแก้ปัญหา เราต้องดูก่อนว่ามี Resource อะไรบ้าง

• น้องฝึกงาน 2 คน สายทำเอกสารโดยเฉพาะ ไม่ถัด Code
• Expert 6 คน ที่ยังรอดชีวิต
• เอกสารเก่าอีกชุดนึง
• Schema บางส่วน Dev ตัดสินใจใส่คำอธิบายลงใน DDL เลย
• มี Code Standard ในที่รี้ผมไม่ได้หมายถึงตัว Code นะครับ ผมหมายถึงฝั่งทาง Database ที่มีการวาง Pattern ที่ดีประมาณ 70% ครับ

สิ่งที่ต้องทำ

1.  ใข้ Tools เพื่อทำการ Generate ER-Diagram และ Data-Dict คร่าวๆมาก่อนครับ ได้ Comment มาด้วย
2. เนื่องจากมีรูปแบบพอสมควรใน Database เราใช้สถิติมาช่วย นับจำนวน Column ที่มันซ้ำกันเยอะที่สุดใน DB มาครับ
3. ใส่คำอธิบายของแต่ละ Column โดยอิงจากเอกสารเก่า  วางไว้ใน GoogleDoc จะได้ไม่ต้องงลเสียเวลามา Merge
4. ให้ Expert ช่วยกันมา Review
5. ให้ Expert ตรวจสอบความสัมพนัธ์ของแต่ละ Entity ใน ER ถ้ามี Table ไหน Column ไหนไม่ใช้ ให้ทำ note เก๋บไว้ ห้าม Drop นะ  เดี๋ยวบึ้ม 555
6. ระหว่างที่ Expert ทำงานให้น้องฝึกงาน เตรียมโครงเอกสารข้อมูล ตั้วต้นให้คอธิบาย เท่ากับ ชื่อ Column ทำแบบนี้ เพื่อ Search & Replace แต่ไม่ใช่ให้ไล่ Copy เอา VBA มาช่วยทำครับ
7. เมื่อ Expert ตรวจทานคำอธิบาย Column เสร็จ ให้น้องฝึกงาน Search & Replace ครับ

เผา Data Dictionary  ทันใน 1 สัปดาห์ ทั้งๆที่ แต่ละ มีงาน End Pharse หลังโปรเจคจบ งานจบ แต่ SA กับ Dev ยังต้องเก็บกวาด สิ่งที่เกิดขึ้นจากการ Estimate Time ที่ผิดพลาดครับ T......T