Lợi ích / hạn chế của việc phân loại lỗi trong quá trình đánh giá mã ngang hàng

Khoảng 3 tháng trước, nhóm kỹ thuật của chúng tôi đã đưa ra Bảng đánh giá được sử dụng cho tất cả các đánh giá mã ngang hàng. Hôm nay, tôi đã thảo luận với một trong những người tham gia vào quá trình đó và phát hiện ra rằng chúng tôi đang tìm kiếm một sự thay thế (có thể là một cái gì đó thương mại) vì một số tính năng bị thiếu.

Một trong những tính năng được nhiều người yêu cầu là khả năng phân loại / phân loại từng nhận xét đánh giá mã (nghĩa là vấn đề về phong cách, quy ước mã hóa, rò rỉ tài nguyên, lỗi logic, sự cố ... bất cứ điều gì).

Đối với những đội thường xuyên thực hành đánh giá mã, việc phân loại này có phải là thông lệ chung không? Bạn làm điều đó? bạn đã làm nó trong quá khứ? Nó tốt / xấu?

Một mặt, nó cung cấp cho nhóm một số số liệu nhiều hơn và có thể sẽ chỉ ra các lĩnh vực cụ thể hơn mà các nhà phát triển có thể cần phải được đào tạo (ít nhất đó có vẻ là đối số). Có những lợi ích khác? Mặt khác, và đây là mối quan tâm của tôi, là nó sẽ làm chậm quá trình xem xét mã nhiều hơn nữa. Với tư cách là trưởng nhóm, tôi đã thực hiện một phần đánh giá khá lớn và tôi luôn thích khả năng này, để làm nổi bật một đoạn mã, bỏ qua một nhận xét và tiếp tục nhanh nhất có thể. Mặc dù tôi đã không thử nó một cách cá nhân, tôi có cảm giác rằng việc mở rộng hộp tổ hợp đó mỗi lần và cuộn / tìm kiếm đúng danh mục sẽ có cảm giác như có gì đó đang làm bạn vấp ngã. Ngoài ra nếu chúng ta bắt đầu giữ số liệu về công cụ này,

Tôi tin rằng bạn đã trả lời phần lớn câu hỏi của bạn về lợi ích và nhược điểm tương đối.

Đánh giá mã thường có thể khá tốn công và rút ra các vấn đề, và bất cứ điều gì thêm vào thời gian để xem lại mã sẽ làm cho nó có vẻ tồi tệ hơn. Theo cách tôi thấy, bạn muốn giữ quá trình đánh giá của mình thật ngắn và không phải lao động quá nhiều so với các điểm tốt hơn. Vì vậy, chìa khóa là quyết định những gì về quy trình đánh giá mang lại giá trị kinh doanh cho nhóm của bạn.

