Một đồng nghiệp của tôi đã đưa ra một ý tưởng mà tôi thấy thú vị.

Sẽ không có ích khi viết bài kiểm tra trong quá trình đánh giá mã, bởi người thực hiện đánh giá giả định rằng chúng tôi không làm TDD?

Đối với câu hỏi này giả định rằng đây là một dự án học thuật thuần túy nên không có cuộc sống bị đe dọa. Hơn nữa, đội là 4 người. Mọi người đều biết ngôn ngữ và quen thuộc với tất cả các công cụ / thư viện / khung được sử dụng và có thể viết bài kiểm tra. Vì vậy, về cơ bản, những người không phải là kỹ sư ninja lãnh đạo toàn diện mà là những lập trình viên giỏi.

Ưu điểm tôi tìm thấy:

1. Khuyến khích sự hiểu biết sâu sắc hơn về mã trong khi xem xét để viết các bài kiểm tra có ý nghĩa.
2. Sau đó, bạn có thể thêm đánh giá mã về các thử nghiệm được thực hiện bởi tác giả của mã đang được thử nghiệm.

Nhược điểm tôi tìm thấy:

1. Vòng phản hồi giữa viết mã và kiểm tra phát triển.

EDIT: Tôi biết rằng nó sẽ không hoạt động tốt trên các ứng dụng web "bình thường". Những gì tôi có trong tâm trí là một trường hợp góc mà bạn thực hiện các thuật toán khoa học, phức tạp đòi hỏi phải quan tâm đến các chi tiết. Chúng ta hãy giả sử một cái gì đó như triển khai thư viện đồ thị của riêng tôi, NLP, v.v. Tôi tự hỏi liệu mã chúng ta đang viết có bị cô lập khỏi cơ sở dữ liệu hay không và rất khó để hiểu mức độ kiểm soát được thêm vào, người khác cần hiểu nguồn mã và thực hiện kiểm tra có ý nghĩa, làm cho toàn bộ quá trình ít bị các lỗi ít rõ ràng hơn không làm hỏng ứng dụng nhưng cuối cùng lại khiến kết quả của bạn trở nên rác rưởi?

Sẽ không có ích khi viết bài kiểm tra trong quá trình đánh giá mã, bởi người thực hiện đánh giá?

Tôi đã thấy rằng một thời điểm tốt để viết bài kiểm tra là khi bạn nhận ra rằng bạn cần một bài kiểm tra cho một tình huống.

Chuyển đổi tác vụ cho máy tính là tốn kém - thậm chí còn hơn thế đối với con người.

Tại thời điểm này, bạn thường có một sự hiểu biết tốt về các yêu cầu và phụ thuộc cho bài kiểm tra. Vì vậy, tận dụng sự chìm đắm trong nhóm của bạn trong vấn đề. Nếu bạn cần tinh chỉnh bài kiểm tra mới của mình trong tương lai, thật tuyệt, bạn đã có sẵn khung / bài kiểm tra và tất cả những gì bạn cần làm là thay đổi phần cần cải thiện.

Nếu điều đó xảy ra trong quá trình xem xét mã, tại sao không tiếp tục và làm điều đó? Tôi đã làm điều đó trước đây. Tôi đã thấy rằng tốt hơn là không, đặc biệt là nếu bạn có thể làm điều đó một cách nhanh chóng, và thậm chí tốt hơn nếu bạn không làm điều đó nếu không.

Giả sử rằng chúng ta không làm TDD?

Ngay cả khi bạn thực hành TDD, nếu bạn nhận ra rằng bạn cần một bài kiểm tra trong khi thực hiện đánh giá mã, một bài kiểm tra mà bạn không có, tại sao không viết bài kiểm tra sau đó?

Ưu

• Bạn tận dụng sự tập trung của bạn vào mã đang được xem xét.
• Đôi khi, đánh giá mã trở thành trò chơi và thời gian trò chuyện khi mọi người không tham gia. Viết một bài kiểm tra khuyến khích mọi người suy nghĩ tích cực hơn về mã được xem xét.
• Nhiều thành viên cơ sở của nhóm sẽ có cơ hội học hỏi từ kinh nghiệm viết bài kiểm tra.
• Bạn có thể xác định tài năng trong nhóm của bạn mà bạn không biết bạn có.

