Đánh giá mã chậm hơn chu kỳ phân phối / kiểm tra

14

Trong quy trình Agile của chúng tôi, chúng tôi có Sprints 2 tuần. Nhiệm vụ được phân phối hàng ngày (bản dựng hàng ngày) và Nhóm thử nghiệm hoàn thành thử nghiệm của họ ngay lập tức vào ngày hôm sau hoặc thậm chí cùng ngày.

Chúng tôi cũng có các đánh giá mã Dev, yêu cầu một số thời gian (1-2 giờ), vì vậy chúng được lên lịch 3 lần một tuần: Thứ Hai-Thứ Tư-Thứ Sáu. Các nhà phát triển gặp nhau và đề xuất cách cải thiện / tái cấu trúc mã.

Vấn đề của chúng tôi là, vào thời điểm các Mục Hành động xuất hiện sau khi xem xét mã, hầu hết các tác vụ đã được kiểm tra. Người kiểm tra không muốn kiểm tra lại những gì đã vượt qua bài kiểm tra của họ. Họ không quan tâm đến những thay đổi nội bộ.

Có phải chúng ta đang hiểu sai về quy trình Agile? Các đánh giá mã không tương thích với chu kỳ Phát hành / Kiểm tra hàng ngày? Chúng tôi không thể tổ chức đánh giá mã mỗi ngày vì chúng chiếm hết thời gian của mọi người.

— gen b.
nguồn

Tôi đã tìm thấy một số đề xuất có thể hữu ích - Đánh giá mã trong các nhóm Agile - phần II (được tìm thấy từ một tìm kiếm Google rất nhanh - bạn có thể tìm thấy thêm).

— Dukeling

1

Người kiểm tra của bạn đang làm việc trên các nhiệm vụ "phát hành"? Định nghĩa "phát hành" của nhóm bạn có bao gồm đánh giá mã và phân giải mục hành động không? Hoặc là đánh giá mã xảy ra bên ngoài định nghĩa của nhóm bạn đã hoàn thành?

— Kent A.

1

Nhóm thử nghiệm của bạn không có bộ hồi quy tự động?

— Telastyn

5

Làm thế nào để bạn thực hiện đánh giá mã Code? Đây có phải là một quy trình chính thức kéo dài mà người đánh giá phải làm việc thông qua toàn bộ danh sách kiểm tra các số liệu chất lượng (nỗ lực: nhiều người trong nhiều giờ)? Hoặc đó chỉ là bất kỳ thành viên khác trong nhóm xem qua mã và đặt câu hỏi nếu có gì đó không ổn (nỗ lực: 10 phút30 cho lập trình viên và người đánh giá)? Tại sao bạn đánh giá mã? Để đảm bảo chất lượng mã? Để bắt bọ? Để truyền bá kiến thức về hệ thống giữa nhiều người? Là cơ chế xem xét mã của bạn giúp thực hiện các mục tiêu này, hoặc nó chỉ là quan liêu không ai muốn làm?

— amon

Tôi thích tất cả các câu trả lời, nhưng hãy để tôi thêm một điểm tôi cho là quan trọng. Bạn đang hỏi liệu bạn có hiểu sai về Agile không nhưng bạn không nói phương pháp nào. Bạn đang theo dõi Scrum? Quan trọng nhất: bạn có định nghĩa về "Xong" không? Tôi đang hỏi bởi vì tôi thấy rất .. lạ là bạn đang xem xét một cái gì đó "được giao" trước khi hoàn thành thực sự làm việc với nó. Âm thanh như mã xem lại là một cái gì đó "thêm" bạn làm chỉ vì.

— Lorenzo Dematté

8

Người kiểm tra không muốn kiểm tra lại giống như nói rằng "lập trình viên không muốn cấu trúc lại." Đó là một phần của công việc. Quá trình có thể được trình bày lại như một cái gì đó như thế này: Nhiệm vụ được tạo ra. Mã được tạo ra. Mã được kiểm tra. Mã được xem xét. Sự không hoàn hảo được tìm thấy trong mã. Nhiệm vụ mới được tạo để giải quyết các khiếm khuyết này (ví dụ: mã được tái cấu trúc). Những nhiệm vụ mới này yêu cầu thử nghiệm mới.

— John
nguồn

2

+1 Trong bản phát hành hàng ngày Phương pháp Agile, không mở lại các tác vụ. Tạo một nhiệm vụ mới để giải quyết các vấn đề được tìm thấy và lên lịch cho nó theo các ưu tiên của nhóm bạn. Nhiệm vụ mới = hành động QA mới (có thể có nghĩa là chạy lại các bài kiểm tra tương tự). Nếu QA không thích nó, có rất nhiều nghề nghiệp khác.

