Làm thế nào để những người làm TDD xử lý mất việc khi làm tái cấu trúc lớn

Trong một thời gian, tôi đã cố gắng học viết các bài kiểm tra đơn vị cho mã của mình.

Ban đầu tôi bắt đầu thực hiện TDD thực sự, nơi tôi sẽ không viết bất kỳ mã nào cho đến khi tôi viết bài kiểm tra thất bại trước.

Tuy nhiên, gần đây tôi có một vấn đề nhức nhối để giải quyết liên quan đến rất nhiều mã. Sau khi dành một vài tuần để viết bài kiểm tra và sau đó viết mã, tôi đã đi đến một kết luận đáng tiếc rằng toàn bộ cách tiếp cận của tôi sẽ không hiệu quả, và tôi sẽ phải bỏ công việc hai tuần và bắt đầu lại.

Đây là một quyết định đủ tồi tệ để đưa ra khi bạn vừa viết mã, nhưng khi bạn cũng đã viết hàng trăm bài kiểm tra đơn vị, điều đó càng trở nên khó khăn hơn khi chỉ cần vứt bỏ tất cả.

Tôi không thể nghĩ rằng tôi đã lãng phí 3 hoặc 4 ngày nỗ lực để viết các bài kiểm tra đó khi tôi có thể đặt mã cùng nhau để chứng minh khái niệm và sau đó viết các bài kiểm tra sau khi tôi hài lòng với cách tiếp cận của mình.

Làm thế nào để những người thực hành TDD xử lý đúng các tình huống như vậy? Có trường hợp nào bẻ cong các quy tắc trong một số trường hợp hay bạn luôn luôn viết những bài kiểm tra trước, ngay cả khi mã đó có thể trở nên vô dụng?

Tôi cảm thấy có hai vấn đề ở đây. Đầu tiên là bạn không nhận ra trước rằng thiết kế ban đầu của bạn có thể không phải là phương pháp tốt nhất. Nếu bạn đã biết trước điều này, bạn có thể đã chọn phát triển một hoặc hai nguyên mẫu ném nhanh , để khám phá các tùy chọn thiết kế có thể và để đánh giá đâu là cách hứa hẹn nhất để làm theo. Trong tạo mẫu, bạn không cần phải viết mã chất lượng sản xuất và không cần kiểm tra đơn vị mọi ngóc ngách (hoặc hoàn toàn), vì trọng tâm duy nhất của bạn là học, không phải đánh bóng mã.

Bây giờ, nhận ra rằng bạn cần tạo mẫu và thử nghiệm thay vì bắt đầu phát triển mã sản xuất ngay lập tức, không phải lúc nào cũng dễ dàng và thậm chí không phải lúc nào cũng có thể. Được trang bị kiến ​​thức vừa đạt được, bạn có thể nhận ra sự cần thiết của việc tạo mẫu vào lần tới. Hoặc có thể không. Nhưng ít nhất bạn biết bây giờ rằng tùy chọn này sẽ được xem xét. Và đây là kiến ​​thức quan trọng.

Vấn đề khác là IMHO với nhận thức của bạn. Tất cả chúng ta đều phạm sai lầm, và thật dễ dàng để nhìn lại khi nhìn lại những gì chúng ta nên làm khác đi. Đây chỉ là cách chúng ta học. Viết khoản đầu tư của bạn vào các bài kiểm tra đơn vị vì giá của việc học mà tạo mẫu có thể quan trọng và vượt qua nó. Chỉ cần phấn đấu để không mắc lỗi tương tự hai lần :-)

Quan điểm của TDD là nó buộc bạn phải viết các mức tăng nhỏ của mã trong các hàm nhỏ , chính xác để tránh vấn đề này. Nếu bạn đã dành hàng tuần để viết mã trên một tên miền và mọi phương thức tiện ích duy nhất bạn đã viết sẽ trở nên vô dụng khi bạn suy nghĩ lại về kiến ​​trúc, thì phương thức của bạn gần như chắc chắn là quá lớn ở nơi đầu tiên. (Vâng, tôi biết điều này không chính xác an ủi rght bây giờ ...)

