TDD so với năng suất

Trong dự án hiện tại của tôi (một trò chơi, trong C ++), tôi đã quyết định rằng tôi sẽ sử dụng Test Driven Development 100% trong quá trình phát triển.

Về chất lượng mã, điều này thật tuyệt vời. Mã của tôi chưa bao giờ được thiết kế tốt hoặc không có lỗi. Tôi không co rúm người khi xem mã tôi đã viết cách đây một năm khi bắt đầu dự án và tôi đã hiểu rõ hơn về cách cấu trúc mọi thứ, không chỉ dễ kiểm tra hơn mà còn đơn giản hơn để thực hiện và sử dụng .

Tuy nhiên ... đã một năm kể từ khi tôi bắt đầu dự án. Cấp, tôi chỉ có thể làm việc với nó trong thời gian rảnh rỗi, nhưng TDD vẫn làm tôi chậm lại đáng kể so với những gì tôi đã từng làm. Tôi đọc được rằng tốc độ phát triển chậm trở nên tốt hơn theo thời gian và tôi chắc chắn nghĩ rằng việc kiểm tra dễ dàng hơn rất nhiều so với trước đây, nhưng tôi đã ở đó được một năm và tôi vẫn đang làm việc với tốc độ của ốc sên.

Mỗi lần tôi nghĩ về bước tiếp theo cần làm việc, tôi phải dừng lại mỗi lần và nghĩ về cách tôi sẽ viết một bài kiểm tra cho nó, để cho phép tôi viết mã thực tế. Đôi khi tôi sẽ bị mắc kẹt trong nhiều giờ, biết chính xác mã tôi muốn viết, nhưng không biết làm thế nào để phá vỡ nó đủ tốt để hoàn toàn bao quát nó với các bài kiểm tra. Những lần khác, tôi sẽ nhanh chóng nghĩ ra hàng tá bài kiểm tra và dành một giờ để viết bài kiểm tra để bao quát một đoạn mã thực sự nhỏ mà nếu không thì sẽ mất vài phút để viết.

Hoặc, sau khi hoàn thành bài kiểm tra thứ 50 để bao quát một thực thể cụ thể trong trò chơi và tất cả các khía cạnh của việc tạo và sử dụng nó, tôi nhìn vào danh sách việc cần làm của mình và thấy thực thể tiếp theo được mã hóa, và kinh hãi khi nghĩ đến việc viết 50 thử nghiệm tương tự khác để thực hiện nó.

Đã đến lúc, nhìn vào sự tiến bộ của năm ngoái, tôi đang xem xét từ bỏ TDD vì mục đích "hoàn thành dự án chết tiệt". Tuy nhiên, từ bỏ chất lượng mã đi kèm với nó không phải là điều tôi mong đợi. Tôi sợ rằng nếu tôi dừng viết bài kiểm tra, thì tôi sẽ bỏ thói quen làm cho mã trở nên mô-đun và có thể kiểm tra được.

Có lẽ tôi đang làm gì đó sai để vẫn chậm như vậy lúc này? Có những lựa chọn thay thế giúp tăng tốc năng suất mà không mất hoàn toàn lợi ích? TAD? Bảo hiểm ít kiểm tra? Làm thế nào để những người khác sống sót TDD mà không giết chết tất cả năng suất và động lực?

Hãy để tôi bắt đầu bằng cách cảm ơn bạn để chia sẻ kinh nghiệm của bạn và nói lên mối quan tâm của bạn ... mà tôi phải nói là không phổ biến.

