Thời gian phân bổ để đánh giá mã

Nếu bạn đang làm đánh giá mã

• Bạn dành bao nhiêu thời gian cho các đánh giá mã, so với việc thực hiện?
• Bao nhiêu thay đổi trải qua xem xét mã?
• bạn nghĩ nó sẽ nhiều / nên nhiều hơn?

Có nghiên cứu nào về hiệu quả không?

[sửa] cảm ơn tất cả các bạn về câu trả lời, thật khó để chọn một "người chiến thắng" cho câu hỏi như vậy, cũng có rất nhiều thông tin có giá trị trong các câu trả lời khác.

Tại công việc của tôi, chúng tôi có các thủ tục sau đây để đánh giá mã. Nó đã làm việc tốt cho chúng tôi cho đến nay, và chúng tôi thấy nó rất hiệu quả về thời gian, đặc biệt là về thời gian làm việc. Chúng tôi thực sự không có bất kỳ thời gian cụ thể nào được phân bổ cho các đánh giá. Mỗi cam kết hoặc hợp nhất vào thân cây phải được xem xét và phải mất chừng nào người đánh giá mới chấp nhận được.

Chỉnh sửa: Tất nhiên thời gian cần thiết phụ thuộc vào mức độ thay đổi. Các tính năng nhỏ và sửa lỗi mất vài phút. Các tính năng mới, tái cấu trúc hoặc thay đổi ảnh hưởng đến nhiều phần của hệ thống có thể mất nửa ngày để xem xét và một ngày khác để giải quyết tất cả các vấn đề phát sinh do đó.

Để làm cho hệ thống này hoạt động, điều quan trọng là phải cam kết với thân cây thường xuyên, để các thay đổi có kích thước có thể quản lý được. Bạn không muốn có tình huống khi bạn phải xem lại mã của ai đó trong một năm.

Liên quan đến các nghiên cứu, phần mềm Smart Bear sẽ gửi cho bạn một cuốn sách nhỏ, Bí mật tốt nhất về đánh giá mã ngang hàng , miễn phí. Nó có một số bài viết trong đó về các khía cạnh khác nhau của đánh giá mã, bao gồm các nghiên cứu về thời gian họ nên sử dụng và hiệu quả của chúng.

Trong dự án của chúng tôi, mọi thay đổi quan trọng đối với hệ thống được xem xét bởi trưởng nhóm hoặc cùng với một nhà phát triển khác, người sẽ là "người tiêu dùng" chính của mô-đun mới. Chúng tôi nói chuyện trên skype và sử dụng Rudel trong Emacs (một plugin để chỉnh sửa cộng tác, về cơ bản, nó cho phép một số người dùng chỉnh sửa cùng một tệp trực tiếp) hoặc TypeWith.me (Piratepad) hoặc một trong số chúng tôi chia sẻ màn hình của mình trên skype.

Thật khó để định lượng điều này, bởi vì những thay đổi trần tục, như các chế độ xem, trang mới, v.v. không được xem xét. Chúng tôi xem xét các mô-đun mới, cập nhật lớn và tái cấu trúc. Đối với những thay đổi lớn, việc xem xét mã có thể mất từ ​​10% đến 30% thời gian, nhưng nó đáng giá.

Tôi có thể nói lập trình cặp, khi 2 lập trình viên chỉnh sửa cùng một tệp cùng một lúc, không chỉ ngồi cùng một máy tính, tốt hơn nhiều so với thực hành văn phòng thông thường là ngồi sau vai một người.

Đối với những điều đơn giản như quy ước đặt tên và lỗi phạm vi, chúng tôi sử dụng các công cụ tự động nguồn mở hoặc riêng của chúng tôi (jslint, pylint, pyflakes, pep8). Và chúng tôi không giới hạn các cam kết và thúc đẩy: chúng tôi sử dụng Mercurial có khả năng phân nhánh và hợp nhất rất dễ dàng (tôi phải nói, dễ dàng hơn trong Git). Lỗi không phải là một vấn đề xem xét mã.

Chúng tôi làm các cuộc họp nhóm nơi những thay đổi và những điều mới được công bố, nhưng ở đó, không phải ai cũng thực sự chú ý. Có lẽ chúng ta nên làm thêm một chút đánh giá mã.

Không có câu trả lời đúng hay sai cho vấn đề này. Nhưng như nhiều người trước tôi đã đề xuất - nếu việc xem xét mã được thực hiện bởi một thành viên nhóm bên ngoài [phương pháp được khuyến nghị cao] thì có thể lên tới khoảng 30% đến 35% nỗ lực phát triển. Nhưng nếu điều này được thực hiện bởi một thành viên nhóm dự án nội bộ, một phần của nhóm phát triển [không được đề xuất] thì việc này có thể được hoàn thành trong khoảng 20% thời gian dành cho nỗ lực phát triển.

Lưu ý: Tôi đã xem qua chủ đề này khi tìm kiếm một cái gì đó khác và tôi nghĩ rằng tôi có thể có thể thêm một số giá trị ở đây. Btw, tất cả các ước tính nỗ lực trên này dựa trên kinh nghiệm làm việc của tôi với tư cách là người quản lý tham gia trên nhiều dự án. Hy vọng nó giúp.

Mỗi tổ chức và cơ sở mã là khác nhau, vì vậy rất khó để có được một giá trị rộng của ngành.
Nếu bạn thực sự nghiêm túc thì bạn nên bắt đầu thu thập số liệu. Tức là thực hiện đánh giá mã cho đến khi được thực hiện thỏa đáng bao gồm cả làm lại. Bắt đầu thu thập dữ liệu này trong cơ sở dữ liệu (LỘC, độ phức tạp của mã, ngôn ngữ lập trình, thời gian, v.v.). Sau đó, cũng thu thập số liệu về tỷ lệ lỗi của bạn trong quá trình thử nghiệm. Miễn là bạn có thể giảm đánh giá mã này nên tự trả. Nếu lỗi trở lại từ kiểm tra thì hãy thu thập số liệu về thời gian dành cho việc sửa lỗi. Xây dựng những dữ liệu này trong tổ chức của bạn, tạo đường cơ sở và bạn có thể dự đoán nó khá chính xác. Các thuật ngữ để tìm kiếm học tập thêm là Chi phí chất lượng và Chi phí chất lượng kém.

Nhắc nhở duy nhất là điều này có thể bắt đầu trở nên quan liêu và phụ thuộc vào văn hóa tổ chức.