“อัพเดตอีกแล้ว?”
มักเป็นสิ่งที่หลายๆ คนคิด ในยุคสมัยที่เครื่องมือต่างๆ พากันขยันอัพเดตตัวเองอย่างต่อเนื่อง (บางที ถี่กว่าแอพในมือถือเราอีกนะเออ)
บางทีมันก็บ่อยซะจนเรารู้สึกว่า
มันจะมีผลอะไรกับโค้ดในโปรเจคของเรามั้ยเนี่ย?
แน่นอนว่า มันไม่ได้มีแค่โปรเจคที่เพิ่งทำใหม่ แต่มันหมายถึงโปรเจคเก่าๆ ที่เราทำไปแล้วด้วย
- ตกลงต้องรื้อโค้ดไหม?
- ทำไมอัพแล้ว Bug ยังไม่หาย?
- ทำไมจู่ๆ โปรเจคก็พัง?
ความไม่แน่นอนพวกนี้ที่เกิดขึ้นในใจของนักพัฒนา อาจจะส่งผลถึงสุขภาพจิต และการดำเนินชีวิตของเราได้เลยทีเดียว
ซึ่งถ้าเราเข้าใจรูปแบบของ “เลขเวอร์ชั่น” ที่มักใช้กันในเครื่องมือพัฒนาต่างๆ เราก็สามารถรับมือชิลล์ๆ กับการเปลี่ยนแปลงที่ไม่มีวันหยุดของมันได้ รวมถึง Ionic Framework ด้วย ครับ
เลขเวอร์ชั่น? (Versioning)
“เฮ้ย ตอนนี้เรามาใช้ Google Flutter 0.3.2 แล้วนะ”
“ไอเจ้า 0.3.2 นี่มันคืออะไรอ้ะ?”
ตอนแรกพลก็คิดแบบนี้ครับ ถ้ามองผิวเผินมันเหมือนแค่ตัวเลขเอาไว้เช็คว่า เราใช้เวอร์ชั่นเดียวกับเพื่อน เราใช้ตัวเดียวกับที่โครงการกำหนดมา
แต่จริงๆ แล้ว พวกนี้มีความหมายมากกว่าที่เห็นครับ
เลข 3 ส่วนนี้ คือเลขที่ใช้บอกอดีต ปัจจุบัน และอนาคตของเครื่องมือที่เราใช้ได้เลยล่ะเอ้อ
โดยวิธีการกำหนดเลขทศนิยม 3 หลักนี้ เป็นมาตรฐานหนึ่งที่ปัจจุบันถูกใช้ในการกำหนดความคืบหน้าของซอฟต์แวร์ และระบบต่างๆ เรียกกันว่า Semantic Versioning
ซึ่งแต่ละส่วนแบ่งออกเป็นดังนี้
Major.Minor.Patch
อย่าง Ionic 4 ที่โค้ชพลแนะนำให้รู้จักกับ รวมถึงพวกเครื่องมือที่จัดอบรมอย่าง
- React Native
- Google Flutter
- MEAN Stack
- Xamarin
- รวมไปถึงโปรแกรม และแอพพลิเคชั่นต่างๆ ปัจจุบันก็ใช้ Semantic Versioning ในการกำหนด และอ้างอิงการพัฒนาทั้งหมด
ดังนั้นการเข้าใจบทบาทหน้าที่ของเลขแต่ละตัว จะทำให้พวกเราดำเนินโครงการพัฒนาระบบ หรือแอพพลิเคชั่นได้ชิลล์ขึ้นอีกครับ
เริ่มจากเลข Patch
x.x.Patch/Build
สำหรับ Patch มันคือการแก้ข้อผิดพลาดของระบบ, ซอฟต์แวร์, หรือแอพพลิเคชั่นนั้นๆ เรียกว่าเป็นตัวเลขที่บ่งบอกถึงการปราบบั๊กล้วนๆ เลยครับ
อาจจะเป็นการแก้ความผิดพลาด หรือการเปลี่ยนแปลงเล็กๆ น้อยๆ ที่ทำให้ผู้ใช้สามารถพิจารณาอัพเดตได้อย่างสบายใจ (เรียกว่า low risk หรือความเสี่ยงต่อโปรเจคน้อยนั่นเอง)
ถ้าตัว Framework หรือระบบมีข้อผิดพลาด การแก้ไขในแต่ละรอบ จะกลายมาเป็นตัวเลขที่เพิ่มขึ้นในส่วนของ Patch ใน Semantic Versioning นั่นเอง
ซึ่ง Patch/Build จะแตกต่างจากเพื่อนๆ อีก 2 ตัวคือ Minor และ Major ซึ่งจะอธิบายเพิ่มเติมด้านล่าง
ตัวอย่างการทำงานจริงก็คือ สำหรับ Ionic ทีมพัฒนาจะมีรอบการปล่อย Patch ทุก 2 อาทิตย์ หรือเร็วกว่าในกรณีเร่งด่วน
ของใหม่กับเลข Minor
x.Minor.x
เลข Minor มักมาพร้อมกับความสามารถใหม่ๆ (Feature) ที่มาพร้อมกับตัว Framework หรือซอฟต์แวร์ และเป็นการอัพเดตที่ไม่ทำให้เกิด Major change หรือการเปลี่ยนแปลงสำคัญ
ซึ่งหลายๆ ครั้ง ของใหม่พวกนี้ ก็มักมาจากความต้องการของทางผู้ใช้ หรือชุมชนนักพัฒนานี่แหละ
แน่นอนว่าการปล่อยของใหม่ๆ ทางทีมพัฒนาต้องมีการทดสอบอย่างหนักหน่วง เพื่อให้แน่ใจว่าการเพิ่มเลข Minor นี้จะเป็นการเติบโตที่ราบรื่น
ดังนั้น Minor นี้เราจะเรียกว่าเป็น medium risk หรือเวอร์ชั่นที่มีความเสี่ยงปานกลางในกรณีที่มีปัญหาเกิดขึ้นจาก Minor ใหม่นี้ ก็จะมี Patch/build ตามมาติดๆ ครับ
ก้าวสู่ยุคหน้าด้วยเลข Major
Major.x.x
Major มักมาพร้อมกับความเปลี่ยนแปลงที่ค่อนข้างใหญ่ อาจจะเป็นการเพิ่มความสามารถชุดใหญ่ หรือกระทั่งเปลี่ยนแปลงแนวคิดของเครื่องมือ (อย่างเช่น AngularJS ไปเป็น Angular 2 ที่ทำนักพัฒนากรีดร้องไปตามๆ กัน)
จึงทำให้เจ้า Major นี่จัดอยู่ในระดับ High risk (ความเสี่ยงสูงต่อโปรเจค) ที่ต้องใส่ใจให้ดีในการอัพเกรดไปใช้
ดังนั้นการเปลี่ยน Major version มักจะมีการห้อยท้ายว่า “RC” (Release Candidate) หรือ Preview หรือ Beta เพื่อรับฟังปัญหา และข้อเสนอแนะจากผู้ใช้ หรือชุมชนนักพัฒนา เป็นระยะหนึ่ง
ก่อนที่จะยืนยันเวอร์ชั่นใหม่ โดยการถอดคำว่า RC ออกจากชื่อ ซึ่งหลังจากนี้ก็จะเข้าสู่การนับเลข Patch หรือ Minor ตามที่อธิบายไว้ด้านบนนั่นเอง
เช่นใน Ionic 4 ที่กำลังจะมาถึง จะมี
- การรองรับ Progressive Web Application
- การเพิ่ม engine ในการประมวลผลใหม่
- และเครื่องมือที่มาไล่เช็คการเปลี่ยนแปลงที่จำเป็นในโปรเจคเก่าของเรา เพื่อความสะดวกสบาย เป็นต้น
สิ่งที่ควรรู้ในการทำงานจริง
ที่นี้นอกจากเลขเวอร์ชั่นแล้ว สิ่งสำคัญอีกอย่างหนึ่งที่ควรรู้จัก และนึกถึง ก็คือ Chang log ครับ
Change Log?
change log จะเป็นไฟล์ๆ หนึ่ง หรือหน้าเว็บสักหน้าหนึงที่อุทิศให้กับการเปลี่ยนแปลงสำคัญต่างๆ ที่ออกมาในแต่ละเวอร์ชั่นนั่นเองครับ
ลองดู Change Log ของเครื่องมือต่างๆ อย่าง
- Ionic
- React Native
- Angular
- Xamarin (เจ้านี้ค่อนข้างจะยิ่งใหญ่ เพราะมีเครื่องมือหลากหลายเหลือเกิน)
- NodeJS
ซึ่ง change log นั้นมีประโยชน์มากมายมหาศาล ในฐานะที่เราอยู่ในฝ่ายนักพัฒนา (Developer) ควรใช้ change log ในบทบาทที่ต่างกันดังนี้
- ในฐานะคนที่เอาเครื่องมือมาใช้งาน Change Log จะเป็นประกาศสำคัญ ที่บอกถึงการเปลี่ยนแปลงต่างๆ ในเวอร์ชั่นนั้นๆ
- ในฐานะนักพัฒนาที่ทำระบบ หรือแอพให้คนอื่นเอาไปใช้ ก็ควรจะมี Change Log เพื่อบอกถึงการเปลี่ยนแปลงที่เราทำ (แน่นอน หมายถึงสำหรับเรา และทีมของเราด้วย)
สรุปเรื่อง Semantic Versioning
เลขเวอร์ชั่นหากดูผิวเผิน ก็คงเหมือนกับหมายเลขเอาไว้อ้างอิงการทำงานที่ผิดพลาด หรือติดตามปัญหาที่เกิดขึ้น
แต่หากดูความเป็นมาและแนวคิดแล้ว เจ้าเลข 3 ส่วนนี้มันเป็นการเชื่อมโยงสิ่งที่อยู่ในฝั่งผู้สร้าง กับผู้ใช้ได้อย่างเป็นระบบได้เป็นอย่างดีทีเดียว
ใครยังไม่เคยใช้ ลองเอาไปใช้กับโปรเจคตัวเองดูครับ พลและหลายๆ คนใช้แล้ว ชีวิตดีย์ขึ้นเยอะ
ติดตามเรื่องใหม่ๆ แนวคิดดีๆ แบบนี้ได้ผ่านช่องทางด้านล่าง…
- อัพเดตก่อนใคร แค่ติดตามทางแฟนเพจ
- คลิปดีๆ ทาง YouTube