Brooks nói "kế hoạch vứt bỏ một cái, dù sao đi nữa, bạn sẽ làm được". Dường như với tôi rằng bạn đang làm điều đó. Điều đó nói rằng, bạn nên viết các bài kiểm tra đơn vị của bạn để kiểm tra đơn vị mã và không có nhiều mã. Đó là những thử nghiệm chức năng nhiều hơn và do đó nó nên qua bất kỳ thực hiện nội bộ.

Ví dụ, nếu tôi muốn viết một bộ giải PDE (phương trình vi phân từng phần), tôi sẽ viết một vài bài kiểm tra để cố gắng giải những điều mà tôi có thể giải được bằng toán học. Đó là những thử nghiệm "đơn vị" đầu tiên của tôi - đọc: các thử nghiệm chức năng chạy như một phần của khung xUnit. Chúng sẽ không thay đổi tùy thuộc vào thuật toán tôi sử dụng để giải quyết PDE. Tất cả những gì tôi quan tâm là kết quả. Các bài kiểm tra đơn vị thứ hai sẽ tập trung vào các hàm được sử dụng để mã hóa thuật toán và do đó sẽ là thuật toán cụ thể - nói Runge-Kutta. Nếu tôi phát hiện ra rằng Runge-Kutta không phù hợp, thì tôi vẫn sẽ có những bài kiểm tra cấp cao nhất (bao gồm cả những bài kiểm tra cho thấy Runge-Kutta không phù hợp). Do đó, lần lặp thứ hai vẫn có nhiều bài kiểm tra giống như lần lặp đầu tiên.

Vấn đề của bạn có thể về thiết kế và không nhất thiết là mã. Nhưng không có thêm chi tiết, rất khó để nói.

Bạn nên nhớ rằng TDD là một quá trình lặp lại. Viết một bài kiểm tra nhỏ (trong hầu hết các trường hợp, một vài dòng là đủ) và chạy nó. Thử nghiệm sẽ thất bại, bây giờ trực tiếp làm việc trên nguồn chính của bạn và cố gắng thực hiện chức năng được thử nghiệm để thử nghiệm vượt qua. Bây giờ bắt đầu lại.

Bạn không nên cố gắng viết tất cả các bài kiểm tra trong một lần, bởi vì, như bạn đã nhận thấy, điều này sẽ không thành công. Điều này giúp giảm nguy cơ lãng phí thời gian viết các bài kiểm tra sẽ không được sử dụng.

Tôi nghĩ rằng bạn đã tự nói điều đó: bạn không chắc chắn về cách tiếp cận của mình trước khi bạn bắt đầu viết tất cả các bài kiểm tra đơn vị của mình.

Điều tôi học được khi so sánh các dự án TDD ngoài đời thực mà tôi đã làm việc (thực tế không phải là nhiều, chỉ có 3 trong 2 năm làm việc) với những gì tôi đã học về mặt lý thuyết, đó là Kiểm thử tự động! độc quyền).

Nói cách khác, T trong TDD không cần phải có chữ U ... Nó được tự động hóa, nhưng không phải là một bài kiểm tra đơn vị (như trong các lớp và phương thức kiểm tra) so với kiểm tra chức năng tự động: nó ở cùng cấp độ độ chi tiết chức năng như kiến ​​trúc bạn hiện đang làm việc. Bạn bắt đầu cấp cao, với một vài thử nghiệm và chỉ có bức tranh lớn chức năng, và cuối cùng chỉ có bạn có hàng ngàn UT, và tất cả các lớp của bạn được xác định rõ trong một kiến ​​trúc đẹp ...