• Thời gian / Năng suất: Kiểm tra viết chậm hơn so với không viết kiểm tra. Nếu bạn phạm vi nó, tôi đồng ý. Tuy nhiên, nếu bạn thực hiện một nỗ lực song song trong đó bạn áp dụng cách tiếp cận không phải TDD, thì rất có thể thời gian bạn dành mã phá vỡ phát hiện-gỡ lỗi-sửa lỗi và sửa lỗi sẽ khiến bạn rơi vào tình trạng tiêu cực. Đối với tôi, TDD là cách nhanh nhất tôi có thể đi mà không ảnh hưởng đến sự tự tin về mã của tôi. Nếu bạn tìm thấy những thứ trong phương thức của mình, đó là không thêm giá trị, hãy loại bỏ chúng.
• Số lượng kiểm tra: Nếu bạn mã hóa N điều, bạn cần kiểm tra N điều. để diễn giải một trong những dòng của Kent Beck " Chỉ thử nghiệm nếu bạn muốn nó hoạt động. "
• Bị kẹt trong nhiều giờ: Tôi cũng vậy (đôi khi và không> 20 phút trước khi tôi dừng dòng) .. Đó chỉ là mã của bạn cho bạn biết rằng thiết kế cần một số công việc. Một bài kiểm tra chỉ là một khách hàng khác cho lớp SUT của bạn. Nếu một bài kiểm tra cảm thấy khó sử dụng loại của bạn, thì rất có thể khách hàng sản xuất của bạn cũng vậy.
• Các bài kiểm tra tương tự tedium: Điều này cần thêm một số bối cảnh để tôi viết lên một phản biện. Điều đó nói rằng, Dừng lại và suy nghĩ về sự tương tự. Bạn có thể lái dữ liệu bằng cách nào đó? Có thể viết bài kiểm tra đối với loại cơ sở không? Sau đó, bạn chỉ cần chạy cùng một bộ thử nghiệm đối với từng dẫn xuất. Nghe bài kiểm tra của bạn. Hãy là người lười biếng đúng đắn và xem liệu bạn có thể tìm ra cách để tránh tẻ nhạt không.
• Dừng lại để suy nghĩ về những gì bạn cần làm tiếp theo (bài kiểm tra / thông số kỹ thuật) không phải là một điều xấu. Ngược lại, bạn nên xây dựng "điều đúng đắn". Thông thường nếu tôi không thể nghĩ ra cách kiểm tra nó, tôi cũng thường không nghĩ đến việc thực hiện. Đó là một ý tưởng tốt để loại bỏ các ý tưởng triển khai cho đến khi bạn đạt được điều đó .. có thể một giải pháp đơn giản hơn bị lu mờ bởi một thiết kế phủ đầu YAGNI-ish.

Và điều đó đưa tôi đến truy vấn cuối cùng: Làm thế nào để tôi trở nên tốt hơn? Câu trả lời của tôi (hoặc An) là Đọc, Suy ngẫm và Thực hành.

vd: Muộn, tôi giữ các tab trên

• cho dù nhịp điệu của tôi phản ánh RG [Ref] RG [Ref] RG [Ref] hay là RRRRGRRef.
• % thời gian ở trạng thái Lỗi đỏ / Biên dịch.
• Tôi có bị mắc kẹt trong trạng thái xây dựng Red / Broken không?

Bạn không cần bảo hiểm kiểm tra 100%. Hãy thực dụng.

TDD vẫn làm tôi chậm lại đáng kể

Điều đó thực sự sai.

Không có TDD, bạn dành vài tuần để viết mã, phần lớn hoạt động và dành "thử nghiệm" trong năm tới và sửa nhiều lỗi (nhưng không phải tất cả) các lỗi.

Với TDD, bạn dành một năm để viết mã thực sự hoạt động. Sau đó, bạn làm thử nghiệm tích hợp cuối cùng trong một vài tuần.

Thời gian trôi qua có lẽ sẽ giống nhau. Phần mềm TDD sẽ có chất lượng tốt hơn đáng kể.

Hoặc, sau khi hoàn thành bài kiểm tra thứ 50 để bao quát một thực thể cụ thể trong trò chơi và tất cả các khía cạnh của việc tạo và sử dụng nó, tôi nhìn vào danh sách việc cần làm của mình và thấy thực thể tiếp theo được mã hóa, và kinh hãi khi nghĩ đến việc viết 50 thử nghiệm tương tự khác để thực hiện nó.

Điều này khiến tôi tự hỏi rằng bạn đang theo bước "Tái cấu trúc" của TDD đến mức nào.

Khi tất cả các bài kiểm tra của bạn đang trôi qua, đây là lúc để bạn cấu trúc lại mã và loại bỏ trùng lặp. Trong khi mọi người thường nhớ điều này, đôi khi họ quên rằng đây cũng là lúc để cấu trúc lại các bài kiểm tra của họ , để loại bỏ sự trùng lặp và đơn giản hóa mọi thứ.

Nếu bạn có hai thực thể hợp nhất thành một để cho phép sử dụng lại mã, hãy xem xét việc hợp nhất các thử nghiệm của chúng. Bạn thực sự chỉ cần kiểm tra sự khác biệt gia tăng trong mã của bạn. Nếu bạn không thường xuyên thực hiện bảo trì trong các bài kiểm tra của mình, chúng có thể nhanh chóng trở nên khó sử dụng.

Một vài điểm triết học về TDD có thể hữu ích:

