Hãy commit code có tâm như Senior Developer

Hãy commit code có tâm như Senior Developer

Tổng quan

30-06-2021

NỘI DUNG BÀI VIẾT

Nay định bụng viết một bài “cao siêu sâu xa về git commit rebase”. Nhưng ngồi lướt face book lại thấy cái bài post hay quá. Nên lại viết về kinh nghiệm thực tế khi làm việc. Viết message commit như thế nào cho tốt?.

Thiết nghĩ theo cái nghề cũng là cái duyên cái nghiệp, không phải ai cũng ngồi trước máy tính làm việc 10-12 tiếng mà vẫn vui vẻ được. Cái nghề nó chọn mình, đeo bám lấy mình. Nhưng cứ “vững chí bền gan” – rèn luyện trau dồi thì nghề không phụ mình đâu!.

Lạc cmn đề, quay lại chủ đề chính “viết commit message sao cho tốt?“

1. Liên quan gì tới Senior?

Liên quan chứ, trở thành Senior không chỉ là “nắm rõ design pattern, hiểu tường tận về architecture“. Ngoài ra còn kĩ càng, chỉn chu trong những công việc nhỏ như viết nội dung commit, refactor các function nhỏ, hay viết manual document.

Chắc hẳn ai cũng biết những dòng lệnh commit sau:

git add .
git commit -m "added new feature"
git push

Đây, vài ba dòng đơn giản, nhưng là nỗi ám ảnh không của riêng ai, nội dung có chứ không phải không. Nhưng có cũng như không có. Tại sao mình nói vậy?

New feature là b**p gì?.
Nếu là application thì nó implement FE hay BE?. Nếu ông kia Fullstack thì ổng đang làm khúc nào?
Vẫn phải liếc qua xem của người nào commit. Mở tab change (gitlab) xem change cái gì.

git add .
git commit -m "fix bug"
git push

git add .
git commit -m "hot fix bug blur"
git push

Một vài ví dụ. Blur là blur cái gì?, hot fix là fix khi nào?. Trước thì còn nóng sốt kịp release, nhưng giờ quay lại thì đâu thấy “gấp gáp” gì nữa. Vậy nội dung fix là gì?

2. Ủa chứ tưởng commit sao thì commit

Xin thưa là không phải nha, không phải code hoành tá tràng, giải thuật cao siêu hay component siêu to bự là muốn commit sao thì commit nha.

Vấn đề là feature này làm trong 2 tuần thì release, nên có viết content “ngáo ngơ” xíu thì cũng ok, nhìn vẫn nhớ. Còn nếu sau 2 tháng quay lại nhìn vào git history?.

Ơn chúa, “chỉ có chúa và con biết nội dung của nó là gì?. Mà đó còn là nội dung của bạn viết, chứ ông dev nào khác mà nhìn vào thì ôi thôi. Xác định là khỏi tra theo commit để mà tìm bug.

Ngoài ra, viết commit tốt còn giúp cho:

To speed up the reviewing process. (Tăng tốc quá trình review)
To help us write a good release note. (Viết release note tốt)
To help the future maintainers of Erlang/OTP (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added. (Tìm lại những gì đã làm năm xưa một cách dễ dàng)

Để tránh những trường hợp đó. Ngoài có chuyên môn giỏi, khả năng code “thần sầu quỷ khóc”, cũng cần có tâm khi viết message content. How?, đây, tui chỉ cho

3. Hãy commit code message có tâm

Rõ ràng phải nói là vậy, nhiều khi task dí tới đít, chạy còn không kịp, lấy đâu ra thời gian mà trau với chuốt nội dung commit. Biết là thế, nhưng mình vẫn khuyên là nên bỏ chút thời gian (khoảng 1,2 phút) để viết một nội dung có tâm.

Vậy nội dung có tâm là như thế nào?. Có ngay đây!

git add .
git commit -m "fix bug"
git push

Nội dung commit không nên quá 50 kí tự (Limit the subject line to 50 characters). Đã là nội dung thì nên mô tả ngắn gọn, súc tích nhất có thể. Không nên viết quá dài dòng như tấu chương

Đây chỉ là ví dụ về refactor code, tuy nhiên nếu fix bug hay gì cũng nên theo cấu trúc đó. Cấu trúc chuẩn cho một commit message tốt là:

git add .
git commit -m "[HÀNH ĐỘNG CHUNG] - [NỘI DUNG CHI TIẾT] - [LƯU Ý NẾU CÓ]"
git push

Việc bỏ một chút thời gian để ghi rõ comment, commit message không những giúp rèn luyện tính cẩn thận tỉ mỉ. Từ những việc làm tưởng như nhỏ bé và đơn giản này cho ta cái nhìn khác biệt về hai người lập trình viên.

Chính vì vậy, hãy tập viết nội dung commit thật đàng hoàng ngay từ bây giờ nha. Có bị dí “chạy tụt quần” thì cũng bỏ ra 2 phút để viết được mà.