Các vấn đề về phong cách có lẽ là một trong những mục tôi sẽ đặt là ưu tiên thấp nhất. Chắc chắn, việc giữ mã gọn gàng và được định dạng đồng nhất có thể giúp dễ hiểu hơn, nhưng việc lộn xộn về kiểu dáng cũng có thể dẫn đến sự thiếu hiệu quả trong quá trình mã hóa, bởi vì lo lắng về việc mã đẹp sẽ khiến các nhà phát triển nghĩ ra những vấn đề cần giải quyết như thế nào. Nếu bạn vẫn lo ngại về các vấn đề về kiểu, thì sử dụng công cụ kiểm tra Kiểu / Định dạng (Ví dụ: StyleCop cho C #) là một cách tuyệt vời để giải quyết các vấn đề về kiểu cụ thể đến thời điểm cuối cùng và thực hiện quy trình ra quyết định liên quan đến kiểu ra khỏi tay các nhà phát triển, giải phóng suy nghĩ của họ cho những thứ quan trọng hơn. Nếu bạn không có một sản phẩm như vậy cho ngôn ngữ bạn chọn, có lẽ một trình phân tích cú pháp đơn giản có thể được viết để quét nhanh mã của bạn cho các vấn đề như vậy,

Rò rỉ bộ nhớ và các vấn đề cụ thể về hiệu suất khác sẽ không bao giờ phụ thuộc vào quá trình xem xét để chọn ra. Chắc chắn, nếu bạn phát hiện ra thứ gì đó rõ ràng sẽ gây ra vấn đề lớn, bạn nên chỉ ra nó, nhưng đó không phải là mục đích của việc xem xét mã để theo dõi từng vấn đề về bộ nhớ / hiệu năng trong mã của bạn. Đó là những gì một công cụ định hình tốt dành cho, và chúng chắc chắn đáng giá từng xu bạn bỏ ra nếu bạn quản lý để xác định vị trí rất tốt cho ngôn ngữ bạn đang phát triển.

Các vấn đề logic là vấn đề tốt nhất, và đây là những điều thực sự có thể hút rất nhiều thời gian quý giá khi bạn đang xem xét mã. Thay vì để tất cả điều này hoàn toàn cho việc xem xét mã, đây là những gì bài kiểm tra đơn vị của bạn nên được sử dụng cho. Có, thậm chí các bài kiểm tra có thể sai, tuy nhiên nếu bạn phát triển bài kiểm tra trước, hãy bám vào hiệu trưởng SRP và DRY, tái cấu trúc không thương tiếc và xác định các bài kiểm tra đơn vị của bạn như một phương tiện để xác thực thông số kỹ thuật của bạn, bạn sẽ thấy rằng bạn sẽ kết thúc với các vấn đề liên quan đến logic ít hơn nhiều. Nếu bạn kiểm tra sau khi viết mã, bạn sẽ ít gặp phải các vấn đề logic tiềm ẩn khi chúng phát sinh và có nhiều khả năng quên kiểm tra một lộ trình cụ thể thông qua mã của bạn.

Vì vậy, nếu bạn làm mọi thứ như tôi đã đề xuất ở đây, điều đó khiến bạn phải làm gì trong phần đánh giá mã? Câu trả lời đơn giản là việc xem xét mã của bạn trở thành một quy trình khá đơn giản, theo đó người viết mã giải thích cho người đánh giá về cách yêu cầu cụ thể đã được nắm bắt trong các thử nghiệm và cách các thử nghiệm đó được áp dụng cho các vấn đề được giải quyết. Bạn có xu hướng phát hiện kiểm tra mã nhiều hơn và phân tích các kiểm tra kỹ lưỡng hơn, vì đây là nơi có thể đo được giá trị kinh doanh lớn nhất và đặc biệt là khi mã đó cần được duy trì sau đó. Để làm cho việc xem xét mã kiểm tra trở nên khó khăn hơn, sử dụng khung kiểm tra Hành vi tốt có thể đơn giản hóa đánh giá rất nhiều, vì các thông số kỹ thuật được ghi lại trong mã dưới dạng mô tả tiếng Anh gần như đơn giản về cách kiểm tra sẽ chạy. Kiểm tra chi tiết được thực hiện trên bất kỳ mã nào hỗ trợ các bài kiểm tra, và nếu khung BDD của bạn tạo ra các báo cáo văn bản đẹp liệt kê các bài kiểm tra trong các câu chuyện tính năng / câu chuyện văn bản đơn giản, thì quá trình này thậm chí còn dễ dàng hơn. Tất cả điều này bổ sung cho một quy trình cực kỳ hiệu quả sẽ có giá trị như một đánh giá mã truyền thống hơn, nhưng có thể được tiến hành nhanh hơn và tập trung hơn, giúp bạn tránh bị sa lầy vào những chuyện nhỏ nhặt và kiểm tra hai lần điều đó thường dẫn bạn đến đâu. Cách tiếp cận gọn hơn này có nghĩa là dành nhiều thời gian hơn để thử nghiệm và mã hóa, và ít thời gian hơn cho các quy trình hành chính. nhưng có thể được tiến hành nhanh hơn và theo cách tập trung hơn, giúp bạn tránh bị sa lầy vào những chuyện nhỏ nhặt và kiểm tra hai lần thường không dẫn bạn đến đâu. Cách tiếp cận gọn hơn này có nghĩa là dành nhiều thời gian hơn để thử nghiệm và mã hóa, và ít thời gian hơn cho các quy trình hành chính. nhưng có thể được tiến hành nhanh hơn và theo cách tập trung hơn, giúp bạn tránh bị sa lầy vào những chuyện nhỏ nhặt và kiểm tra hai lần thường không dẫn bạn đến đâu. Cách tiếp cận gọn hơn này có nghĩa là dành nhiều thời gian hơn để thử nghiệm và mã hóa, và ít thời gian hơn cho các quy trình hành chính.

Vậy những số liệu đó thì sao? Nếu tất cả các vấn đề được coi đơn giản là "lỗi", thì số liệu duy nhất bạn thực sự cần quan tâm là số lỗi bạn gặp phải trước và sau khi phát hành, theo thời gian và liệu các lỗi được xác định có theo xu hướng cụ thể không. Nếu bạn đang sử dụng ngay cả một nửa hệ thống theo dõi vấn đề, tất cả thông tin này sẽ thực sự nằm trong tầm tay bạn và bạn sẽ không cần phải lo lắng về việc liệu quy trình xem xét của bạn có cần xác định chúng hay không. Vào cuối ngày, nhóm của bạn muốn làm những gì họ giỏi, đó là viết phần mềm và không dành quá nhiều thời gian cho các vấn đề hành chính thường chỉ cung cấp một cái gì đó quan tâm cho 1 hoặc 2 cá nhân trong công ty.

... mặt khác, và đây là mối quan tâm của tôi, là nó sẽ làm chậm quá trình xem xét mã ...

Nếu bạn muốn giữ cho các bài đánh giá nhẹ thì hãy nỗ lực tiêu thụ những thứ như điều tra, sửa lỗi và kiểm tra các lỗi được phát hiện không nên có.

• Tùy chọn đơn giản ( câm nếu bạn muốn) để xử lý đó là tốt, chỉ cần thả nó và đợi cho đến khi người kiểm tra tìm và báo cáo lỗi. Hạn chế chính của phương pháp này là một số vấn đề dễ thấy trong mã nguồn có thể mất nhiều nỗ lực để khám phá trong thử nghiệm hộp đen.
   
  Các vấn đề luồng và rò rỉ bộ nhớ thường thuộc loại này. Cuộc đua dữ liệu khiến tôi mất một phút để phát hiện bằng cách xem mã, có thể ngồi đó hàng tháng trời, vượt qua tất cả các bài kiểm tra trước khi nó lấy cái đầu xấu xí của nó.

Vì ở trên, tôi không bao giờ sử dụng và không đề xuất một tùy chọn như trên.

• Một lựa chọn khác là để dequeue công việc nặng - theo nghĩa là nó đi của nhà phê bình hàng đợi làm việc của tôi ở một nơi khác. Tùy chọn này là một cái tôi sử dụng, cái tôi khá thoải mái.
   
  Cách tiếp cận khá đơn giản. Nếu tôi cảm thấy (các) vấn đề mà tôi thấy có thể mất nhiều nỗ lực để giải quyết, tôi chỉ cần tạo một vé trong trình theo dõi vấn đề với tiêu đề như "điều tra và giải quyết các vấn đề được chỉ ra trong đánh giá mã <đánh giá ID / URL>" và tiếp tục thông qua mã làm cho ý kiến ​​trong một hình thức miễn phí. Tôi không lãng phí thời gian vào những thứ sẽ được thực hiện trên mỗi vé tôi đã mở - bởi vì nó sẽ vào hàng đợi làm việc theo nhóm và được ưu tiên và xử lý theo cách thông thường.
   
  Bằng cách đó, tôi đảm bảo rằng 1) quá trình xem xét vẫn nhẹ nhất có thể và 2) các vấn đề được phát hiện sẽ không bị lãng quên.

