Nên xem lại mã trước hoặc sau khi kiểm tra đơn vị

Tôi đang tranh luận với đồng nghiệp về thời điểm thực hiện đánh giá mã - trước hoặc sau khi kiểm tra đơn vị. Thực hành tốt nhất là gì?

Một số yếu tố chúng ta có thể cần phải tính đến (có thể có nhiều hơn):

• Kích thước thay đổi mã - một thay đổi lớn có nghĩa là sẽ có nhiều thay đổi hơn từ việc xem xét mã. Nếu những thay đổi này lớn hơn, nếu UT trước khi xem lại mã, bạn sẽ cần lặp lại hầu hết các UT của mình.
• Thời gian cần thiết để thực hiện kiểm tra đơn vị
• Là chức năng mới hay sửa lỗi

Bạn phải luôn kiểm tra đơn vị trước khi thực hiện đánh giá mã và đây là lý do

1. Nếu mã của bạn bị hỏng theo cách có thể bị bắt bởi các bài kiểm tra đơn vị, bạn sẽ lãng phí thời gian của nhà phát triển khác bằng cách khiến họ tham gia vào chu trình đỏ / xanh / tái cấu trúc.
2. Các thử nghiệm cho thấy các nhà phát triển khác dự định sử dụng mã này để xem xét dễ dàng hơn.
3. Các thử nghiệm phải được xem xét cùng với mã được kiểm tra trong trường hợp bạn thiếu các trường hợp thử nghiệm hoặc các thử nghiệm của bạn không hoạt động đúng.
4. Các thử nghiệm và xem xét mã có xu hướng nắm bắt các vấn đề khác nhau chỉ với một chút trùng lặp trong các vấn đề được tìm thấy. Các thử nghiệm đơn vị không cảm thấy khó chịu khi phải kiểm tra lại mã khi người đánh giá phát hiện ra vấn đề, các nhà phát triển cảm thấy khó chịu và có lẽ sẽ không làm tốt như vậy trong lần thứ hai.

Có thể có những lý do khác nhưng đó là những lý do mà cá nhân tôi đã thấy và có kinh nghiệm đã triển khai thực hành đánh giá mã trong 3 nhóm / công ty khác nhau.

Chỉnh sửa Tất nhiên những điều trên là dành cho thời gian khi xem lại mã là một bước trong quy trình phát triển phần mềm của bạn (cho dù là thác nước hay nhanh nhẹn). Nếu bạn đang làm việc trên một đoạn mã đặc biệt lớn hoặc khó khăn, hãy thoải mái để có được một đôi mắt khác về nó bất cứ lúc nào.

Nhận xét mã là khi mã được "thực hiện".

Trong tổ chức của tôi, định nghĩa của chúng tôi về "thực hiện" bao gồm các bài kiểm tra đơn vị (như chúng tôi nhắm đến TDD) để đánh giá mã là mã hoàn chỉnh - và mã hoàn chỉnh bao gồm các bài kiểm tra.

Ngoài ra, các bài kiểm tra cần xem xét và tái cấu trúc để có ý nghĩa rằng chúng là một phần của đánh giá mã.

Các xét nghiệm nên được coi là một phần của mã để xem xét. Vì vậy, nó có ý nghĩa để xem xét sau khi thử nghiệm được thực hiện.

Đảm bảo các bài kiểm tra cũng được xem xét. Điều này là rất quan trọng cho những người mới làm bài kiểm tra đơn vị.

Hãy chắc chắn rằng nhóm của bạn thực hiện tiêm phụ thuộc, khung cách ly, giả so với sơ khai, đường nối, tương tác với kiểm tra dựa trên trạng thái và tích hợp so với kiểm tra đơn vị.

Bạn không cần phải thực hiện các chủ đề đã nói ở trên, nhưng bạn nên hiểu chúng.

Tốt,

Điều này phụ thuộc vào ý của bạn trong "Bài kiểm tra đơn vị" ...

Nếu đó là Kiểm tra đơn vị kiểu TDD thì không có nghĩa gì vì bạn viết kiểm tra trong khi bạn viết mã. Không có trường hợp nào về sau. Trong trường hợp này, bạn liên tục cải thiện chất lượng mã: Tái cấu trúc ...

VÀ

Nếu đó là "kiểm tra đơn vị" cổ điển [bất cứ điều gì nó có nghĩa là tôi không biết, nhưng ý tôi là kiểm tra sau khi bạn viết mã và thường được thực hiện bởi những người khác] thì tiêu chí chính là những gì bạn mong đợi từ kiểm tra mã hóa và bản chất của kiểm tra đơn vị: nếu bạn muốn phản hồi nhanh - thực hiện đánh giá và thực hiện hành động và không có kiểm tra đơn vị tự động, bạn sẽ phải chờ kiểm tra đơn vị. Nếu bạn muốn xác định các vấn đề trưởng thành với đánh giá mã và áp dụng giải pháp tăng dần cho các lần lặp tiếp theo, bạn có thể thực hiện trước khi kiểm tra đơn vị ...

Nhưng xét cho cùng , đối với cá nhân, đối với bài kiểm tra mã hóa, bài kiểm tra đơn vị sau hoặc sau này không phải là một tiêu chí thực sự đối với tôi ...

Tại sao chúng tôi làm codereview? Đối với chất lượng mã ... Thay vì cổng "kiểm soát chất lượng", hãy đưa chất lượng vào quy trình phát triển phần mềm của bạn ...

Tôi có xu hướng nói rằng, hãy "nhanh nhẹn" ... đừng đợi mã được hoàn thành để thực hiện một số đánh giá mã nhanh, không chính thức: có những nhà phát triển cùng với ai và đối tượng mà bạn thực sự có thể chờ đợi toàn bộ mã + kiểm tra kết thúc để hoàn thành ... nhưng

khi nói đến các môn học thực sự mới (tính năng hoàn toàn mới, nghiên cứu gần, một thứ hoàn toàn mới đối với nhóm), xem xét mã sớm, không mất thời gian: thỉnh thoảng hãy xem đồng nghiệp: cách ly là một yếu tố quan trọng thất bại trong trường hợp này.

nếu nhà phát triển cũng mới đối với nhóm, hãy xem lại mã sớm và có thể thường xuyên .

và nhân tiện, kiểm tra đơn vị cũng cần xem lại mã.