กลับไปหน้าบทความ
#Husky#Git Hooks#DevOps#Code Quality#Frontend

ใช้ Husky กับ Git เพื่อลดความผิดพลาดเล็กๆ ก่อนพังถึงโปรดักชัน

Husky ช่วยให้ทีมพัฒนาซอฟต์แวร์บังคับกติกาสำคัญได้อัตโนมัติผ่าน Git hooks ตั้งแต่บนเครื่องนักพัฒนา ลดปัญหาอย่างลืมรันเทสต์หรือฟอร์แมตโค้ดไม่ตรงกัน ก่อนโค้ดจะเข้า repository และหลุดไปถึงโปรดักชัน

2 มีนาคม 2569อ่านประมาณ 2 นาที

แชร์บทความ

ใช้ Husky กับ Git เพื่อลดความผิดพลาดเล็กๆ ก่อนพังถึงโปรดักชัน

ใช้ Husky กับ Git เพื่อลดความผิดพลาดเล็กๆ ก่อนพังถึงโปรดักชัน

หลายทีมมีทักษะการเขียนโค้ดที่ยอดเยี่ยม แต่ปัญหาที่ทำให้ระบบพังในความเป็นจริงกลับเป็นเรื่องเล็กๆ ที่มักถูกมองข้าม เช่น ลืมรัน test, ฟอร์แมตโค้ดไม่ตรงตามมาตรฐาน หรือเขียนข้อความ commit แบบไม่เป็นระบบ ปัญหาเหล่านี้อาจดูเล็กในระดับบุคคล แต่เมื่อรวมกันในระดับทีมและโปรเจกต์ กลับสร้างต้นทุนมหาศาลได้

Husky คือเครื่องมือที่เข้ามาช่วยแก้ปัญหานี้ โดยทำงานร่วมกับ Git hooks เพื่อบังคับขั้นตอนสำคัญแบบอัตโนมัติก่อนที่โค้ดจะถูก commit หรือ push ขึ้น remote ทำให้ทีมรักษาวินัยการพัฒนาได้โดยไม่ต้องคอยเตือนกันตลอดเวลา

Husky คืออะไร และช่วยทีมได้อย่างไร

หากจะอธิบายแบบเข้าใจง่าย การ commit เปรียบเหมือนด่านตรวจคนเข้าเมือง ส่วนการ push ก็เหมือนด่านก่อนขึ้นเครื่องบิน ขณะที่ Husky คือเจ้าหน้าที่ที่คอยตรวจทุกครั้งแบบไม่รู้จักเหน็ดเหนื่อย

จุดแข็งของ Git hooks คือมันทำงานบนเครื่องของนักพัฒนาทันที ก่อนที่โค้ดจะเดินทางไปไกลกว่านั้น นั่นหมายความว่าความผิดพลาดจำนวนมากสามารถถูกจับได้ตั้งแต่ต้นทาง ลดโอกาสที่โค้ดมีปัญหาจะหลุดเข้า repository หรือส่งผลต่อเพื่อนร่วมทีม

Git hooks ที่นิยมใช้ในโปรเจกต์จริง

ในงานพัฒนาซอฟต์แวร์จริง มี hooks หลักที่นิยมใช้อยู่ 3 ตัว ได้แก่

1. pre-commit

รันก่อนการ commit เพื่อเช็กคุณภาพพื้นฐานของโค้ด เช่น format, lint หรือ type check เฉพาะส่วนที่เกี่ยวข้อง

2. commit-msg

ใช้ตรวจรูปแบบข้อความ commit ให้เป็นมาตรฐานเดียวกันทั้งทีม เช่น

  • feat: ...
  • fix: ...
  • docs: ...
  • refactor: ...

การมีรูปแบบ commit ที่ชัดเจนช่วยให้ค้นประวัติย้อนหลังได้ง่ายขึ้น สร้าง changelog ได้สะดวกขึ้น และทำให้การรีวิว PR อ่านเข้าใจได้เร็วขึ้น

3. pre-push

รันก่อน push เพื่อป้องกันโค้ดที่ยังไม่พร้อมถูกส่งขึ้น remote โดยมักใช้สำหรับรัน test ชุดสำคัญที่จำเป็น

แนวทางตั้งค่าที่เหมาะกับทีมส่วนใหญ่

สำหรับโปรเจกต์ Node.js, Frontend หรือ Fullstack ที่มี package.json การเริ่มต้นใช้งาน Husky ทำได้ค่อนข้างเร็ว โดยติดตั้ง Husky เปิดใช้งาน hooks และสร้าง hook ตามความต้องการของทีม

ตัวอย่างการตั้งค่าที่มักได้ผลดีในทีมจริง ได้แก่

  • pre-commit: รัน prettier และ eslint เฉพาะไฟล์ที่แก้ไข
  • commit-msg: บังคับรูปแบบข้อความ commit ให้เหมือนกันทั้งทีม
  • pre-push: รัน test ชุดสำคัญก่อนส่งโค้ดขึ้น remote

