Điều gì nên đến đầu tiên: kiểm tra hoặc xem xét mã?

Tôi còn khá mới mẻ với các mẫu thiết kế lập trình và vòng đời và tôi đã tự hỏi, điều gì nên đến trước, xem xét mã hoặc thử nghiệm, liên quan đến việc những người được thực hiện bởi những người riêng biệt?

Từ một phía, tại sao phải xem xét mã nếu không ai kiểm tra nếu nó thậm chí hoạt động? Mặt khác, một số lỗi có thể được tìm thấy sớm, nếu bạn thực hiện đánh giá trước khi thử nghiệm.

Phương pháp nào được khuyến nghị và tại sao?

Kiểm thử đơn vị nhà phát triển trước, sau đó xem lại mã, sau đó kiểm tra QA là cách tôi thực hiện. Đôi khi việc xem xét mã xảy ra trước khi kiểm tra đơn vị nhưng thường chỉ khi người kiểm tra mã thực sự bị ngập và đó là lần duy nhất anh ta hoặc cô ta có thể làm điều đó.

Tiêu chuẩn của chúng tôi là thực hiện đánh giá mã trước khi sản phẩm chuyển sang QA. Lý do cho điều đó là một khi sản phẩm đã được kiểm tra và xác minh, sẽ có ít động lực hơn để thực hiện tái cấu trúc và sửa đổi nội bộ mã. Sau đó nó sẽ phải được kiểm tra lại. Lưu ý rằng chúng tôi cũng làm thử nghiệm đơn vị trong hầu hết các trường hợp.

Lý tưởng nhất là trong một thế giới Agile, cả hai :)

Phát triển dựa trên thử nghiệm là phương pháp khuyến khích phát triển các thử nghiệm đơn vị trước khi viết mã thực tế - bằng cách này, bạn có thể nắm bắt đặc tả trong mã và viết thử nghiệm vượt qua các thử nghiệm. Theo đó, các kiểm tra tích hợp tự động đảm bảo tất cả các thành phần khác nhau phù hợp với nhau là một điều tốt để đảm bảo hơn nữa chức năng của ứng dụng của bạn phù hợp với những gì được mong đợi.

Đối với đánh giá mã, lập trình cặp là một cách hữu ích để có một tâm trí khác nhìn vào mã của bạn khi bạn thực sự viết nó. Tuy nhiên, đó không nhất thiết là một cách tiếp cận thực tế. Cách thức hoạt động trong công ty hiện tại của tôi là mã được xem xét sau khi nó được thử nghiệm trên máy cá nhân của nhà phát triển, nhưng trước khi nó được triển khai đến một máy chủ phát triển dùng chung.

Đánh giá mã được thực hiện để "đánh bóng" những thứ đã hoạt động, để đảm bảo mã có mức chất lượng mong muốn và đáp ứng các nguyên tắc mã được xác định bởi công ty.

Đánh giá mã cũng có thể xảy ra như một phần của hoạt động tối ưu hóa chung trong tương lai nơi bạn tái cấu trúc và cải thiện mã cũ.

Nếu bạn thực hành đánh giá mã trước khi thực hiện đăng ký thì đánh giá mã rơi vào giữa hai giai đoạn thử nghiệm: bạn là nhà phát triển kiểm tra mã của mình trước, đồng nghiệp của bạn thực hiện đánh giá mã, bạn kiểm tra mã, sau đó người kiểm tra chuyên dụng sẽ thực hiện kỹ lưỡng hơn từng cá nhân và kiểm tra tích hợp.

Kiểm tra trước. Kiểm tra lần cuối. Kiểm tra, kiểm tra, kiểm tra.

Đánh giá mã là tốt đẹp để có. Nhưng khó khăn - có thể là một quá trình đau đớn nếu tính cách liên quan hoặc ý kiến ​​khác nhau.

Kiểm tra rất rõ ràng: hoặc nó hoạt động hoặc nó không hoạt động. Vì vậy, kiểm tra, thử nghiệm, kiểm tra! Và xem xét mã nếu có thể.

Ở công việc cuối cùng của chúng tôi, chúng tôi đã có ba loại đánh giá mã khác nhau mà chúng tôi sẽ thực hiện ở các giai đoạn khác nhau của vòng đời sản phẩm. Loại đầu tiên chúng tôi gọi là Đánh giá Sanity và nó sẽ xảy ra trước khi nhà phát triển thậm chí đã thực hiện thử nghiệm đơn vị - thực tế, Sanity Reviews đã được thực hiện ngay cả trước khi các tính năng được hoàn thành. Ý tưởng là một cặp thành viên trong nhóm sẽ ngồi xuống và chỉ lướt qua một vài đoạn mã ngẫu nhiên như trong quá trình phát triển, để đảm bảo rằng sự phát triển sẽ diễn ra tốt đẹp và chúng ta sẽ không kết thúc với một người khổng lồ Mục nhập TDWTF khi tính năng này đã sẵn sàng để được hợp nhất. Điều này được thực hiện chủ yếu cho những người cần hướng dẫn thêm (nhà phát triển cơ sở, nhân viên mới và những người được chỉ định làm việc trên một cái gì đó họ ít quen thuộc hơn các thành viên khác trong nhóm), và nói chung giữ cho một cuộc họp ngắn mà chỉ giải quyết các vấn đề nghiêm trọng.

