Các việc cần làm để review code hiệu quả

Mình đọc bài viết này khá thú vị về review code nên dịch lại chia sẻ cho anh em. Bài viết gốc tại đây: https://willowtreeapps.com/ideas/best-practices-for-effective-code-reviews

Tại WillowTree, chúng tôi thường được hỏi về cách chúng tôi thực hiện việc review code và cách feedback về process khi phát triển phần mềm. Hôm nay, tôi muốn chia sẻ quy trình của chúng tôi và một số thực tiễn tốt nhất mà chúng tôi áp dụng khi tiến hành review code.

Quy trình review code bắt đầu bằng cách chúng ta cấu trúc công việc của chúng ta. Nói chung, chúng ta làm theo git flow model của branching và hoàn thành công việc. Bạn có thể đọc thêm về git flow ở đây (http://nvie.com/posts/a-successful-git-branching-model/), git flow yêu cầu mỗi nhà phát triển làm việc trong branch riêng của họ xuất phát từ một branch phát triển chung. Một khi một developer thực hiện với một feature hoặc fix bug, họ có thể merge code đó trở lại development, branch. Chính thời điểm này chúng tôi đã thực hiện code reviews.

Khi một developer hoàn thành công việc của họ trên một feature branch, họ push nó lên git repository. Sau khi được push, developer sẽ tạo pull request và assign nó cho một developer khác review. Reviewer tiến hành comment trên code được review và đẩy lại cho developer thực hiện bất kỳ sửa đổi cần thiết, sau đó pull request sẽ được merge vào branch chính. Như bạn thấy, process này là tối thiểu. Để duy trì nó, chúng tôi thực hiện theo một số thực hành đơn giản và giảm thiểu rủi ro nhất như dưới đây.

Có vẻ như là một điều rất đỗi bình thường, nhưng một trong những bước quan trọng đầu tiên để review code quả là thảo luận cách tính năng này phải được xây dựng cùng với development team của bạn. Lý tưởng là, điều này được thực hiện trước khi viết một dòng code. Đó là một bước đặc biệt quan trọng nếu bạn là người mới tiếp xúc với code base hoặc còn non kinh nghiệm. Nhận phản hồi từ các senior developers hoặc từ các developers đã làm việc với code base trước đây - họ có thể có cái nhìn sâu sắc về cách tính năng nên được tích hợp. Điều này cũng làm giảm rủi ro review code khi bạn dành thời gian viết function cho một tính năng đã có sẵn trong code base hoặc bạn tiếp cận với hệ thống bằng một cách khác.

Review code tốt nhất là review một lượng code nhỏ. Nó chỉ ra rằng hầu hết các bài review có phản hồi xây dựng nhất khi chúng dưới 400 dòng code (http://nvie.com/posts/a-successful-git-branching-model/). Sau khoảng 400 dòng sự phức tạp trở nên quá khó để giữ trong đầu của bạn và hầu hết các reviewer sẽ lướt qua các chi tiết khi reviews tăng lên về kích thước.

Các tính năng lớn thì sao? - làm thế nào bạn nên xử lý những cái này? Có một cách là bạn giữ tính năng chính trên một bracnh và tạo pull request, các tính năng phụ trên các branches khác. Một khi feature và các PRs đã hoàn thành, đơn giản là merge tất cả các branch vào branch chính đang phát triển. Một tùy chọn khác là thực hiện các phần nhỏ của tính năng nhưng thêm một flag giữ cho tính năng đó bị vô hiệu hóa cho đến khi nó hoàn tất.

Ngoài việc giữ lượng code review nhỏ, điều quan trọng là giữ cho chúng tập trung. Hãy thử giữ các pull requests giới hạn trong một mục duy nhất của công việc. Không sửa format kèm theo code fixes, hoặc thêm các dependencies khi fix bugs. Điều này làm cho reviewer tập trung hơn vào những thay đổi chức năng quan trọng mà bạn đã thực hiện trong code của mình. Nếu dependencies hoặc format khác là cần thiết, hãy tạo pull request khác và review riêng. Bạn cũng có thể comment về những gì bạn đã làm để reviewer dễ dàng và nhanh chóng review hơn nếu tất cả những gì bạn đang làm là thêm app assets hay third-party dependencies. Cũng nên để ý đến chính PR của bạn trước tiên để loại bỏ những code debug, các dấu xuống dòng thừa thãi, hay vấn đề về format trước khi đưa nó chó reviewer.

Khi review, điều quan trọng là phải đưa ra comment hữu ích. Thay vì comment "cái này sai", hãy cố gắng xây dựng các comment cung cấp các giải pháp có thể. Ví dụ: "Tôi không chắc chắn điều này là chính xác, nếu bạn thử X?" Đề cập đến các giải pháp mới để giải quyết vấn đề cũng có thể hữu ích vô cùng. Một số review tốt nhất mà tôi tham gia liên quan đến những người đánh giá đã dành thời gian để chỉ cho tôi các code khác mà tôi có thể sử dụng để giải quyết vấn đề tôi đang làm hoặc các bài viết có thể giúp tôi tìm hiểu thêm.

Cuối cùng, điều quan trọng cần nhớ là bạn không phải là code của bạn. Reviews có thể gây khó khăn với các developer khác chỉ ra những điều không chính xác hoặc có thể cần cải thiện, nhưng với thái độ đúng, bạn có thể nhận được review rất xây dựng. Reviewers cũng nên nhớ để giữ giọng nói chuyên nghiệp trong các reviews và nói chuyện với các vấn đề với code chứ không nói về developer đã viết code. Cuối cùng, nếu bạn khó khăn trong việc đồng ý thay đổi code, không có cách nào tốt hơn để giải quyết xung đột là reviewer và developer ngồi xuống mặt đối mặt nói chuyện về nó.

Tôi hy vọng bài viết này hữu ích cho việc review code của bạn. Tôi nhận thấy rằng code reviews là vô cùng quan trọng và là một phần quan trọng trong quá trình phát triển.