Bạn xem xét các khối mã mới lớn như thế nào

Question

Tôi là người ủng hộ mạnh mẽ các đánh giá mã, điều đó có nghĩa là gì. Tôi biết nó có nghĩa là những thứ khác nhau cho các cá nhân và nhóm khác nhau và có thể được áp dụng khác nhau trong các giai đoạn phát triển khác nhau.

Khi tôi thực hiện thay đổi một dòng thành #define để sửa lỗi đánh máy trong chuỗi nhắc hiển thị người dùng, "Này, Joe, tôi đã đánh vần 'FooBar' phải không?" dễ. Khi bạn thực hiện một vài thay đổi có liên quan trong một số chức năng liên quan, kiểm tra độ chính xác qua vai là 10-15 phút.

Nhưng còn về dự án mới với hàng chục nghìn dòng thương hiệu đánh dấu mã mới thì sao? Nó không xảy ra thường xuyên vì vậy tôi không thoải mái với nó. Bạn đánh giá như thế nào? One-on-one? Tắt và xem lại "ngoại tuyến" với phản hồi sau này? Trong một thiết lập nhóm?

Đối với các cách tiếp cận khác nhau, có bất kỳ quy tắc chung nào cho các dòng/giờ được đánh giá để tôi có thể ước tính thời gian cho phép không?

Answer 1

Tôi nghĩ rằng bạn nên xem xét mã trước khi nó đạt đến hàng nghìn dòng mã mới. Sau đó nó trở thành vấn đề bạn đang phải đối mặt.

Answer 2

Cá nhân, khi tôi chịu trách nhiệm cho một lập trình viên khác; Tôi xem xét việc kiểm tra mã nguồn theo cách khác nhau gần như hàng ngày nhất có thể

Điều này đang cung cấp mọi thứ đang ở trạng thái hoạt động. Nếu những thay đổi của họ không ở trạng thái hoạt động, tôi sẽ đợi cho đến khi chúng thay đổi.

Nếu họ mất hơn 3 ngày để thay đổi trạng thái hoạt động ... Tôi coi đó là cờ cảnh báo cần được điều tra. Đây thường là một cái gì đó đơn giản như thực hiện quá nhiều thay đổi cùng một lúc hoặc một quá trình tái cấu trúc với quá nhiều tác động.

Answer 3

Nếu mã này khá phức tạp, sau đó tôi muốn xem qua mã này với nhà phát triển ban đầu trực tiếp. Bằng cách đó tôi có thể yêu cầu họ giải thích cách nó hoạt động thay vì dành thời gian cần thiết để tự mình hình dung ra tất cả. Tôi sử dụng một công cụ khác để xem những gì đã thay đổi trong nhiều tập tin và chúng tôi đi qua dòng chảy cùng nhau chú ý đến những thay đổi.

Nếu mã là khá thẳng về phía trước, sau đó tôi thường xem xét nó một mình. Tôi chỉ gọi trong nhà phát triển ban đầu nếu tôi có thắc mắc hoặc quan tâm. Một lần nữa, tôi sử dụng một công cụ khác để xem những gì đã thay đổi và đi qua dòng chảy.

Nếu có hàng tấn mã/thay đổi mới, thì tôi thường chỉ xem lại đường dẫn và kiểm tra điểm quan trọng các phần khác của mã. Trong tình huống này, tôi không cố gắng tìm mọi thứ có thể sai với mã. Giả định của tôi là thử nghiệm sẽ bắt được hầu hết các lỗi. Đánh giá của tôi chủ yếu là để nắm bắt bất kỳ lỗi chính nào, để đảm bảo rằng mã tuân theo các thực hành phần mềm cơ bản tốt và rằng nó sẽ dễ bảo trì.

Answer 4

Lý tưởng nhất là bạn sẽ thực hiện đánh giá mã khi đang được xây dựng, vì vậy bạn có thể cung cấp phản hồi và giảm các vấn đề đáng kể.

Điều đó nói rằng, tôi sẽ sử dụng các công cụ phân tích tĩnh. Điều đó có thể kiểm tra các vấn đề thường xuyên và thậm chí làm phân tích chung về các phụ thuộc trong mã.

Và điều đầu tiên sẽ là: nó có thử nghiệm đơn vị không? Bắt đầu ở đó, kiểm tra chúng được hiểu rõ, nó có thể tiết lộ một số vấn đề khớp nối nhanh chóng.

Nếu mã là cho một hệ thống hiện tại bạn đang làm việc trên như một đội bóng, bạn nên xem xét:

• hội nhập liên tục + cam kết những mảnh nhỏ của sự thay đổi (thay vì làm một lớn cam kết sau vài ngày)
• TDD - tập trung vào nhóm làm các xét nghiệm đơn vị, đặc biệt để tránh khớp nối cao
• Không chỉ thử nghiệm đơn vị mà còn các loại kiểm tra khác chạy theo định kỳ. Đã tách riêng các loại thử nghiệm khác nhau, bạn không muốn kích hoạt thử nghiệm tải trên mỗi bản dựng.
• Có các công cụ phân tích tĩnh chạy với bản dựng
• Phân tích thông tin bản dựng dưới dạng bước đầu tiên, trước khi tiếp tục xem xét mã.

Answer 5

Cách tiếp cận của tôi là phân tích công việc thành các phần nhỏ hơn và xem lại các thay đổi càng sớm càng tốt. Việc xem lại 100-200 dòng mã dễ dàng hơn nhiều so với việc xem lại hàng nghìn và bạn có thể truyền bá bất kỳ thay đổi nào bạn cần thực hiện cho mã tiếp theo.

Answer 6

Tích hợp mã xem xét một cách dễ dàng trong các dự án của bạn:

• giới thiệu một quy tắc bắt buộc để xem xét mã trước khi bất kỳ check-in.
• Để người đánh giá viết nhận xét đăng ký.
• Đặt tên người đánh giá trong séc theo cách chính thức (ví dụ: bằng cách thêm trường nhận xét bắt buộc trong VCS của bạn) hoặc cách thức không chính thức
• Nghĩ giải thưởng cho người quay vòng, ví dụ: một số hệ thống chấm điểm như trên SO :-) (nghiêm túc, nếu không thì sẽ không làm điều đó)

Answer 7

Nếu bạn không thể thực hiện đánh giá gia tăng theo cách mà người khác đã đề xuất, bạn vẫn có thể quản lý đánh giá sau khi thực tế chức năng mới bằng cách chia nó thành các phần có thể quản lý được. Bạn có thể làm điều này trên cơ sở từng lớp, cơ sở từng mô-đun, cơ sở từng tính năng hoặc bất kỳ thứ gì hoạt động tốt nhất cho hệ thống của bạn.

Công cụ như Người cộng tác mã sẽ cho phép bạn thêm các tệp được chọn thủ công vào đánh giá mã, vì vậy bạn có thể chia nhỏ chúng theo cách đó. Thiếu công cụ, bạn cũng có thể chỉ gửi cho người đánh giá nhiều bài đánh giá 'các gói' của các tệp có liên quan.