Các bài kiểm tra đơn vị cung cấp cho bạn rất nhiều trợ giúp khi bạn làm việc theo nhóm, để tránh thay đổi mã tạo ra các chu kỳ lỗi vô tận. Nhưng tôi chưa bao giờ viết bất cứ điều gì chính xác khi bắt đầu làm việc trên một dự án, trước khi có ít nhất một POC hoạt động toàn cầu cho mỗi câu chuyện của người dùng.

Có lẽ đó chỉ là cách cá nhân của tôi để làm điều này. Tôi không có đủ kinh nghiệm để quyết định từ đầu những mô hình hoặc cấu trúc dự án của tôi sẽ có, vì vậy thực sự tôi sẽ không lãng phí thời gian của mình để viết 100s UT ngay từ đầu ...

Tổng quát hơn, ý tưởng phá vỡ mọi thứ và ném tất cả sẽ luôn ở đó. Là "liên tục" như chúng ta có thể cố gắng với các công cụ và phương pháp của mình, đôi khi cách duy nhất để chống lại entropy là bắt đầu lại. Nhưng mục tiêu là khi điều đó xảy ra, thử nghiệm tự động và đơn vị bạn đã thực hiện sẽ khiến dự án của bạn trở nên ít tốn kém hơn so với nếu không có ở đó - và nó sẽ, nếu bạn tìm thấy trạng thái cân bằng.

Làm thế nào để những người thực hành TDD xử lý đúng các tình huống như vậy?

1. bằng cách xem xét khi nào nguyên mẫu so với khi nào mã
2. bằng cách nhận ra rằng thử nghiệm đơn vị không giống như TDD
3. bằng cách viết bài kiểm tra TDD để xác minh tính năng / câu chuyện, không phải đơn vị chức năng

Sự kết hợp của thử nghiệm đơn vị với sự phát triển dựa trên thử nghiệm là nguồn gốc của nhiều nỗi thống khổ và đau khổ. Vì vậy, hãy xem xét lại một lần nữa:

• kiểm tra đơn vị liên quan đến việc xác minh từng mô-đun và chức năng riêng lẻ trong việc thực hiện ; trong UT, bạn sẽ thấy sự nhấn mạnh vào những thứ như số liệu và kiểm tra độ phủ mã thực thi rất nhanh
• phát triển dựa trên thử nghiệm liên quan đến việc xác minh từng tính năng / câu chuyện trong các yêu cầu ; trong TDD, bạn sẽ thấy sự nhấn mạnh vào những thứ như viết bài kiểm tra trước, đảm bảo rằng mã được viết không vượt quá phạm vi dự định và tái cấu trúc cho chất lượng

Tóm lại: kiểm thử đơn vị có trọng tâm thực hiện, TDD có trọng tâm yêu cầu. Chúng không giống nhau.

Phát triển thử nghiệm điều khiển có nghĩa là để lái xe phát triển của bạn. Các bài kiểm tra bạn viết giúp bạn khẳng định tính chính xác của mã bạn đang viết và tăng tốc độ phát triển từ dòng đầu tiên trở đi.

Bạn dường như tin rằng các bài kiểm tra là một gánh nặng và chỉ có ý nghĩa cho sự phát triển gia tăng sau này. Dòng suy nghĩ này không phù hợp với TDD.

Có lẽ bạn có thể so sánh nó với kiểu gõ tĩnh: mặc dù người ta có thể viết mã mà không sử dụng thông tin kiểu tĩnh, việc thêm kiểu tĩnh vào mã giúp xác nhận một số thuộc tính của mã, giải phóng tâm trí và cho phép tập trung vào cấu trúc quan trọng thay vào đó, do đó làm tăng vận tốc và hiệu quả.

Vấn đề với việc thực hiện tái cấu trúc chính là bạn có thể và đôi khi sẽ đi theo một con đường dẫn bạn nhận ra rằng bạn đã cắn nhiều hơn những gì bạn có thể nhai. Tái cấu trúc khổng lồ là một sai lầm. Nếu thiết kế hệ thống bị thiếu sót ngay từ đầu, thì việc tái cấu trúc chỉ có thể đưa bạn đến nay trước khi bạn cần đưa ra quyết định khó khăn. Hoặc rời khỏi hệ thống như hiện tại và làm việc xung quanh nó, hoặc lên kế hoạch thiết kế lại và thực hiện một số thay đổi lớn.

