số lượng mã trong đánh giá mã

Theo kinh nghiệm của tôi, hầu hết các đội trong công ty xem xét mã của thành viên nhóm với một lượng mã nhỏ, luôn luôn ít hơn hàng trăm dòng. Có phù hợp để xem xét số lượng lớn mã, ví dụ như một mô-đun, khi mã hoàn tất và sẵn sàng để được xem xét một lần cho tất cả?

Lý do cho các đánh giá mã nhỏ là để tối đa hóa hiệu quả.

Các nghiên cứu liên quan đến Quy trình phần mềm cá nhân đã phát hiện ra rằng các nhà đánh giá có hiệu quả nhất, liên quan đến việc tối đa hóa các khiếm khuyết được xác định trong đánh giá, khi họ xem xét không quá 150-200 dòng mã nguồn mỗi giờ. Với dữ liệu thực nghiệm đó, nó trở thành vấn đề xác định thời gian mọi người có thể chú ý trong bao lâu. Tôi không có bất kỳ dữ liệu thực nghiệm nào, nhưng tôi biết tâm trí tôi bắt đầu lang thang sau khoảng 1 giờ đọc một cái gì đó. Đối với tôi, điều đó chỉ ra rằng các đánh giá mã nên xem lại ít hơn 150 dòng mã mỗi lần.

Nó phù hợp nếu nó giúp nhóm của bạn tạo ra một sản phẩm tốt hơn.

Một số lý do mà các đánh giá mã thường tập trung vào các phần nhỏ hơn:

• Việc xem xét đúng một lượng lớn mã yêu cầu mỗi người tham gia phải dành khá nhiều thời gian để chuẩn bị và điều đó có thể tốn kém.

• Cuộc họp đánh giá càng kéo dài (bất kỳ cuộc họp nào, thực sự), càng ít người chú ý. Hai giờ là gần như hầu hết mọi người có thể đứng, và giữ cho các cuộc họp ngắn hơn thế (ví dụ, một giờ hoặc 90 phút ngọn) đi một chặng đường dài để đảm bảo rằng mọi người đều ở trạng thái tốt nhất.

• Nó thường không cần thiết để xem xét mọi dòng. Một lý do để xem xét mã là để đảm bảo rằng tất cả mọi người đều tuân theo cơ bản cùng một bộ hướng dẫn mã hóa. Đánh giá chi tiết về số lượng mã nhỏ hơn hoạt động tốt hơn cho mục đích đó so với đánh giá ít chi tiết hơn về mã.

Điều đó nói rằng, nếu bạn thấy rằng việc xem xét thêm mã là hữu ích và nếu nhóm của bạn có thể chịu đựng được thì bằng mọi cách hãy thử xem. Nó sẽ giúp đảm bảo rằng có một số quy tắc cơ bản và ai đó đóng vai trò là người điều phối để duy trì cuộc họp. Ngoài ra, hãy cân nhắc việc người đánh giá gửi nhận xét của họ trước để bạn dành ít thời gian hơn cho những thứ khó chịu như sử dụng không gian trắng không đúng cách và có nhiều thời gian hơn để thảo luận về các vấn đề quan trọng và thú vị.

Nếu bạn xem xét một lượng lớn mã sau khi nó đã hoàn thành (và có lẽ là chức năng), thì điều này sẽ biến nhiều hơn thành một phiên "chúng ta nên làm ..." hơn là "hãy sửa / thay đổi điều này để làm ..."

Vì vậy, nếu mục đích chính của hoạt động là một bài tập học tập sau khi chết, thì việc xem xét mã lớn có ý nghĩa. Nếu nó cố gắng bắt lỗi, có lẽ nó sẽ không hoạt động tốt. Các khiếm khuyết nhỏ có thể bị bỏ qua vì mọi người trong bài đánh giá đều cảm thấy buồn chán và mệt mỏi, và các khiếm khuyết lớn về cấu trúc có thể bị bỏ qua vì, "quá muộn rồi - mã đã được viết và khách hàng muốn nó vào ngày hôm qua."