Đánh giá mã tiêu chuẩn chứa gì?

Trong công ty của tôi, đó là một cuộc thảo luận qua email về tính năng nào được triển khai và loại lỗi nào được sửa bởi người viết mã. Và người đánh giá, người nhận thư, sẽ xem xét mã và thảo luận về chất lượng cũng như cách chỉnh sửa mã theo ý kiến ​​của mình. Đánh giá mã tiêu chuẩn chứa gì?

Theo kinh nghiệm của tôi, hầu hết các đánh giá mã chính thức đều chuyển sang kiểm tra kiểu vì nó dễ. Ngay cả khi bạn cung cấp một danh sách kiểm tra những thứ cần xem xét, thật dễ dàng để mắt bắt đầu sáng lên.

Tôi đã thấy rằng đánh giá thử nghiệm đơn vị cung cấp nhiều lợi ích hơn. Hầu hết các nhà phát triển mà tôi đã làm việc không thực sự biết cách kiểm tra đơn vị đúng cách và một khi họ nhận được "Aha!" Khoảnh khắc phần còn lại của mã của họ cũng bắt đầu cải thiện. Đây là một gợi ý: đây không phải là thử nghiệm đơn vị nếu bạn yêu cầu người dùng kiểm tra thứ gì đó và đó không phải là thử nghiệm đơn vị nếu bạn chỉ bắt đầu một thứ gì đó để chạy trong trình gỡ lỗi.

Nó có xu hướng thay đổi dựa trên những gì vấn đề là. Rất nhiều lần nó là một con dấu cao su đơn giản. "Đây là vấn đề là gì, hãy nhìn vào dòng này ở đây, rõ ràng có gì không ổn và đây là nơi tôi đã sửa nó." "Yup, điều đó khá rõ ràng. Hãy tiếp tục và kiểm tra nó."

Nhưng khi một cái gì đó liên quan nhiều hơn đang diễn ra, nó thường diễn ra như sau:

• Chạy Kiểm tra sửa đổi trên TortoiseSVN và nhận danh sách các tệp đã thay đổi.
• Đưa người đánh giá vào văn phòng của bạn.
• Giải thích vấn đề, với CR từ hệ thống theo dõi lỗi mở để tham khảo.
• Đi xuống danh sách các tệp trong TortoiseSVN, mở từng tệp trong BeyondCompare để xem các thay đổi.
• Nếu người đánh giá không hiểu các thay đổi, hãy giải thích những gì bạn đã làm và tại sao.
• Người đánh giá có thể nhận thấy một cái gì đó không đẹp. Nếu vậy, hãy thảo luận về nó cho đến khi bạn đạt được thỏa thuận về việc có nên thay đổi hay không. (Nếu cần thực hiện các thay đổi đơn giản, bạn thậm chí có thể chỉnh sửa tệp bên trong BeyondCompare.)
• Nếu bạn đã thực hiện bất kỳ thay đổi, biên dịch lại và đảm bảo rằng nó được xây dựng!
• Chạy chương trình để chứng minh cho người đánh giá rằng bản sửa lỗi của bạn thực sự hoạt động.
• Kiểm tra nó trong.

IMO, Đánh giá mã không liên quan gì đến các tính năng hoặc lỗi, nhưng tập trung vào chất lượng của mã và các bài kiểm tra được viết cho nó.

Vì vậy, bạn ngồi bên cạnh đồng nghiệp của mình và yêu cầu anh ta giải thích mã, hoặc lấy mã và đi qua nó, bất kể tình huống nào được yêu cầu.

Nó có ích khi mọi chương trình chống lại các tiêu chuẩn giống nhau và nếu bạn sử dụng các công cụ như fxCop để tự động hóa một phần của quy trình.

Tôi thích xem lại mã nơi nhà phát triển ngồi với người đánh giá và đi qua dòng mã theo từng dòng giải thích nó. Thông thường, nhà phát triển sẽ thấy một vấn đề trong việc giải thích rằng người đánh giá có thể chưa thấy, đó là lý do tại sao đây là sở thích của tôi. Tôi cũng thực hiện đánh giá mã nơi tôi đã gửi mã và tự mình đọc mã và nhận xét, nhưng tôi thấy những điều đó có xu hướng mất nhiều thời gian hơn (tôi xem xét và soạn thảo nhận xét và gửi cho nhà phát triển đọc chúng và gửi WTF. Tôi quay lại và tôi giải thích và hai hoặc ba vòng sau chúng tôi gặp nhau và tôi chỉ ra trên màn hình những gì tôi muốn nói và nhà phát triển nói, "oh yeah bây giờ tôi thấy nó.") và kém hiệu quả hơn vì có ít thảo luận chân thực hơn và hơn nữa, "Bạn đã làm điều này sai."

Nó cũng rất quan trọng để thực thi các tiêu chuẩn trong đánh giá mã nhưng không làm cho chúng trở thành trọng tâm duy nhất.

Tuy nhiên, mã không được gửi đến sản xuất cho đến khi người đánh giá mã hài lòng hoặc người quản lý (không phải nhà phát triển) đã ghi đè anh ta hoặc cô ta (người đánh giá mã cũng đã sai). Điều này rất quan trọng hoặc đánh giá mã chỉ là một quá trình quan liêu không có giá trị gia tăng trừ khi người xem xét mã phải phê duyệt mã cuối cùng trước khi nó được đẩy.

Đầu tiên bạn cần phải có các tiêu chuẩn mã hóa và đây không chỉ là cú pháp. Khi mọi người bắt đầu trong công ty của bạn, họ phải tìm hiểu các hướng dẫn của công ty bạn càng nhiều càng tốt trước khi họ bắt đầu viết mã . Nếu trong quá trình xem xét, tất cả các loại vi phạm được tìm thấy, rất có thể chúng sẽ:

• không được sửa chữa do hạn chế về thời gian
• thấy khó chịu hơn những gì hướng dẫn có giá trị

Các hướng dẫn nên có ý nghĩa và cần có công cụ thích hợp để tìm ra các vi phạm và tái cấu trúc dễ dàng nhất có thể. Luôn luôn nhìn vào mục tiêu của các hướng dẫn và đánh giá mã

Mục tiêu trong tâm trí của tôi là làm cho mã thống nhất nhất có thể và tìm ra các vấn đề với khả năng bảo trì và dễ đọc. Mục tiêu thứ yếu có thể là giúp nhiều người tăng tốc với một phần mềm nhất định.

Các hướng dẫn trong tâm trí của tôi ví dụ có thể tồn tại:

• cú pháp chung và hướng dẫn mã hóa (chọn một hướng dẫn đã tồn tại và sử dụng công cụ kiểm tra tự động)
• Xử lý ngoại lệ thích hợp
• Đăng nhập đúng cách
• Sử dụng tốt các mô hình cho ngôn ngữ (RẮN cho các ngôn ngữ OO)
• Rõ ràng và nghĩ ra sự phụ thuộc giữa các thành phần (sử dụng các công cụ như NDepend)
• Kịch bản xây dựng
• Tài liệu hiện tại (nhà phát triển khởi động, hướng dẫn cài đặt)
• thư viện nội bộ để sử dụng
• chính sách công ty
• công cụ của bên thứ ba không được phép
• Kiểm tra đơn vị hiện tại và không thất bại
• mã bảo hiểm 90%
• ...

Cùng với đó, phần đánh giá mã bao gồm phần mềm được kiểm tra theo hướng dẫn và:

• thảo luận về vi phạm với lập trình viên
• sửa chữa những vi phạm không cần thiết
• bình luận vi phạm cần thiết