Hãy đánh giá ngắn.
Thật khó để tập trung, đặc biệt là trong quá trình xem xét mã, trong một thời gian dài. Hơn nữa, các đánh giá mã dài có thể chỉ ra rằng có quá nhiều điều để nói về mã (xem hai điểm tiếp theo) hoặc đánh giá trở thành một cuộc thảo luận về các vấn đề lớn hơn, chẳng hạn như kiến trúc.
Ngoài ra, một đánh giá nên vẫn là một đánh giá, không phải là một cuộc thảo luận. Điều đó không có nghĩa là tác giả của mã không thể trả lời, nhưng nó không nên biến thành một cuộc trao đổi ý kiến dài.
Tránh xem lại mã quá tệ.
Việc xem xét mã chất lượng thấp đang gây áp lực cho cả người đánh giá và tác giả của mã. Nếu một đoạn mã là khủng khiếp, đánh giá mã không hữu ích. Thay vào đó, tác giả nên được yêu cầu viết lại mã chính xác.
Sử dụng kiểm tra tự động trước khi xem xét.
Kiểm tra tự động tránh lãng phí thời gian quý báu chỉ ra những sai lầm có thể được tìm thấy tự động. Ví dụ: đối với mã C #, chạy StyleCop, số liệu mã và đặc biệt là phân tích mã là cơ hội tốt để tìm một số lỗi trước khi xem xét. Sau đó, đánh giá mã có thể được dành cho các điểm cực kỳ khó thực hiện cho máy.
Chọn cẩn thận những người làm đánh giá.
Hai người không thể chịu đựng nhau sẽ không đánh giá tốt một trong những mã của người khác. Vấn đề tương tự phát sinh khi một người không tôn trọng người khác (nhân tiện, dù đó là người đánh giá hay tác giả).
Ngoài ra, một số người không thể xem mã của họ được xem xét, vì vậy họ yêu cầu đào tạo và chuẩn bị cụ thể để hiểu rằng họ không bị chỉ trích và họ không nên xem đó là điều gì đó tiêu cực. Thực hiện đánh giá, không chuẩn bị, sẽ không giúp ích gì, vì họ sẽ luôn phòng thủ và sẽ không lắng nghe bất kỳ lời phê bình nào về mã của họ (lấy mọi lời đề nghị làm chỉ trích).
Làm cả hai đánh giá không chính thức và chính thức.
Có một danh sách kiểm tra giúp tập trung vào một bộ lỗ hổng chính xác, tránh để chuyển sang chọn nit. Danh sách kiểm tra này có thể chứa các điểm như:
- SQL tiêm,
- Giả định sai về một ngôn ngữ có thể dẫn đến lỗi,
- Các tình huống cụ thể có thể dẫn đến lỗi, chẳng hạn như quyền ưu tiên của nhà điều hành. Ví dụ, trong C #,
var a = b ?? 0 + c ?? 0;có thể trông ổn đối với người muốn thêm hai số không có giá trị với số kết hợp bằng 0, nhưng không phải vậy.
- Phân bổ bộ nhớ,
- Tải lười biếng (với hai rủi ro của nó: tải cùng một thứ nhiều hơn một lần và hoàn toàn không tải nó),
- Tràn,
- Cấu trúc dữ liệu (với các lỗi như danh sách đơn giản thay vì bộ băm chẳng hạn),
- Xác nhận đầu vào và lập trình phòng thủ nói chung,
- An toàn chủ đề,
- Vân vân.
Tôi dừng danh sách ở đây, nhưng có hàng trăm điểm có thể nằm trong danh sách kiểm tra, tùy thuộc vào điểm yếu của một tác giả chính xác.
Điều chỉnh dần danh sách kiểm tra.
Để duy trì tính xây dựng và hữu ích theo thời gian, danh sách kiểm tra được sử dụng trong các đánh giá chính thức nên được điều chỉnh theo thời gian tùy thuộc vào các lỗi được tìm thấy. Ví dụ: các đánh giá không chính thức đầu tiên có thể tiết lộ một số rủi ro nhất định của SQL Injection. Kiểm tra SQL tiêm sẽ được bao gồm trong danh sách kiểm tra. Khi, một vài tháng sau, có vẻ như tác giả hiện đang rất cẩn thận về các truy vấn động so với tham số, SQL Injection có thể bị xóa khỏi danh sách kiểm tra.