Tuy nhiên có một cách khác. Lợi ích thực sự của việc tái cấu trúc mã là làm cho mọi thứ đơn giản hơn, dễ đọc hơn và thậm chí dễ bảo trì hơn. Khi bạn tiếp cận một vấn đề mà bạn không chắc chắn, bạn tăng đột biến, đi xa để xem nó có thể dẫn đến đâu để tìm hiểu thêm về vấn đề, sau đó vứt bỏ gai nhọn và áp dụng tái cấu trúc mới dựa trên mức tăng đột biến đã dạy bạn Vấn đề là, bạn thực sự chỉ có thể cải thiện mã của mình một cách chắc chắn nếu các bước nhỏ và các nỗ lực tái cấu trúc của bạn không vượt quá khả năng viết bài kiểm tra của bạn trước. Sự cám dỗ là viết một bài kiểm tra, sau đó viết mã, sau đó viết mã thêm vì một giải pháp có vẻ rõ ràng, nhưng ngay sau đó bạn nhận ra rằng sự thay đổi của bạn sẽ thay đổi nhiều bài kiểm tra hơn, vì vậy bạn cần cẩn thận chỉ thay đổi một điều một lúc.

Do đó, câu trả lời là không bao giờ biến việc tái cấu trúc của bạn thành một vấn đề chính. Bước chân em bé. Bắt đầu bằng cách trích xuất các phương thức, sau đó tìm cách loại bỏ trùng lặp. Sau đó chuyển sang các lớp trích xuất. Mỗi bước nhỏ, một thay đổi nhỏ tại một thời điểm. NẾU bạn đang giải nén mã, hãy viết một bài kiểm tra trước. Nếu bạn đang xóa mã, sau đó xóa mã đó và chạy thử nghiệm của bạn và quyết định xem có cần thử nghiệm nào nữa không. Một bước nhỏ bé tại một thời điểm. Có vẻ như sẽ mất nhiều thời gian hơn, nhưng thực sự sẽ rút ngắn đáng kể thời gian tái cấu trúc của bạn.

Tuy nhiên, thực tế là mọi sự tăng đột biến dường như là một sự lãng phí tiềm năng của nỗ lực. Thay đổi mã đôi khi không đi đến đâu và bạn thấy mình khôi phục mã từ vcs của mình. Đây chỉ là một thực tế của những gì chúng ta làm hàng ngày. Tuy nhiên, mọi đột biến không bị lãng phí, nếu nó dạy cho bạn một cái gì đó. Mọi nỗ lực tái cấu trúc thất bại sẽ dạy cho bạn rằng bạn đang cố gắng thực hiện quá nhiều quá nhanh, hoặc cách tiếp cận của bạn có thể sai. Điều đó cũng không lãng phí thời gian nếu bạn học được điều gì đó từ nó. Bạn càng làm công cụ này, bạn càng học được nhiều hơn và bạn sẽ trở nên hiệu quả hơn với nó. Lời khuyên của tôi là chỉ nên mặc nó bây giờ, học cách làm nhiều hơn bằng cách làm ít hơn và chấp nhận rằng đây chỉ là cách mọi thứ có thể cần phải làm cho đến khi bạn trở nên tốt hơn trong việc xác định mức độ tăng vọt trước khi nó dẫn bạn đến đâu.

Tôi không chắc chắn về lý do tại sao cách tiếp cận của bạn trở nên thiếu sót sau 3 ngày. Tùy thuộc vào sự không chắc chắn của bạn trong kiến ​​trúc của bạn, bạn có thể xem xét thay đổi chiến lược thử nghiệm của mình:

• Nếu bạn không chắc chắn về hiệu suất, Bạn có thể muốn bắt đầu với một vài thử nghiệm tích hợp để khẳng định hiệu suất?

• Khi độ phức tạp của API là những gì bạn đang nghiên cứu, hãy viết một số bài kiểm tra đơn vị nhỏ, thực sự để tìm ra cách tốt nhất để thực hiện điều đó. Đừng bận tâm thực hiện bất cứ điều gì, chỉ cần làm cho các lớp của bạn trả về các giá trị được mã hóa cứng hoặc làm cho chúng ném NotImcellenceedExceptions.

Đối với tôi, các bài kiểm tra đơn vị cũng là một dịp để đưa giao diện vào sử dụng "thực" (cũng như thực tế như các bài kiểm tra đơn vị đi!).

Nếu tôi bị buộc phải thiết lập một bài kiểm tra, tôi phải thực hiện thiết kế của mình. Điều này giúp giữ cho mọi thứ lành mạnh (nếu một cái gì đó quá phức tạp đến nỗi viết một bài kiểm tra cho nó là một gánh nặng, nó sẽ như thế nào khi sử dụng nó?).

Điều này không tránh được những thay đổi trong thiết kế, thay vào đó nó phơi bày sự cần thiết của chúng. Vâng, viết lại hoàn toàn là một nỗi đau. Để (cố gắng) tránh nó, tôi thường thiết lập (một hoặc nhiều) nguyên mẫu, có thể bằng Python (với sự phát triển cuối cùng trong c ++).

Cấp, bạn không luôn luôn có thời gian cho tất cả những điều tốt đẹp. Đó chính xác là những trường hợp khi bạn sẽ cần một lượng thời gian LARGER để đạt được mục tiêu của mình ... và / hoặc để giữ mọi thứ trong tầm kiểm soát.

Chào mừng bạn đến rạp xiếc phát triển .

Thay vì tôn trọng tất cả cách mã hóa 'hợp pháp / hợp lý' ngay từ đầu,
hãy thử trực giác , trên hết nếu nó quan trọng và mới đối với bạn và nếu không có mẫu nào xung quanh trông giống như bạn muốn:

- Viết theo bản năng của bạn, từ những điều bạn đã biết , không phải với tinh thần và trí tưởng tượng của bạn.
- Và dừng lại.
- Lấy kính lúp và kiểm tra tất cả các từ bạn viết: Bạn viết "văn bản" vì "văn bản" gần với Chuỗi, nhưng "động từ", "tính từ" hoặc một cái gì đó chính xác hơn là cần thiết, đọc lại và điều chỉnh phương pháp với ý nghĩa mới
. .. hoặc, bạn đã viết một đoạn mã nghĩ về tương lai? loại bỏ nó
- Đúng, thực hiện các nhiệm vụ khác (thể thao, văn hóa hoặc những thứ khác ngoài kinh doanh), quay lại và đọc lại.
- Tất cả đều vừa vặn,
- Đúng, làm nhiệm vụ khác, trở lại và đọc lại.
- Tất cả đều phù hợp, vượt qua TDD
- Bây giờ tất cả đều chính xác, tốt
- Hãy thử điểm chuẩn để chỉ ra những điều cần được tối ưu hóa, thực hiện nó.

Điều gì xuất hiện:
- bạn đã viết một mã tôn trọng tất cả các quy tắc
- bạn có được trải nghiệm, cách thức mới cho công việc
- một điều gì đó thay đổi trong tâm trí bạn, bạn sẽ không bao giờ sợ cấu hình mới.

Và bây giờ, nếu bạn thấy một UML trông giống như ở trên, bạn sẽ có thể nói
"Ông chủ, tôi bắt đầu bằng TDD cho việc này ...."
đó là một điều mới?
"Ông chủ, tôi sẽ thử vài thứ trước khi quyết định cách tôi sẽ viết mã .."

Trân trọng từ PARIS
Claude