AdminTee รายงานตัวประจำวันเสาร์ที่ 3 มกราคม 2569 ครับ เป็นอย่างไรกันบ้างครับกับสัปดาห์แรกของปีใหม่? ในตอนที่แล้ว (Ep.22) เราได้ติดเครื่องยนต์เรือเร็วด้วยแนวคิด Agile ที่เน้นความรวดเร็วคล่องตัวกันไปแล้ว
แต่ช้าก่อนครับ… ความเร็วถ้าขาด “ระเบียบ” อาจนำไปสู่หายนะได้ ลองนึกภาพดูนะครับ ถ้าเราปล่อยให้กรม ก. สร้างปืนใหญ่ขนาด 5 นิ้ว แต่กรม ข. ดันผลิตลูกปืนขนาด 6 นิ้วออกมา สุดท้ายปืนก็ยิงไม่ได้ใช่ไหมครับ? ในโลกของการพัฒนาระบบก็เช่นกัน หากต่างคนต่างเขียนโค้ดตามใจฉัน (Free Style) สุดท้ายระบบจะเอามาประกอบร่างกันไม่ได้
วันนี้ใน ตอนที่ 23 เราจะมาพูดถึง “Standard Framework” หรือ “แม่พิมพ์กลาง” ที่จะเป็นตัวกำหนดมาตรฐานให้ทุก Module ของกองทัพเรือ สามารถเชื่อมต่อกันได้อย่างสนิทแนบแน่นเหมือนตัวต่อเลโก้ครับ
บทที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy)
จุดประสงค์: แก้ปัญหา Bias และดึงเจ้าของงาน (Users) มาเป็นผู้ร่วมสร้าง
ตอนที่ 23/80: การสร้าง Standard Framework: เพื่อให้ Module ของแต่ละหน่วยมาประกอบร่างกันได้ การกระจายงานให้หลายหน่วยช่วยกันทำ (Decentralized) เป็นเรื่องดี แต่ต้องอยู่ภายใต้ “กติกาเดียวกัน” ครับ เพื่อให้มั่นใจว่าเมื่อนำงานมารวมกันแล้ว จะไม่เกิดอาการ “สำสำลักข้อมูล” หรือ “Error กระจาย” โดยเราจะใช้หลักการดังนี้:
1. ภาษาเดียวกัน (Naming Convention & Data Dictionary):
- ปัญหา: กรมกำลังพล ตั้งชื่อตัวแปรเก็บเลขบัตรประชาชนว่า
citizen_idแต่ กรมการเงิน ตั้งชื่อว่าid_card_num… ผลคือ ระบบคุยกันไม่รู้เรื่อง เพราะเข้าใจว่าเป็นคนละข้อมูล - ทางออก: สร้าง “พจนานุกรมข้อมูลกลาง” (Data Dictionary) ที่ระบุชัดเจนว่า ข้อมูลพื้นฐานทุกอย่างต้องใช้ชื่อภาษาอังกฤษว่าอะไร (Standard Naming) ใครจะเขียน Module ใหม่ ต้องมาเปิดคัมภีร์เล่มนี้ก่อนตั้งชื่อตัวแปร
- เปรียบเทียบ: เหมือนทหารเรือทั่วโลก ใช้รหัสสัญญาณธง (Flag Signals) มาตรฐานเดียวกัน เพื่อให้สื่อสารกันเข้าใจแม้อยู่คนละประเทศ
2. หน้าตาเดียวกัน (UI/UX Consistency):
- ปัญหา: กรมพลาฯ ชอบสีเขียว เลยทำปุ่มสีเขียว กรมช่างฯ ชอบสีเหลือง เลยทำปุ่มสีเหลือง พอผู้ใช้งาน (User) ต้องใช้ทั้งสองระบบ ก็จะงงว่าตกลงปุ่มไหนคือปุ่ม “ตกลง” กันแน่
- ทางออก: สร้าง “Navy Design System” เป็นชุดโค้ดหน้ากากมาตรฐาน (Theme) ที่กำหนดเลยว่า
- ปุ่ม “บันทึก” ต้องเป็นสีน้ำเงินเข้ม (Navy Blue) เท่านั้น
- ฟอนต์ต้องใช้ “TH Sarabun New” ขนาด 16 เท่านั้น
- ตำแหน่งปุ่มต้องอยู่ “ขวาล่าง” เสมอ
- ผลลัพธ์: ไม่ว่า User จะเข้าใช้งาน Module ไหน ก็จะรู้สึกคุ้นเคย ใช้งานเป็นทันทีโดยไม่ต้องเรียนรู้ใหม่
3. แม่พิมพ์กลาง (Navy Base Module):
- แนวคิด: แทนที่จะเริ่มเขียนโค้ดจากศูนย์ (Blank Page) ทีม Dev ส่วนกลาง (สสท.ทร.) จะสร้าง “แม่พิมพ์” (Base Template) แจกจ่ายให้ทุกหน่วย
- การใช้งาน: ใครจะสร้างระบบใหม่ ให้ Copy แม่พิมพ์นี้ไปใช้ ซึ่งในแม่พิมพ์จะมีระบบรักษาความปลอดภัย ระบบ Log และการเชื่อมต่อฐานข้อมูล เตรียมไว้ให้เสร็จสรรพ ลดเวลาการเขียนโค้ดพื้นฐาน และรับประกันว่ามาตรฐานไม่ตกหล่น
4. ข้อจำกัดและอุปสรรค (The Constraints)
- Ego ของนักพัฒนา: โปรแกรมเมอร์แต่ละคนมักมี “ลายเซ็น” หรือสไตล์การเขียนโค้ดเป็นของตัวเอง การบังคับให้เขียนตาม Pattern กลาง อาจทำให้รู้สึกอึดอัดและต่อต้านในช่วงแรก
- ความยุ่งยากในการอัปเดต: หากมีการเปลี่ยนมาตรฐานกลาง (เช่น เปลี่ยนธีมสีใหม่) ทุก Module ที่กระจายอยู่ตามหน่วยต่างๆ ต้องทำการอัปเดตตามไปด้วย ซึ่งต้องมีการบริหารจัดการเวอร์ชัน (Versioning) ที่แม่นยำ
5. ข้อแนะนำและข้อเสนอแนะ (Recommendations)
- Linter & Code Formatter: ใช้เครื่องมืออัตโนมัติ (Automated Tools) ในการตรวจจับโค้ดที่ผิดมาตรฐาน เช่น ถ้าใครตั้งชื่อตัวแปรผิดกฎ ระบบจะขีดเส้นแดงเตือนทันทีเหมือนตรวจคำผิดใน Word
- Library กลาง: รวบรวมฟังก์ชันที่ใช้บ่อยๆ เช่น “ฟังก์ชันแปลงเลขไทย-อารบิก” หรือ “ฟังก์ชันคำนวณวันเกษียณ” เก็บไว้ใน Library กลาง ให้ทุกคนกดเรียกใช้ได้เลย ไม่ต้องเสียเวลาเขียนใหม่
บทสรุป
การสร้าง Standard Framework ไม่ใช่การจำกัดจินตนาการ แต่เป็นการ “สร้างรากฐานของความสามัคคีทางดิจิทัล” ครับ หากเราเปรียบ Odoo ของกองทัพเรือเป็น “สถานีอวกาศ” ที่ประกอบขึ้นจากยานหลายลำมาเชื่อมต่อกัน (Docking) การมี “หัวต่อ” (Interface) ที่เป็นมาตรฐานสากล คือสิ่งเดียวที่จะทำให้สถานีอวกาศนี้คงอยู่ได้ ไม่แตกออกเป็นเสี่ยงๆ และสามารถรองรับโมดูลใหม่ๆ ที่จะมาเชื่อมต่อในอนาคตได้อย่างไร้รอยต่อครับ
(อ้างอิง: หลักการ Software Design Patterns และ คู่มือมาตรฐานการแลกเปลี่ยนข้อมูลภาครัฐ)
คำถามชวนคิด (เพื่อการมีส่วนร่วม)
- ท่านเคยเข้าเว็บของหน่วยงานราชการ 2 เว็บ แล้วรู้สึกว่าหน้าตาต่างกันราวฟ้ากับเหว จนงงว่าใช้งานยังไงไหมครับ?
- ถ้าต้องเลือกระหว่าง “อิสระเสรี แต่คุยกับใครไม่รู้เรื่อง” กับ “อยู่ในกรอบระเบียบ แต่ทำงานร่วมกันได้ราบรื่น” ท่านจะเลือกแบบไหนในการทำงาน?
- ท่านคิดว่า “สิ่งของ” อะไรในกองทัพเรือ ที่มีมาตรฐานเดียวกันเป๊ะๆ แล้วทำให้ชีวิตท่านง่ายขึ้น? (เช่น ขนาดซองกระสุน, หัวจ่ายน้ำมัน)
ติดตามตอนต่อไป
เมื่อทุกคนเขียนโค้ดตามมาตรฐานแล้ว แต่ถ้าต่างคนต่างแก้ไฟล์เดียวกันพร้อมกัน ข้อมูลจะทับกันมั่วไหม? ใครเซฟทับใคร? ในตอนหน้า Ep.24/80 “GitHub / GitLab สำหรับ ทร.: การจัดการ Version Control ร่วมกันทั้งกองทัพ” เราจะมารู้จัก “ไทม์แมชชีน” สำหรับนักพัฒนา ที่จะช่วยจัดการประวัติการแก้ไขโค้ด และป้องกันอุบัติเหตุ “ไฟล์หาย-งานพัง” ได้ 100% ห้ามพลาดครับ!
Talk is cheap. Show me the code.