Có thực sự là một lừa đảo mà nhiều bài kiểm tra có thể dẫn đến nhiều mã hơn? Nếu bài kiểm tra là cần thiết, và mã là cần thiết cho bài kiểm tra, và bây giờ bạn có nó, thì đó là một điều tốt .

Hãy cẩn thận

Có lẽ một số nhóm cần phải tập trung vào những thứ khác. Nếu nó gây ra sự xao lãng khỏi các ưu tiên hoặc đánh giá mã của bạn vượt quá lịch trình, thì bạn cần hạn chế hoặc cắt bỏ bài viết thực tế của bài kiểm tra. Tuy nhiên, xem xét mã chắc chắn có thể xác định các bài kiểm tra cần phải viết, và có lẽ ít nhất chúng có thể được đặt ra để người viết hoàn thành sau này.

Đây là một ý tưởng tuyệt vời, với một cảnh báo. Đừng thay thế các bài kiểm tra viết của nhà phát triển bằng các bài kiểm tra viết của người đánh giá. Có người đánh giá của bạn tìm kiếm các trường hợp góc và đầu vào sẽ phá vỡ mã. Nói cách khác, hãy để họ thử viết các bài kiểm tra mới mà nhà phát triển ban đầu không nghĩ sẽ viết.

Viết các bài kiểm tra đặc tính là một cách hoàn toàn tuyệt vời để có được sự hiểu biết về một đoạn mã bạn không viết. Việc những người đánh giá của bạn thực hiện các bài kiểm tra bổ sung tại mã giúp họ hiểu rõ hơn về cách thức hoạt động của mã, cách mã hóa và cách cải thiện. Trong khi đó, tăng phạm vi bảo hiểm mã của bạn.

Đây là tất cả chiến thắng trong cuốn sách của tôi.

Tôi không nghĩ rằng ý tưởng này hoàn toàn không có công - tuy nhiên, lợi ích chính của TDD và cộng sự là các vấn đề được phát hiện sớm . Nhà phát triển cũng được đặt tốt nhất để phát hiện trường hợp góc nào có thể yêu cầu sự chú ý cụ thể. Nếu điều này được để lại cho đến khi xem xét mã, thì có nguy cơ kiến ​​thức này có thể bị mất.

Kiểm tra viết trong quá trình xem xét mã sẽ gặp phải vấn đề tương tự như kiểm tra thủ công truyền thống - sự hiểu biết về các quy tắc kinh doanh có thể khác nhau từ nhà phát triển đến nhà phát triển cũng như sự siêng năng.

Ngoài ra còn có một cuộc thảo luận cũ sẽ chạy và chạy về việc liệu các nhà phát triển sẽ kiểm tra mã của họ tốt như vậy nếu họ biết có một chức năng kiểm tra ngược dòng sẽ bắt các lỗi nghiêm trọng hơn.

Tôi đồng ý với câu trả lời của @ RobbieDee nhưng tôi có thêm một chút để thêm.

Nếu bạn thực sự thích ý tưởng này, tại sao không có cùng một người viết các bài kiểm tra trước mã dưới dạng tiêu chí chấp nhận thực thi cho câu chuyện của người dùng?

Điều đó sẽ làm điều tương tự, vẫn giữ thông tin phản hồi ngắn và khiến mọi người có một cuộc thảo luận xung quanh câu chuyện, mà tôi nghĩ sẽ có giá trị lớn hơn.