• Khi bạn không thể tìm ra cách viết một bài kiểm tra, mặc dù có nhiều kinh nghiệm viết bài kiểm tra, thì đó chắc chắn là một mùi mã . Mã của bạn bằng cách nào đó thiếu tính mô đun, điều này làm cho việc viết các bài kiểm tra nhỏ, đơn giản trở nên khó khăn.
• Việc sử dụng một chút mã là hoàn toàn chấp nhận được khi sử dụng TDD. Viết mã bạn muốn, để có ý tưởng về giao diện của nó, sau đó xóa mã và bắt đầu với các bài kiểm tra.
• Tôi thấy thực hành TDD cực kỳ nghiêm ngặt như một hình thức tập thể dục. Khi bạn lần đầu tiên bắt đầu, chắc chắn viết một bài kiểm tra đầu tiên mỗi lần và viết mã đơn giản nhất để thực hiện bài kiểm tra trước khi tiếp tục. Tuy nhiên, điều này là không cần thiết một khi bạn trở nên thoải mái hơn với việc luyện tập. Tôi không có bài kiểm tra đơn vị cho mỗi đường dẫn mã có thể tôi viết, nhưng qua kinh nghiệm tôi có thể chọn những gì cần kiểm tra bằng kiểm tra đơn vị và thay vào đó có thể được kiểm tra bằng chức năng hoặc kiểm tra tích hợp. Nếu bạn đã thực hành TDD một cách nghiêm ngặt trong một năm, tôi sẽ tưởng tượng bạn cũng đang ở gần điểm này.

EDIT: Về chủ đề triết học của thử nghiệm đơn vị, tôi nghĩ rằng điều này có thể thú vị cho bạn đọc: Con đường của Testivus

Và một điểm thực tế hơn, nếu không nhất thiết là rất hữu ích, điểm:

• Bạn đề cập đến C ++ là ngôn ngữ phát triển của bạn. Tôi đã thực hành TDD rộng rãi trong Java, sử dụng các thư viện tuyệt vời như JUnit và Mockito. Tuy nhiên, tôi đã tìm thấy TDD trong C ++ rất bực bội do thiếu các thư viện (đặc biệt là các khung mô phỏng) có sẵn. Mặc dù điểm này không giúp bạn nhiều trong tình huống hiện tại của bạn, tôi hy vọng bạn cân nhắc nó trước khi bỏ TDD hoàn toàn.

Câu hỏi rất thú vị.

Điều quan trọng cần lưu ý là C ++ không dễ kiểm tra và nói chung, chơi game cũng là một ứng cử viên rất tồi cho TDD. Bạn không thể kiểm tra xem OpenGL / DirectX có vẽ màu đỏ tam giác với trình điều khiển X và màu vàng với trình điều khiển Y dễ dàng không. Nếu vectơ bình thường, vectơ bình thường không bị lật sau khi biến đổi shader. Bạn cũng không thể kiểm tra các vấn đề cắt trên các phiên bản trình điều khiển với các quy tắc khác nhau, v.v. Hành vi vẽ không xác định do các cuộc gọi không chính xác cũng chỉ có thể được kiểm tra với đánh giá mã chính xác và SDK trong tay. Âm thanh cũng là một ứng cử viên tồi. Đa luồng, một lần nữa khá quan trọng đối với các trò chơi, lại khá vô dụng đối với bài kiểm tra đơn vị. Vì vậy, nó khó khăn.

Về cơ bản chơi game là rất nhiều GUI, âm thanh và chủ đề. GUI, ngay cả với các thành phần tiêu chuẩn bạn có thể gửi WM_ tới, rất khó để kiểm tra đơn vị.

Vì vậy, những gì bạn có thể kiểm tra, là các lớp tải mô hình, các lớp tải kết cấu, thư viện ma trận và một số - không phải là nhiều mã, và, khá thường xuyên, không thể tái sử dụng, nếu đó chỉ là dự án đầu tiên của bạn. Ngoài ra, chúng được đóng gói thành các định dạng độc quyền, do đó, không có khả năng đầu vào của bên thứ 3 có thể khác nhau nhiều, trừ khi bạn phát hành các công cụ sửa đổi, v.v.

Sau đó, một lần nữa, tôi không phải là giáo sư hoặc nhà truyền giáo TDD, vì vậy hãy lấy tất cả những thứ đó bằng một hạt muối.

Tôi có thể sẽ viết một số bài kiểm tra cho các thành phần cốt lõi chính (ví dụ thư viện ma trận, thư viện hình ảnh). Thêm một loạt các abort()đầu vào bất ngờ trong mọi chức năng. Và quan trọng nhất, tập trung vào mã kháng / đàn hồi không dễ bị phá vỡ.

Liên quan đến một lỗi, sử dụng thông minh C ++, RAII và một thiết kế tốt sẽ đi một chặng đường dài để ngăn chặn chúng.

