การเขียนไฟล์ CHANGELOG.md คือการบันทึกการเปลี่ยนแปลงที่สำคัญในโปรเจกต์ ซึ่งช่วยให้ทีมงานและผู้ใช้งานทราบถึงฟีเจอร์ใหม่ การแก้ไขบั๊ก หรือการเปลี่ยนแปลงในซอฟต์แวร์ที่ถูกปล่อยออกมา การมี CHANGELOG.md ที่ชัดเจนและสม่ำเสมอเป็นวิธีที่ดีในการรักษาความโปร่งใสและการติดตามการพัฒนาโปรเจกต์ ซึ่งสามารถนำไปใช้ได้ทั้งในโปรเจกต์ส่วนตัวและในองค์กร
ทำไมต้องมี CHANGELOG.md?
การเขียน CHANGELOG.md มีประโยชน์หลายประการ เช่น:
- ติดตามการเปลี่ยนแปลง: คุณสามารถดูประวัติการเปลี่ยนแปลงของโปรเจกต์ได้อย่างง่ายดาย
- การจัดการเวอร์ชัน: ช่วยให้ทีมสามารถดูได้ว่าเวอร์ชันไหนมีการแก้ไขอะไรบ้าง
- ความโปร่งใส: ช่วยให้ผู้ใช้และนักพัฒนาทราบถึงฟีเจอร์ใหม่หรือบั๊กที่ได้รับการแก้ไข
- การตรวจสอบย้อนกลับ: หากมีปัญหาเกิดขึ้นในเวอร์ชันใหม่ คุณสามารถตรวจสอบได้ทันทีว่าเกิดจากการเปลี่ยนแปลงในส่วนใด
แนวทางการเขียน CHANGELOG.md
- รูปแบบของไฟล์
CHANGELOG.md
ส่วนใหญ่แล้วไฟล์ CHANGELOG.md จะมีรูปแบบดังนี้:
# Changelog
## [Unreleased]
### Added
- ฟีเจอร์ใหม่ที่ถูกเพิ่มเข้ามา
### Changed
- การเปลี่ยนแปลงที่สำคัญในฟีเจอร์
### Fixed
- การแก้ไขบั๊ก
## [1.0.0] - 2024-12-01
### Added
- ฟีเจอร์ใหม่ เช่น ระบบล็อกอิน
### Changed
- การปรับปรุง UI ของหน้าหลัก
### Fixed
- แก้ไขบั๊กที่ทำให้โปรแกรมค้างเวลาโหลดหน้า
## [0.9.0] - 2024-11-15
### Added
- ระบบการแจ้งเตือนใหม่
- วิธีการจัดประเภทการเปลี่ยนแปลง
เมื่อเขียน CHANGELOG.md ควรจะมีการจัดประเภทการเปลี่ยนแปลงต่างๆ เพื่อให้สามารถเข้าใจได้ง่ายขึ้น:
- Added: ฟีเจอร์ใหม่ที่เพิ่มเข้ามาในโปรเจกต์
- Changed: การปรับปรุงหรือการเปลี่ยนแปลงในฟีเจอร์เดิม
- Fixed: การแก้ไขบั๊กหรือปัญหาที่เกิดขึ้น
- Deprecated: ฟีเจอร์ที่กำลังจะถูกยกเลิกในอนาคต
- Removed: ฟีเจอร์ที่ถูกลบออกไปจากโปรเจกต์
- Security: การอัพเดตที่เกี่ยวข้องกับความปลอดภัย
- การใช้หมายเลขเวอร์ชัน
ตามหลักการ Semantic Versioning (SemVer) เวอร์ชันจะประกอบด้วย 3 ส่วนหลักๆ:
- Major: การเปลี่ยนแปลงที่ไม่สามารถเข้ากันได้กับเวอร์ชันเก่า (เช่นการลบฟีเจอร์เดิมหรือเปลี่ยน API)
- Minor: การเพิ่มฟีเจอร์ใหม่ที่สามารถทำงานร่วมกับเวอร์ชันก่อนหน้าได้
- Patch: การแก้ไขบั๊กหรือข้อผิดพลาดที่ไม่กระทบกับฟีเจอร์ที่มีอยู่
ตัวอย่าง:
1.0.0(Major: 1, Minor: 0, Patch: 0)1.1.0(Minor update)1.0.1(Patch update)
- การอ้างอิงการเปลี่ยนแปลงในโค้ด
เมื่อทำการแก้ไขบั๊กหรือเพิ่มฟีเจอร์ ควรจะอ้างอิงถึงหมายเลข issue หรือ pull request ที่เกี่ยวข้องในส่วนของการเปลี่ยนแปลง เช่น:
### Added
- ฟีเจอร์ใหม่สำหรับการค้นหาในหน้าแรก (#45)
- เวอร์ชันที่ไม่ถูกปล่อย
ในกรณีที่โปรเจกต์ยังไม่ถึงเวอร์ชันที่ปล่อยออกมา หรืออยู่ในสถานะพัฒนา คุณสามารถใช้ [Unreleased] สำหรับเวอร์ชันนั้น ๆ โดยการบันทึกการเปลี่ยนแปลงที่ยังไม่ได้ปล่อยจริง ๆ
ตัวอย่างไฟล์ CHANGELOG.md
# Changelog
## [Unreleased]
### Added
- เพิ่มระบบค้นหาสำหรับผู้ใช้งาน
### Changed
- ปรับปรุงประสิทธิภาพของหน้าแสดงผล
## [1.0.0] - 2024-12-01
### Added
- เพิ่มฟีเจอร์การลงทะเบียนผู้ใช้ใหม่
### Fixed
- แก้ไขปัญหาที่เกิดจากการโหลดข้อมูลที่ช้า
สรุป
การเขียนไฟล์ CHANGELOG.md เป็นวิธีที่ดีในการจัดระเบียบการเปลี่ยนแปลงที่เกิดขึ้นในโปรเจกต์ ช่วยให้ทีมสามารถติดตามการพัฒนาและการแก้ไขปัญหาต่างๆ ได้ง่ายดาย โดยการใช้ระบบการจัดประเภทการเปลี่ยนแปลง เช่น Added, Fixed, Changed, และอื่น ๆ ช่วยให้ผู้พัฒนาทุกคนสามารถเข้าใจได้ว่าการเปลี่ยนแปลงเหล่านั้นเกี่ยวข้องกับอะไรบ้าง และจะส่งผลกระทบกับโปรเจกต์อย่างไร