9 Ý tưởng giúp bạn review code hiệu quả hơn

Tiếp theo "Những nguyên lý cơ bản của review code", bài viết này sẽ trình bày 9 ý tưởng giúp các bạn review code nhẹ nhàng và hiệu quả hơn.

#1 Viết code sạch bằng mọi giá

Code sạch mang lại vô số lợi ích như: dễ đọc, dễ bảo trì, thể hiện "đẳng cấp" của lập trình viên..... Tóm lại, ngoài yếu tố con người và phương pháp quản lý thì code sạch là một nền tảng vững chắc cho sự thành công của bất kỳ dự án nào.

Với quá trình review code, hãy thể hiện sự tôn trọng với đồng nghiệp của bạn và giúp họ tiết kiệm thời gian bằng cách viết những dòng code sạch ngay từ bây giờ.

#2 Code đi đôi với test

Có thể bạn không phải là fan của TDD - Test Driven Development. Không sao, tôi không nhắc đến TDD ở đây, tôi chỉ mong các bạn hãy test code của mình trước khi submit lên để review. Việc này kéo theo 2 lợi ích nho nhỏ:

• Bạn không submit những dòng code lỗi
• Giúp đồng nghiệp hiểu code của bạn dễ dàng hơn

#3 Luôn duy trì sự nhất quán khi lập trình

Các phương pháp duy trì sự nhất quán khi lập trình đã được tác giả trình bày tại đây.

Dù bạn vô tình hay cố ý bỏ quên việc chỉnh sửa code cho nhất quán với quy chuẩn (của team), bạn cũng sẽ bị nhắc nhở bởi người trực tiếp review code cho bạn. Chung quy lại, việc này giúp reviewer hiểu những dòng code đó nhanh hơn, từ đó tiết kiệm thời gian review.

#4 Trước khi submit, hãy giải quyết các vấn đề tồn đọng mà bạn có thể nhận ra

Sẽ có lúc bạn viết ra những dòng code "thúi" (sai logic, vi phạm design pattern...) nhưng bạn cố tình "lờ đi" vì ... lười.

Đừng làm như vậy, hãy là một lập trình viên tử tế.

Bạn biết đấy, khi người review bị phân tâm bởi những lối ngớ ngẩn đó, anh ta khó có đủ thời gian để chỉ ra cho bạn những lỗi mà bạn "không nhìn thấy". Và điều này vừa không tốt cho tương lai của bạn, vừa không tốt cho tương lai của dự án.

#5 Viết commit message đầy đủ một cách ngắn gọn

Đây là một ví dụ ngắn về 6 lần viết commit message của anh bạn tôi (theo trình tự thời gian):

1. Add user login feature
2. Code review
3. Code review fixes
4. Quick fix
5. Rename variable
6. Review fixes etc.

Bạn thấy đấy, anh ta chỉ tập trung mô tả đầy đủ ở lần commit đầu tiên. Càng về sau, những commit message càng trở nên tối nghĩa và không cụ thể.

Có 2 hướng khắc phục việc này:

• Khoanh vùng các thay đổi sau mỗi lần code review và sử dụng một commit message mô tả đầy đủ nhất có thể cho mỗi nhóm.
• Commit khi quá trình review hoàn tất và branch sẵn sàng để merge

#6 Giới hạn lượng code mang đi review

Tôi đã từng "phải" review một pull request chứa 50 class. Và dưới góc nhìn của các reviewer như tôi, đó thực sự là một thảm họa.

Dưới góc nhìn khách quan thì việc 1 lập trình viên submit quá nhiều code trong 1 lẩn review sẽ mang đến 2 tác hại chính:

• Giảm sự tập trung và gây tâm lý tiêu cực cho reviewer, kéo theo hiệu quả review đi xuống
• Đi ngược lại nguyên lý của Continous Integration

#7 Không tự ti khi code dính review tiêu cực

Khi bạn đã cố gắng hết mình nhưng kết quả review không như mong đợi... Bạn nên vui mừng vì điều đỏ.

Việc nhận được chỉ trích từ phía đồng nghiệp sau mỗi phiên code review chính là một động lực lớn để bạn tự hoàn thiện kỹ năng của mình. Bạn biết đấy, người ngoài không khen ngợi những ưu điểm của bạn thì bạn vẫn có thể phát huy chúng được. Tuy nhiên với nhược điểm thì ngược lại, nếu bạn chưa bao giờ bị chỉ trích vì nhược điểm của mình thì bạn sẽ không hình thành được ý thức và quyết tâm để sửa đổi chúng.

Hãy cảm ơn những đồng nghiệp đã và đang chỉ trích mình, vì họ chỉ muốn bạn tốt lên mà thôi

#8 Đừng mong chờ những giải pháp "mỳ ăn liền"

Điều này sẽ làm bạn lười tư duy, lâu dần sinh tâm lý ỉ lại vào code review. Nó vừa giết chết kỹ năng của bạn, vừa gây khó chịu cho đồng đội.

Hãy đứng vững trên đôi chân của mình.

#9 Xử lý các vấn đề khó bằng offline meeting

Khi xảy ra tình huống tranh cãi lâu dài, hãy ngồi lại với nhau thay vì đưa ra giải pháp bằng comment hoặc message. Trình bày ý tưởng của bạn với bảng trắng và bút đen là một lựa chọn không thể tốt hơn!

Techmaster via TidyJava