Reading time – 4 minutes

ช่วงนี้ Thailand 4.0 ถูกพูดถึงอย่างแพร่หลาย เป็นอีกเป้าหมายหนึ่งของประเทศที่จะพัฒนา เลยนึกถึงว่าก่อนหน้านี้ก็มี version 1.0, 2.0, 3.0 หรือ 3.9 มาแล้วเป็นแน่ อันนี้เป็น version ของโมเดลนโยบายเศรษฐกิจ

ทีนี้ในมุมของ Software Development  บ้างหล่ะ

React and ANGULAR versions

การพัฒนา Framework และ API ทำให้เกิดความเปลี่ยนแปลงอย่างต่อเนื่อง ตัวเลขของ version จะสื่อสารออกมาอย่างไรเพื่อให้เข้าใจง่าย เลยเป็นที่มาของการปรับเลข  version เพื่อให้สื่อความหมาย

เลข Version  สำคัญไฉน

ลองนึกว่าถ้าเราเขียน Framework  หรือ API ให้คนอื่นใช้งาน แล้วไม่ได้ระบุ version มันจะเป็นยังไงได้บ้าง

  • อาจจะมีคำถาม “ทำไมหลังจากลอง upgrade library ตัวใหม่แล้วเปิดเอกสารเก่าไม่ได้แล้วหล่ะ
  • หรือ “แอพที่เขียนไว้ ตอนนี้ดึงข้อมูลจาก API ใหม่ไม่ได้แล้ว

เราถึงจำเป็นต้องเลข version เพื่อสื่อสารกับคนใช้งาน


 

Semantic Versioning

แล้วทีนี้ Semantic Version เป็นอย่างไร โดยหลักการก็อ้างอิงไปที่  “Semantic Versioning 2.0.0” จากเวบ http://semver.org/ แบบที่เป็นทั่วๆไป จะประกอบด้วยตัวเลข 3 ส่วนคั่นด้วย  “.” เหมือนในรูปนี้

Semantic Versioning Pattern

  1. Major version
    • เป็นตัวเลขหลักของ API หรือ Framework เช่น version 1.0.0 มักใช้กับการออกสู่ตลาดหรือพร้อมใช้งานเป็นครั้งแรก
    • ถ้ามีการเปลี่ยนแปลงเลขนี้ แสดงว่า API มีผลต่อการเรียกใช้งานในเวอร์ชั่นก่อนหน้านี้ (Incompatible API Changes)
  2. Minor version
    • มีการเพิ่ม feature ใหม่เข้าไป
    • API ยังคงใช้งานได้กับคนที่ใช้งานอยู่แล้ว  (Back-ward compatible)
  3. Patch version
    • แก้บั๊ก โดยไม่ได้มีการเพิ่ม  feature ใหม่เข้าไป
    • API ยังคงใช้งานได้กับคนที่ใช้งานอยู่แล้ว  (Back-ward compatible)

การทำ Version นั้นไม่ยาก แต่มีประโยชน์มาก

  • Clearer compatibility and dependencies – จะทำให้เห็นชัดว่า API ที่เราจะใช้ มันสามารถทำงานร่วมกับโปรแกรมเก่าเราได้ไหม
  • Encourage well-defined API –  ในฐานะคนที่ออกแบบ API  จะถูกกระตุ้นให้คิดถึงผลกระทบที่ตามมาจากการเพิ่มหรือพัฒนา feature ของ  API มากขึ้น เพราะมีผลทำให้โปรมแกรมก่อนหน้านี้ใช้งานไม่ได้
  • Clearer decision for upgrading – ทำให้คนที่เรียกใช้งาน API เห็นผลกระทบจากการ upgrade  ไปใช้  version ใหม่ชัดเจน ส่งผลให้สามารถตัดสินใจว่าจะเปลี่ยนไปใช้ version ที่ใหม่กว่าหรือไม่ ได้ง่ายขึ้นจาก

ตัวอย่างจาก Angular 2.x.x

ANGULAR changelog
reference: https://github.com/angular/angular/blob/master/CHANGELOG.md

จะเห็นได้ว่ามีการเพิ่ม features หลักๆ เข้าไปหลายตัวทีเดียว และมีการปรับแก้ performance

แต่ว่าคนที่ใช้ Angular 2.x.x  ก่อนหน้านี้ จะยังคงใช้ code ชุดเดิมต่อไปได้ถึงจะมีการ upgrade แล้วก็ตาม

ส่วนตัวอย่างการ Upgrade Angular 1.x. -> Angular 2.x.x อันนี้ก็ชัดเจนว่ามีการเปลี่ยนเลข Major ซึ่งมีการเกิดการ Break Backward Compatibility ตั้งแต่วิธีการเขียนจนถึง Dependencies ที่เรียกใช้


หวังว่าจะเป็นประโยชน์สำหรับการนำไปใช้ตั้งแต่การอ่าน Version  ของ Framework หรือ API จนถึงคนที่ออกแบบให้คนอื่นใช้งาน

สุดท้ายนี้ยังหวังว่าประเทศไทยจะก้าวเข้าสู่ Thailand 4.0 อย่างก้าวหน้าและมั่นคง (แต่เอ๊ะ…เกี่ยวกันไหมนะ)