อีกหนึ่งเครื่องมือที่นิยมใช้คู่กับ Husky คือ lint-staged ซึ่งช่วยเลือกเฉพาะไฟล์ที่ถูก stage ไป lint หรือ format ทำให้การทำงานเร็วขึ้นและไม่กระทบประสบการณ์ของนักพัฒนามากเกินไป

ทำอย่างไรไม่ให้ hook ช้าเกินไปจนคนอยากปิด

ข้อผิดพลาดที่พบได้บ่อยคือการใส่ทุกอย่างไว้ใน pre-commit โดยเฉพาะการรัน test ทั้งระบบ ซึ่งมักทำให้ขั้นตอน commit ช้ามากจนคนในทีมเริ่มหาวิธี bypass หรือปิด hook ไปในที่สุด

แนวทางที่ดีกว่าคือแบ่งหน้าที่ให้เหมาะสม เช่น

  • pre-commit: ทำงานที่ต้องเร็ว เช่น prettier, eslint, typecheck เฉพาะส่วน
  • pre-push: รัน test ชุดสำคัญที่ใช้เวลามากขึ้น
  • CI: รัน test แบบเต็มชุดอีกชั้นหนึ่งบนเซิร์ฟเวอร์

แนวคิดนี้ช่วยให้ทั้งความเร็วและคุณภาพเดินไปด้วยกันได้ โดยไม่สร้างภาระเกินจำเป็นให้ทีม

ข้อควรระวังที่ทำให้ Husky เหมือนทำงาน แต่จริงๆ ไม่ทำ

แม้จะตั้งค่าไว้แล้ว แต่หลายทีมยังเจอปัญหาที่ hooks ไม่ทำงานจริง สาเหตุที่พบบ่อยมีดังนี้

  • ลืมติดตั้ง dependencies ที่เกี่ยวข้อง
  • ลืมรันคำสั่งติดตั้ง Husky หลัง clone repository
  • ไฟล์ hook ไม่มีสิทธิ์ execute

วิธีลดปัญหาคือเพิ่ม script ใน package.json ให้รันอัตโนมัติหลัง npm install และเขียน README แบบสั้น กระชับ ให้สมาชิกใหม่ในทีมทำตามได้ทันที

ใช้ Husky กับโปรเจกต์หลายภาษาได้หรือไม่

แม้ Husky จะนิยมในโลก Node.js แต่ก็ไม่ได้จำกัดแค่ JavaScript หรือ TypeScript เท่านั้น หากทีมมีหลายภาษา เช่น Node + Python + Go ก็ยังสามารถใช้ Husky ได้เช่นกัน โดยให้ hook เรียกคำสั่งที่เหมาะกับแต่ละส่วนของระบบ เช่น pytest, go test หรือ make test

สิ่งสำคัญคือการออกแบบ hook ให้เหมาะกับโครงสร้างโปรเจกต์ และไม่ทำให้ขั้นตอนทำงานของทีมหนักเกินไป

Husky และ CI ต้องมีทั้งคู่

อีกมุมหนึ่งที่หลายคนมักลืมคือ Husky ไม่ได้มาแทน CI แต่ทำหน้าที่คนละจุด

  • Husky คือประตูหน้าที่ช่วยสกัดปัญหาตั้งแต่บนเครื่องนักพัฒนา
  • CI คือประตูหลังที่ช่วยตรวจซ้ำอย่างเป็นระบบก่อน deploy

เมื่อมีทั้งสองชั้นร่วมกัน โอกาสที่โค้ดมีปัญหาจะหลุดรอดไปสู่ production จะลดลงอย่างมาก

แนวทางเริ่มต้นสำหรับทีมที่อยากใช้วันนี้

ถ้าทีมต้องการเริ่มใช้งานแบบค่อยเป็นค่อยไป ลำดับที่แนะนำคือ

  1. เริ่มจาก pre-commit ด้วย prettier และ eslint เพราะเห็นผลเร็วและไม่หนักเกินไป
  2. เพิ่ม commit-msg เพื่อให้รูปแบบข้อความ commit เป็นมาตรฐานเดียวกัน
  3. ค่อยเพิ่ม pre-push สำหรับรัน test ชุดสำคัญ

ลำดับนี้ช่วยให้ทีมเห็นประโยชน์ตั้งแต่ช่วงแรก และปรับตัวได้ง่ายโดยไม่รู้สึกว่ากระบวนการพัฒนาถูกทำให้ยุ่งยากขึ้น

สรุป

Husky คือเครื่องมือที่ช่วยบังคับวินัยของทีมแบบอัตโนมัติ โดยไม่ต้องพึ่งการเตือนซ้ำๆ จากคนในทีม มันช่วยกันความผิดพลาดเล็กๆ ที่อาจลุกลามไปเป็นปัญหาใหญ่ในโปรดักชันได้อย่างมีประสิทธิภาพ

เมื่อใช้ร่วมกับ Git hooks, lint-staged และ CI อย่างเหมาะสม ทีมจะสามารถโฟกัสกับการพัฒนาคุณภาพของซอฟต์แวร์ได้มากขึ้น แทนที่จะต้องเสียเวลาแก้ปัญหาเดิมซ้ำๆ จากขั้นตอนพื้นฐานที่ควรถูกตรวจจับได้ตั้งแต่แรก