Có vẻ như bạn đang tìm kiếm codestriker . Nó có một tính năng để phân loại các vấn đề cả theo chế độ, cấp độ và loại.

Đối với những đội thường xuyên thực hành đánh giá mã, việc phân loại này có phải là thông lệ chung không?

Vâng, vì tôi sử dụng công cụ trên, tôi buộc phải làm. Vấn đề tôi thấy với điều đó là đôi khi có thể khó có thể ổn, bởi vì có rất nhiều lựa chọn.

Việc phân loại các vấn đề cung cấp ít giá trị cho việc xem xét mã, vì nhận xét là quan trọng hơn. Trên thực tế, vì tôi buộc phải đặt 4 trường trong công cụ ở trên cho mỗi nhận xét, nó trở nên cồng kềnh.

Sau này khi bạn kiểm tra tóm tắt các đánh giá, bạn có thể thấy rằng phân phối dường như có phân phối duy nhất. Mọi người có xu hướng không phạm sai lầm tương tự nhiều lần.

Chúng tôi mã đánh giá bằng cách sử dụng Nguyên nhân chính / Nhỏ và Nguyên nhân đơn giản (Yêu cầu / Thiết kế / Thực hiện). Giữ các mục số xuống cho số liệu có thể sử dụng, mà không có gánh nặng quá hạt mịn. Hiếm khi có một cuộc thảo luận về một thể loại vì có quá ít để lựa chọn.

Theo dõi đánh giá của chúng tôi là cổ xưa, nhưng đã phát triển hơn 20 năm. Công cụ của "sự lựa chọn" là Excel, vì vậy nó đã quá nặng nề. Chúng tôi đang chuyển sang Gerrit để đánh giá mã ít chính thức hơn (Bên ngoài "Quy trình" vì nó phù hợp với nhu cầu của nhà phát triển hơn - với gerrit chúng tôi chỉ cần bình luận và tiếp tục. Không phải là "số liệu".

Cá nhân tôi nghĩ rằng Metrics được đánh giá quá cao - đánh giá là về cải tiến mã và hỏi bất kỳ ai đã ngồi vào một vài người, họ sẽ cho bạn biết những điều tương tự mà số liệu sẽ làm. Tuy nhiên, các số liệu không thể được tranh luận với. Chúng cũng có thể được xử lý một cách hữu ích theo yêu cầu và quản lý không phải là người khôn ngoan hơn (đôi khi tôi là một người hay hoài nghi.)