Tiếp theo chúng tôi đã đánh giá đơn vị. Chúng thường được thực hiện với ba nhà phát triển và sẽ được thực hiện khi một đơn vị / tính năng đã được thử nghiệm và sẵn sàng để được sáp nhập vào cây chính. Đây là đánh giá thịt nhất và sẽ đi vào khá nhiều chi tiết. Chúng tôi có ba nhà phát triển cho việc này vì chúng tôi có tác giả ban đầu của mã, người duy trì cây phải ký tắt mã trước khi có thể sáp nhập và nhà phát triển thứ ba được chọn làm dự phòng cho nhà phát triển ban đầu (ý tưởng là một khi một phần của mã đã được hoàn thành, cần có sự chuyển giao kiến ​​thức đầy đủ cho một thành viên khác trong nhóm, vì vậy luôn có ít nhất 2 người trong nhóm hoàn toàn thoải mái với bất kỳ phần nào của cơ sở mã).

Cuối cùng, chúng tôi đã có đánh giá dự án. Điều này bao gồm toàn bộ nhóm và sẽ mất khoảng một tuần, và được thực hiện sau khi QA và ra mắt sản phẩm, và mục tiêu là để mọi người ngồi vào và trải qua tất cả các thay đổi đối với toàn bộ cơ sở mã trong chu kỳ phát hành cuối cùng, nơi mọi người đều có thể nói về những thay đổi kiến ​​trúc, gotchas và quyết định những gì cần được tái cấu trúc và sửa chữa trước khi chúng tôi bắt đầu phát triển phiên bản tiếp theo của dự án.

Đầu tiên, viết các bài kiểm tra tự động cho mã được phát triển. Xem lại các bài kiểm tra để đảm bảo tất cả các yêu cầu đã biết đang được kiểm tra. Viết mã. Xem lại thường xuyên như mong muốn.

Nếu bất kỳ kiểm tra thủ công nào là bắt buộc, điều quan trọng là phải xem lại mã trước khi thực hiện bất kỳ kiểm tra thủ công nào. Mặt khác, các cải tiến thiết kế được đề xuất trong đánh giá mã sẽ bị từ chối vì các thử nghiệm thủ công sẽ phải được chạy lại.

Đó là đầu tiên, trứng hay gà?
Nó phụ thuộc.

Nếu bạn là người mới và không chắc chắn về những gì bạn làm, thì bằng mọi cách, hãy nhờ một người ngang hàng giúp đỡ bạn một chút. Đây là một đánh giá mã không chính thức nhưng rất nghiêm trọng và có giá trị.

Nói chung, mặc dù tôi sẽ đề nghị bạn tự làm công việc bẩn thỉu của mình trước tiên, hãy chắc chắn rằng bạn đã giải quyết được mã, nhận xét nó đúng chỗ (ví dụ như các bit khó khăn, không phải là những thứ rõ ràng), về cơ bản nó hoạt động (bạn có thử nghiệm ở các trường hợp chung tối thiểu và một số trường hợp giới hạn hoặc ngoại lệ). Sau đó, bạn đưa nó đến ngang hàng của bạn.

Việc mã của bạn được xem xét quá sớm có thể sẽ gây lãng phí thời gian của đồng nghiệp. Làm cho nó được xem xét quá muộn có thể sẽ lãng phí thời gian của bạn. Bạn cần tìm sự cân bằng phù hợp để có hiệu quả cao nhất. Vì vậy, một số thử nghiệm đi đầu tiên, sau đó xem xét, sau đó thử nghiệm nhiều hơn. Có khả năng bạn có thể có một số đánh giá mã, tùy thuộc vào độ phức tạp và lặp lại, với các mục đích và trọng tâm khác nhau.

Bạn càng ít chắc chắn rằng bạn càng có nhiều đánh giá (khi bạn đang trong giai đoạn học tập sớm, điều này là bình thường). Bạn càng chắc chắn càng có nhiều đánh giá (không bao giờ là quá chắc chắn về bản thân, điều đó có nghĩa là bạn thường không hoàn toàn là một người chơi nhóm và có thể khiến người khác gặp rắc rối, bạn cần chắc chắn rằng mã của bạn có thể được hiểu và được người khác sử dụng). Đó là khi bạn đang ở giữa mà các đánh giá có thể được đưa ra một số.

Chỉ hai xu của tôi.

Capers-Jones, người đã nghiên cứu và đo lường hiệu quả và chất lượng của các quy trình phát triển phần mềm hơn bất kỳ ai khác, khuyến nghị trình tự các hoạt động loại bỏ lỗi sau:

• Kiểm tra thiết kế
• Kiểm tra mã
• Bài kiểm tra đơn vị
• Kiểm tra chức năng mới
• Kiểm tra hồi quy
• Kiểm tra hiệu năng
• Kiểm tra hệ thống
• Thử nghiệm beta bên ngoài

Một trong những lý do để tiến hành kiểm tra mã trước khi thử nghiệm là để đánh giá có thể xem xét không chỉ bản thân mã, mà cả khả năng kiểm tra của mã.