Đánh giá mã là quá trình ủy quyền một cách có hệ thống một hoặc một số nhà phát triển xem lại mã do nhà phát triển khác viết để phát hiện lỗi và cải thiện nó. Đánh giá mã thường được thực hiện bởi một nhà phát triển có kinh nghiệm xem xét các khía cạnh khác nhau bao gồm chất lượng và tính bảo mật của mã, chia sẻ kiến thức, cho phép cộng tác tốt hơn, xây dựng văn hóa đánh giá, tạo niềm tin cho Nhóm về mã họ đang làm việc
Chi phí đánh giá mã
Ngoài việc xem xét mã, có hai phương pháp nổi tiếng khác để hợp lý hóa quy trình phát triển
- Viết bài kiểm tra để thực hiện thường xuyên và tự động mã được viết và tái cấu trúc
- Sử dụng các công cụ kiểm tra mã để tự động tìm mã và lỗi
Không giống như các công cụ kiểm tra và phân tích, việc xem xét mã do con người thực hiện có thể được coi là một nhiệm vụ khói. Từ khói được sử dụng tương tự với thử nghiệm khói tôi. e đã thực hiện kiểm tra theo cách thủ công để nhanh chóng xác thực một điểm cụ thể. Test như vậy coi như khói vì khi code thay đổi thì phải thực hiện lại, y hệt như code review. Vì lý do đó, việc xem lại mã là một nhiệm vụ tốn kém vì nó tiêu tốn nguồn nhân lực và nó phải được lặp đi lặp lại sau mỗi lần thay đổi mã.
Lợi ích đánh giá mã
Chi phí xem xét mã cao. Mặt khác, lợi ích của việc xem xét mã là có thật
- Giáo dục. Với đánh giá mã, cấp dưới nhận được lời khuyên từ các lập trình viên cấp cao trong bối cảnh mã của chính họ. Không có cách nào tốt hơn để tìm hiểu các phương pháp phù hợp và quảng bá các nguyên tắc và yêu cầu về quy tắc của công ty
- Liên lạc. Với các lập trình viên đánh giá mã nhất thiết phải nói chuyện với nhau và chia sẻ ý kiến. Làm như vậy sẽ thúc đẩy sự đồng hành và cải thiện sự gắn kết của nhóm.
- Kiến thức lan tỏa. Mọi nhóm nên đấu tranh chống lại quyền sở hữu mã i. e khi một người sở hữu cơ sở mã hoặc thành phần. Quyền sở hữu mã đang gây ra xích mích và căng thẳng, cho cả chủ sở hữu và đồng nghiệp của họ. Chủ sở hữu không còn học hỏi từ những người khác và có thể trở nên lười biếng vì công việc của nó không được người khác đánh giá. Mặt khác, những người khác có thể gặp rắc rối lớn khi chủ sở hữu vắng mặt hoặc nếu anh ấy / cô ấy rời đội. Đánh giá mã là cách thực hành tốt nhất để truyền bá kiến thức và ngăn chặn quyền sở hữu mã
- Động lực để tiến bộ. Rõ ràng là nếu bạn ghi nhớ rằng mã của bạn sẽ được một số đồng nghiệp xem xét, bạn sẽ quan tâm nhiều hơn đến nó. Bạn sẽ dành thời gian để đặt tên chính xác cho các định danh, viết bài kiểm tra, giới thiệu các bản tóm tắt phù hợp và sử dụng cẩn thận các mẫu toàn doanh nghiệp
- mã tốt hơn. Bởi vì trí thông minh, kinh nghiệm và sự chú ý của nhà phát triển là cốt lõi của việc xem xét mã, nó có thể giúp phát hiện sớm các lỗi không thể phát hiện được thông qua thử nghiệm và công cụ
Với việc xem xét mã, không chỉ mã kết quả trở nên tốt hơn mà mọi người đều cải thiện với tư cách là nhà phát triển. Những lợi ích liên quan đến con người không thể có được thông qua một thực hành khác. Tuy nhiên, họ có thể tạo ra sự khác biệt giữa một dự án thành công và một dự án thất bại. Do đó, bạn phải nghiêm túc xem xét mã có hệ thống để nhận thấy rằng Lợi tức đầu tư [ROI] của nó là thuận lợi
Cách thực hiện đánh giá mã
Thông báo rằng một số mã đã sẵn sàng để được xem xét
Thường thì việc xem xét mã được tiến hành theo cách không chính thức. Khi một nhà phát triển kết thúc phiên mã hóa, anh ta sẽ thông báo cho một hoặc một số thành viên trong nhóm để xem lại khi họ có thể. Đây là một sự khởi đầu nhưng làm như vậy là không có hệ thống, không thể theo dõi cũng như không đo lường được
Đánh giá qua vai
Không giống như cách thông báo trước đây, đánh giá tổng thể liên quan đến đánh giá đồng bộ. Nó bao gồm việc yêu cầu một hoặc một vài nhà phát triển tham gia để trình bày cho họ công việc đã hoàn thành và thu thập nhận xét. Lý tưởng nhất là họ tham gia trực tiếp nhưng ngày nay, nhiều nhà phát triển làm việc tại nhà và việc đánh giá như vậy có thể được thực hiện từ xa. Đánh giá qua vai chịu cùng một nhược điểm không chính thức của cách thông báo trước đây. Tuy nhiên, nó khuyến khích nhà phát triển tham gia vào một cuộc thảo luận thực sự chứ không chỉ là một chuỗi thư khác, điều này tốt cho việc xây dựng nhóm
Lập trình cặp
Lập trình cặp là một cách tiếp cận phát triển phần mềm Agile xuất phát từ XP [Lập trình cực đoan]. Lập trình cặp bao gồm hai nhà phát triển nhóm với nhau trên một máy tính. Họ tham gia nỗ lực viết mã và kiểm tra. Đây là một hình thức đánh giá mã vì có một bàn phím duy nhất. một người đang xem lại mã được viết bởi người kia
Lập trình cặp có một số lợi thế. Đây là một cách tuyệt vời để cố vấn cho một nhà phát triển cơ sở và phát hiện một số lỗi càng sớm càng tốt
Mặt khác, các nhà phát triển thường đạt năng suất cao nhất khi họ ở một mình, trong vùng dòng chảy và không bị gián đoạn. Do đó, lập trình cặp có hệ thống có thể làm giảm năng suất và khiến các nhà phát triển ít nhiệt tình hơn. Mã được viết bởi một nhà phát triển duy nhất trong khu vực dòng chảy vẫn có thể được những người khác xem xét và cải thiện sau này
Công cụ trợ giúp cho Đánh giá mã
Công cụ đánh giá mã giúp rất nhiều để cải thiện quy trình đánh giá. Với công cụ đánh giá có thể trở nên có hệ thống. Chúng có thể được theo dõi và một số số liệu có thể được suy luận để cải thiện quy trình. Các yêu cầu kéo của Github hiện đang phổ biến để thực hiện hầu hết các nhu cầu đánh giá. Ngoài ra còn có các công cụ tinh vi hơn như SmartBear Collaborator với nhiều loại SCM [Quản lý kiểm soát nguồn] được hỗ trợ
Tuy nhiên, nhược điểm của code review là chi phí cao vì nó đòi hỏi nhiều nỗ lực của con người. Đây là lý do tại sao nhóm phải đấu tranh để tự động hóa quá trình xem xét trên diện rộng để thu hẹp sự can thiệp của con người vào những điểm thiết yếu. Để làm như vậy, công cụ NDepend phân tích nhiều khía cạnh của mã như đặt tên, độ phức tạp, thiết kế, mùi mã, mức độ bao phủ mã bằng các bài kiểm tra… và tạo ảnh chụp nhanh. Hai ảnh chụp nhanh có thể được so sánh. Một số truy vấn dựa trên C# LINQ giúp dễ dàng truy vấn bất kỳ thứ nguyên nào trong vùng đồng bằng giữa hai ảnh chụp nhanh được so sánh. Dưới đây là một số truy vấn mẫu
Trước bất kỳ đánh giá nào của con người, các nhà phát triển có thể buộc phải tránh làm cho các phương thức vốn đã phức tạp trở nên phức tạp hơn nhờ truy vấn bên dưới. Lưu ý tiền tố warnif count > 0 biến truy vấn thành quy tắc. Bằng cách này, các kết quả phù hợp của truy vấn trở thành vấn đề cần khắc phục
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Avoid making complex methods even more complex
cảnh báo đếm > 0
từ m ở JustMyCode. Phương pháp ở đâu
!m. IsAbstract &&
m. IsPresentInBothBuilds[] &&
m. Mã đã thay đổi[] &&
m. Phiên bản cũ hơn[]. Độ phức tạp theo chu kỳ > 6
hãy delta = m. Độ phức tạp theo chu kỳ - m. Phiên bản cũ hơn[]. Độ phức tạp theo chu kỳ
ở đâu delta > 0
theo thứ tự delta giảm dần
chọn mới {
m,
m. Phiên bản mới hơn[]. Độ phức tạp theo chu kỳ ,
delta ,
}
Có thể dễ dàng viết một quy tắc để buộc mã bao phủ 100% bằng các thử nghiệm trên tất cả các lớp mới được viết. Nhưng chắc chắn các nhà phát triển sẽ thấy nó hơi cực đoan vì một số mã như mã UI khó có thể được kiểm tra
Tuy nhiên họ chắc chắn sẽ chấp nhận quy tắc này. Các loại đã từng được bao test 100% vẫn nên được bao 100%. Chúng ta có thể tự hào khi một lớp được bao phủ 100% vì điều đó có nghĩa là lớp đó được thiết kế tốt vì nó có thể kiểm tra đầy đủ. Phạm vi bảo hiểm 100% cũng có nghĩa là nếu lớp có lỗi, có thể dễ dàng điều chỉnh các bài kiểm tra đơn vị để sao chép nó nhằm sửa lỗi. Sau khi sửa lỗi, với phạm vi bảo hiểm đầy đủ, thật dễ dàng để viết một hoặc một số bài kiểm tra để xác nhận sửa lỗi. Tuy nhiên, chúng tôi cần một cách để ngăn chặn các lỗi mới xuất hiện trong một lớp được bảo hiểm 100%. Và quy tắc này giúp ích rất nhiều vì nó phát hiện ra lỗ hổng mới trong phạm vi bảo hiểm của lớp. Kinh nghiệm cho thấy lỗ hổng mới trong phạm vi thử nghiệm hầu như luôn làm sáng tỏ một số sự thật thú vị – nếu không muốn nói là lỗi – đòi hỏi sự chú ý của nhà phát triển
C#1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Types that used to be 100% covered by tests should still be 100% covered
cảnh báo đếm > 0
từ t ở JustMyCode. Các loại ở đâu
t. IsPresentInBothBuilds[] &&
t. Phiên bản cũ hơn[]. Tỷ lệ phần trăm Bảo hiểm == 100 &&
t. Tỷ lệ phần trăm Bảo hiểm 0 &&
m. Tỷ lệ phần trăm Bảo hiểm