— Kent A.

Điều đó rõ ràng hoạt động nhưng có vẻ không hiệu quả.

— usr

7

Nếu bạn định xem lại mã tại một thời điểm nào đó, việc đánh giá sớm sẽ không tốn kém hơn. Và dường như bạn có một quy trình kiểm tra đắt tiền, vì vậy bạn không muốn kiểm tra hai lần. Do đó, rẻ hơn để xem lại mã trước khi thử nghiệm. Xem lại mã sau khi kiểm tra không làm cho công việc nhanh hơn. Nó làm cho nó đi chậm hơn và cám dỗ bạn cung cấp mã được viết kém nhưng được kiểm tra thành công. Theo thời gian tất cả các mã chưa được xem xét này sẽ làm cho công việc chậm hơn và chậm hơn. Sau đó, một đối thủ cạnh tranh hiệu quả hơn sẽ cung cấp một sản phẩm tốt hơn với chi phí thấp hơn và trò chơi kết thúc.

Ngoài ra, tự động hóa thử nghiệm. Kiểm tra thủ công là như vậy 1970.

— kevin cline
nguồn

5

Nếu bạn cảm thấy khó có được các đánh giá mã xảy ra trong thời gian bạn hiện có trước QA, bạn nên xem xét việc đánh giá mã nhẹ hơn, như Đánh giá mã trong các nhóm Agile, Phần II mà @Dukeling đã đăng thảo luận.

Tôi thấy rằng ngay cả điều đơn giản nhất có thể được gọi là đánh giá mã cũng mang lại lợi ích: trước khi thực hiện mã (hoặc đẩy DVCS), hãy gọi cho một nhà phát triển khác và xem qua thay đổi của bạn. Điều này có thể mất năm hoặc mười phút. Mục tiêu của đánh giá mã này là "Điều này có ý nghĩa với nhà phát triển khác không?" Mục tiêu không phải là để thúc đẩy việc triển khai thiết kế hoặc hoàn toàn phù hợp với ý tưởng cá nhân của người đánh giá về cách nó nên được viết. Nó đã cho những lợi ích sau:

Cải thiện kiến thức được chia sẻ về cách làm việc của mã
Bị bắt nhầm mã hoặc có khả năng mã sai vì hành động giải thích mã là đủ để làm cho tác giả suy nghĩ lại mọi thứ
Đã giúp dần dần phát triển thành ngữ và phong cách nhóm, bởi vì nó giúp giải thích mọi thứ dễ dàng hơn
Rất ít càu nhàu từ đội

Đánh giá mã sâu hơn hoàn toàn làm việc tốt hơn để tìm ra vấn đề. Nhưng bạn phải có khả năng thực hiện chúng và hành động dựa trên chúng để có được giá trị. Một quy trình nhẹ mà bạn có thể làm mọi lúc có thể hữu ích hơn một quy trình nặng mà cứ bị trì hoãn, hoặc chỉ thêm mọi thứ vào hồ sơ tồn đọng.

— Alan Shutko
nguồn

1

Một giải pháp cho vấn đề này là thực hiện đánh giá nhanh mã bởi một người khác sau khi câu chuyện của người dùng kết thúc, do đó sẽ không có bất kỳ lỗi cơ bản / rõ ràng nào trong mã.

Nhưng điều này phải xảy ra trước chu kỳ thử nghiệm. Sau đó, sẽ có ít thay đổi mã hơn sau khi thử nghiệm, khi bạn thực hiện đánh giá lớn hơn với tất cả các nhóm cùng nhau.

— Bồ nông bay thấp
nguồn

1

Từ âm thanh của nó, người kiểm tra không muốn kiểm tra lại vì kiểm tra là một quá trình đau đớn / tốn kém.

Kiểm tra tự động hóa bởi cả nhà phát triển và người thử nghiệm là một phần thưởng lớn cho các nhóm cố gắng làm việc một cách nhanh nhẹn. Các bài kiểm tra của bạn càng rẻ, dễ dàng và có thể tái tạo càng nhiều thì bạn càng có thể thực hiện chúng - và bạn sẽ càng ít kháng cự hơn khi thay đổi điều gì đó.

Thực hiện một refactor nhanh dựa trên một số phản hồi dev? Nhấn nút lớn màu đỏ thực hiện bộ hồi quy / khói của bạn và thực hiện thủ công nhanh một lần để kiểm tra xem có bất kỳ vấn đề hình ảnh nào có thể bị cắt không. Dễ dàng!

Khi bạn ở một nơi như thế, việc kiểm tra lại sẽ không phải là việc vặt - đó sẽ là bản chất thứ hai.

— F1dave
nguồn