Về cơ bản, bạn có rất nhiều việc phải làm chỉ để trang trải những điều cơ bản nếu bạn muốn phát hành trò chơi. Tôi không chắc chắn nếu TDD sẽ giúp.

Tôi đồng ý với các câu trả lời khác, nhưng tôi cũng muốn thêm một điểm rất quan trọng: Tái cấu trúc chi phí !!

Với các bài kiểm tra đơn vị được viết tốt, bạn có thể viết lại mã của mình một cách an toàn. Đầu tiên, các bài kiểm tra đơn vị được viết tốt cung cấp tài liệu tuyệt vời về ý định của mã của bạn. Thứ hai, bất kỳ tác dụng phụ đáng tiếc nào của việc tái cấu trúc của bạn sẽ được bắt gặp trong bộ thử nghiệm hiện có. Do đó, bạn đã đảm bảo rằng các giả định về mã cũ của bạn cũng đúng với mã mới của bạn.

Làm thế nào để những người khác sống sót TDD mà không giết chết tất cả năng suất và động lực?

Điều này hoàn toàn khác với kinh nghiệm của tôi. Bạn thông minh đáng kinh ngạc và viết mã mà không có lỗi, (ví dụ: do một lỗi) hoặc bạn không nhận ra mã của mình có lỗi khiến chương trình của bạn không hoạt động và vì vậy không thực sự kết thúc.

TDD là về sự khiêm tốn khi biết rằng bạn (và tôi!) Đã phạm sai lầm.

Đối với tôi thời gian viết unittests nhiều hơn tiết kiệm trong thời gian gỡ lỗi cho các dự án được thực hiện bằng TDD ngay từ đầu.

Nếu bạn không phạm sai lầm thì có lẽ TDD không quan trọng đối với bạn như đối với tôi!

Tôi chỉ có một vài nhận xét:

1. Có vẻ như bạn đang cố gắng kiểm tra mọi thứ . Có lẽ bạn không nên, chỉ những trường hợp rủi ro và rủi ro cao của một đoạn mã / phương pháp cụ thể. Tôi khá chắc chắn quy tắc 80/20 áp dụng ở đây: Bạn dành 80% bài kiểm tra viết cho 20% mã cuối cùng hoặc các trường hợp không được bảo hiểm.

2. Ưu tiên. Tham gia vào phát triển phần mềm linh hoạt và lập danh sách những gì bạn thực sự thực sự cần làm để phát hành trong một tháng. Sau đó phát hành, chỉ cần như vậy. Điều này sẽ khiến bạn suy nghĩ về mức độ ưu tiên của các tính năng. Vâng, thật tuyệt nếu nhân vật của bạn có thể thực hiện một cú backflip, nhưng nó có giá trị kinh doanh không?

TDD là tốt, nhưng chỉ khi bạn không nhắm mục tiêu bảo hiểm thử nghiệm 100%, và sẽ không nếu nó ngăn bạn tạo ra giá trị kinh doanh thực tế (tức là các tính năng, những thứ thêm vào trò chơi của bạn).

Đúng, viết bài kiểm tra và mã có thể mất nhiều thời gian hơn là chỉ viết mã - nhưng viết mã và kiểm tra đơn vị liên quan (sử dụng TDD) có thể dự đoán được nhiều hơn so với viết mã và sau đó gỡ lỗi.

Gỡ lỗi gần như bị loại bỏ khi sử dụng TDD - điều này làm cho tất cả quá trình phát triển có thể dự đoán được nhiều hơn và cuối cùng - nhanh hơn nhiều.

Tái cấu trúc liên tục - không thể thực hiện bất kỳ tái cấu trúc nghiêm trọng nào nếu không có bộ kiểm thử đơn vị toàn diện. Cách hiệu quả nhất để xây dựng mạng lưới an toàn dựa trên thử nghiệm đơn vị đó là trong TDD. Mã được tái cấu trúc tốt cải thiện đáng kể năng suất tổng thể của người thiết kế / nhóm duy trì mã.

Xem xét thu hẹp phạm vi trò chơi của bạn và đưa nó đến nơi ai đó có thể chơi hoặc bạn phát hành nó. Duy trì các tiêu chuẩn thử nghiệm của bạn mà không phải chờ đợi quá lâu để phát hành trò chơi của bạn có thể là một nền tảng để giữ cho bạn có động lực. Phản hồi từ người dùng của bạn có thể cung cấp lợi ích trong dài hạn và thử nghiệm của bạn cho phép bạn cảm thấy thoải mái với các bổ sung và thay đổi.