Nhược điểm là mối nguy hiểm của cuộc họp tiêu chí chấp nhận vô tận :-( và tôi nghĩ rằng bạn đang cố gắng đưa mọi người vào đánh giá mã để xem mã thực thi nhưng tôi khuyên bạn nên lập trình cặp và xoay cặp như một giải pháp tốt hơn để Vấn đề đó.

OP đã thêm một chỉnh sửa trong đó họ bố trí thêm chi tiết về việc đây là một tính năng nặng hoặc khó về thuật toán.

Để đáp lại điều đó tôi sẽ nói thêm rằng bản năng của bạn để có được nhiều mắt hơn về vấn đề và giải pháp là tốt. Có thể ghép nối với nhiều người một đối một cho đến khi mọi người đã thấy một chút khó khăn về mã thực thi và kiểm tra. Mỗi ý tưởng đưa ra những ý tưởng mới và tăng thêm giá trị.

Có một ý tưởng đôi khi gọi lập trình mob, như ghép nối nhưng với nhiều người hơn. Đây gần như là những gì bạn đang nói nhưng họ giúp đỡ tại thời điểm viết chứ không phải trong một đánh giá chính thức sau đó. Điều này không dành cho tất cả mọi người và có thể yêu cầu một người điều khiển (người lãnh đạo) mạnh mẽ để làm cho nó hoạt động hoặc một nhóm rất thoải mái với nhau và quá trình.

Thực hiện sau khi lập trình mob thực tế, tôi đoán sẽ có nhiều ưu điểm giống nhau khi nhiều người nhìn thấy vấn đề và đề xuất cải tiến và nếu đó là cách nhóm của bạn hoạt động thoải mái thì điều đó có thể giúp nhưng tôi thực sự sẽ cố gắng giữ điều cần thiết sự xuất hiện của điều này xuống đến mức tối thiểu vì tôi nghĩ nó có thể làm chậm đội.

Giống như bạn nói, nếu bạn đang chạy một nhóm TDD, thì đây là bản mô tả vì mã đã được kiểm tra.

Nhìn chung, tôi không nghĩ rằng đây là một ý tưởng tuyệt vời, nhưng nó phụ thuộc vào cách tiếp cận hiện tại của bạn và những gì phù hợp với bạn. Về cơ bản, vấn đề tôi thấy là bạn mất lợi thế "vòng phản hồi ngắn" của các bài kiểm tra. Nhận thông báo tức thì ngay khi bạn phá vỡ thứ gì đó ngay cả khi bạn đang viết mã mới là nơi các bài kiểm tra thực sự tỏa sáng. Nếu bạn hoãn kiểm tra cho đến khi xem xét mã, về cơ bản, bạn đang nói rằng "chúng tôi COULD đã khắc phục vấn đề này sớm hơn trong thời gian ngắn hơn và có ít người tham gia hơn, nhưng ít nhất tất cả chúng ta đều học được điều gì đó (có thể)". Tôi chỉ muốn đảm bảo rằng mọi người gửi mã được kiểm tra để xem xét và sau đó bạn đánh giá tính đúng đắn và khả năng duy trì của các thử nghiệm. Rốt cuộc, xem lại mã là để xem xét, không phải để viết mã.

Mặt khác, tôi khuyên bạn nên FIDDLE với các bài kiểm tra / mã trong quá trình đánh giá. Cố gắng phá vỡ một cái gì đó. Nhận xét một điều kiện nếu. thay thế một boolean bằng đúng / sai theo nghĩa đen. Xem nếu các bài kiểm tra là thất bại.

Nhưng vâng, tất cả trong tất cả, tôi khuyên bạn nên viết bài kiểm tra của mình cùng với mã của bạn và sau đó xem lại tất cả cùng một lúc.

Nó phụ thuộc vào những gì bạn đang làm trong xem xét mã. Tôi nghĩ có hai lý do chính để viết bài kiểm tra ở giai đoạn đó:

• trước tiên, nếu bạn cũng tái cấu trúc trong quá trình xem lại mã và bạn lưu ý rằng không có đủ các bài kiểm tra đơn vị để bao gồm loại tái cấu trúc mà bạn muốn áp dụng, hãy thêm các bài kiểm tra như vậy

• thứ hai, nếu mã nhìn vào bạn như thể nó có lỗi và bạn muốn nó chứng minh (hoặc từ chối) điều này, hãy viết một bài kiểm tra cho nó

Cả hai trường hợp đều thể hiện sự cần thiết cho các xét nghiệm không có tại thời điểm này, nhưng nên có. Tất nhiên, nó có thể phụ thuộc vào văn hóa nhóm của bạn nếu loại bài kiểm tra này được viết bởi người đánh giá hoặc bởi tác giả ban đầu, nhưng ai đó nên viết bài kiểm tra.

Trên thực tế, tôi không nghĩ đây là "trường hợp góc" chỉ phù hợp với "thuật toán khoa học, phức tạp" - hoàn toàn ngược lại, điều này phù hợp với bất kỳ loại phần mềm nào bạn mong đợi ở một mức độ nhất định về chất lượng.

Không, đừng làm điều đó. Bạn sẽ khiến họ nghĩ TDD thật kinh khủng.

Tôi nghĩ rằng @ k3b có nó ngay trong các bình luận về câu hỏi. Mã được viết thông qua quy trình kiểu TDD có xu hướng nhìn và tương tác, rất khác với mã được viết mà không cần kiểm tra. Việc thêm các kiểm tra (tốt) vào mã chưa được kiểm tra thường mất rất nhiều cấu trúc lại mã để làm rõ ý định và các bộ phận chuyển động của nó.

Bằng cách thêm các bài kiểm tra sau khi viết mã, bạn bỏ lỡ các khía cạnh kiến ​​trúc về lợi ích của TDD (mà theo tôi là một trong những lợi ích chính). Không chỉ vậy, bạn đang yêu cầu một người khác, người gần như không quen thuộc với mã này, thực hiện cú đánh thêm các bài kiểm tra vốn đã khó thêm.

Người thêm các bài kiểm tra sẽ phải cấu trúc lại mã một cách đáng kể hoặc họ sẽ phải làm việc rất chăm chỉ để kiểm tra mã không thể kiểm chứng. Dù bằng cách nào, họ sẽ không tận hưởng trải nghiệm. Mặc dù đây có thể không phải là TDD cổ điển, nhưng họ sẽ không nhìn thấy nó theo cách đó và bạn có thể loại bỏ chúng khỏi TDD một lần và mãi mãi.

(Nếu bạn đang theo dõi một quá trình TDD đã, viết thêm các xét nghiệm trong xét mã sẽ ít có hại, mặc dù kinh nghiệm của tôi, nếu các cuộc thử nghiệm đã tốt bằng văn bản, nó chỉ là dễ dàng để giải thích sự thử nghiệm thêm để người nộp mã để xem xét và yêu cầu họ viết chúng.)

Các thử nghiệm đơn vị trong quá trình xem xét mã là một sự thay thế kém cho các thử nghiệm đơn vị trong quá trình phát triển.

Những gì bạn đang đề xuất có rất nhiều ý nghĩa, bằng trực giác. Đánh giá để làm gì? Để kiểm tra xem mã có tốt không. Các xét nghiệm là gì? Để kiểm tra xem mã có tốt không. Vậy tại sao không kết hợp cả hai?

Đây là lý do tại sao.

Mang mã theo thử nghiệm là công việc khó khăn. Viết mã chỉ hoạt động ở một điều mà nó có nghĩa là làm một việc; viết mã có thể được kiểm tra hiệu quả và hiệu quả là một cách khác. Thực tế là mã hiện chạy theo hai kịch bản - "công việc thực tế" và "thử nghiệm" - đòi hỏi tính linh hoạt cao hơn nhiều, đòi hỏi mã đó phải có khả năng tự đứng vững một cách có ý nghĩa.

Viết mã của bạn để nó có thể kiểm tra được là công việc và kỹ năng bổ sung. Tái cấu trúc mã của người khác để kiểm tra, khi nó không được viết với khả năng kiểm tra bắt đầu, có thể là một nhiệm vụ chính.

Bạn đang nhân đôi nỗ lực giữa nhà phát triển và người đánh giá. Có lẽ, nhà phát triển của bạn không đưa mã của mình để xem xét mà không có ít nhất một mức độ tin cậy rằng nó đang hoạt động. Anh ta đã cần phải kiểm tra mã. Bây giờ, có nhiều cấp độ và phạm vi thử nghiệm khác nhau. QA kiểm tra mã sau khi nhà phát triển và người đánh giá. Nhưng bất kỳ phạm vi nào bạn nghĩ là phù hợp cho nhà phát triển và người đánh giá, nhà phát triển sẽ không có ý nghĩa gì khi tìm cách kiểm tra mã đến mức đó một lần , nhưng làm cho các thử nghiệm của anh ta bị vứt bỏ và khó tái tạo, sau đó đưa người đánh giá đến phát triển thử nghiệm một lần nữa, lần này là những người tự động và tái sản xuất. Bạn chỉ cần cả hai đầu tư thời gian để viết các bài kiểm tra giống nhau - một lần kém, một lần tốt.

Bạn đang biến việc xem xét thành một bước dài hơn, tốn nhiều công sức hơn. Nếu kiểm tra là một phần chính của quá trình xem xét, điều gì xảy ra khi một số thử nghiệm thất bại ? Người đánh giá có chịu trách nhiệm cho tất cả các bài kiểm tra đang chạy không, vì vậy cô ấy cũng cần gỡ lỗi mã? Hay là nó sẽ được ping-ponged qua lại, một bài kiểm tra viết, cái kia khiến chúng vượt qua?

Đôi khi bạn có thể viết một loạt các bài kiểm tra hoàn toàn trực giao với nhau, vì vậy bạn không cần phải chơi bóng bàn. Người kiểm tra viết một tá bài kiểm tra, một nửa trong số đó không thành công, nhà phát triển sửa lỗi và tất cả các bài kiểm tra vẫn còn hiệu lực và vượt qua ngay bây giờ. Nhưng ... rất nhiều thời gian, bạn đã gặp phải các lỗi chặn hoặc các lỗi yêu cầu thiết kế lại và thay đổi API hoặc không có gì. Nếu bạn không chịu trách nhiệm vượt qua các bài kiểm tra qua lại giữa người đánh giá và nhà phát triển, thì bạn không thực sự ở giai đoạn đánh giá. Bạn vẫn đang phát triển.

Cần viết bài kiểm tra không khuyến khích xem xét kỹ lưỡng hơn. Về cơ bản, điều đó có nghĩa là bạn càng đi sâu, bạn càng phải viết nhiều bài kiểm tra và có lẽ chúng sẽ là những bài kiểm tra khó cần đi sâu vào hệ thống.

So sánh với nhà phát triển viết các bài kiểm tra, trong đó ưu đãi của anh ta là: nếu tôi không viết các bài kiểm tra quan trọng, người đánh giá sẽ chỉ ra điều đó trong bài đánh giá.

Ngay cả người đánh giá cũng sẽ hiểu rõ hơn về hệ thống nếu cô ấy cần vượt qua các bài kiểm tra kỹ lưỡng về mã , sau đó nếu cô ấy cần tự quyết định khi nào cô ấy có thể ngừng viết bài kiểm tra đào sâu và chỉ cần OK xem xét mã.

Nếu nhà phát triển không viết bài kiểm tra đơn vị, người đánh giá sẽ không. Có nhiều trở ngại trong việc áp dụng thử nghiệm như một thông lệ. Có thể bạn đang chịu quá nhiều áp lực và cơ sở mã của bạn khó có thể được kiểm tra. Có thể bạn không có kinh nghiệm trong kiểm tra và cảm thấy như bạn không đủ khả năng học tập. Có lẽ bạn đã có một kẻ giết người rìu gửi những ghi chú đe dọa cho những người viết bài kiểm tra. Tôi không biết!

Nhưng bất kể nguyên nhân là gì, sẽ an toàn khi đặt cược rằng nó áp dụng như nhau cho người đánh giá và nhà phát triển. Nếu nhóm bị căng thẳng, người đánh giá sẽ không có nhiều thời gian hơn nhà phát triển (nếu có, hãy phân phối lại công việc để mọi người không quá căng thẳng ). Nếu không ai biết cách viết bài kiểm tra đơn vị tốt, người đánh giá có lẽ cũng không (nếu có, cô ấy nên ngồi xuống và dạy cho đồng đội của mình ).

Gợi ý này nghe có vẻ như cố gắng vượt qua vòng lao lý từ đồng nghiệp này sang đồng nghiệp khác. Và tôi chỉ không thấy cách nào để giải quyết tốt, trước hết và trên hết vì tạo ra một tình huống rất khó (và không lành mạnh) để tạo ra một tình huống mà một người là người duy nhất có thể làm xét nghiệm, và một người khác không thể làm bất kỳ thử nghiệm nào cả.

Những gì không làm việc là có các bài kiểm tra bìa xem xét là tốt. Nếu nhà phát triển đã viết mười bài kiểm tra, nhiều khả năng người đánh giá có thể giúp đề xuất mười bài kiểm tra khác, hơn là nếu nhà phát triển không viết bất kỳ bài kiểm tra nào.

Và, nếu thử nghiệm các trường hợp góc là một nhiệm vụ chính, có thể có ý nghĩa để phân phối rộng rãi hơn trên toàn đội. ** Một khi mã có thể kiểm tra được ở vị trí đầu tiên, việc viết nhiều bài kiểm tra trở nên dễ dàng hơn nhiều. **

Đánh giá là một thời gian tuyệt vời để phát hiện các trường hợp góc. Và, nếu người đánh giá có thể nhảy vào và viết một bài kiểm tra cho các trường hợp góc mà cô ấy tìm thấy, thì này - tốt hơn hết! Nhưng nói chung, giả sử rằng người đánh giá có thể viết các bài kiểm tra trong đó nhà phát triển không có vẻ là một ý tưởng rất kém.