Kiến trúc tiến hóa và thiết kế nổi dần: Thiết kế dựa theo thử nghiệm, Phần 1 Cho phép thử nghiệm để điều khiển và cải tiến thiết kế của bạn Neal Ford, Kiến trúc phần mềm, ThoughtWorks

Tóm tắt: Hầu hết các nhà phát triển nghĩ rằng phần mang lại lợi ích nhất của việc áp dụng phát triển dựa theo thử nghiệm (TDD) là các thử nghiệm. Tuy nhiên, khi đã thực hiện đúng, TDD cải thiện thiết kế tổng thể của mã lệnh của bạn. Bài viết này trong loạt bài kiến trúc tiến hóa và thiết kế nổi dần thông qua một ví dụ mở rộng sẽ chỉ ra thiết kế có thể rõ nét dần từ các mối quan tâm nổi lên sau các thử nghiệm như thế nào. Việc thử nghiệm chỉ...
Nội dung trích xuất từ tài liệu:
Kiến trúc tiến hóa và thiết kế nổi dần: Thiết kế dựa theo thử nghiệm, Phần 1 Cho phép thử nghiệm để điều khiển và cải tiến thiết kế của bạn Neal Ford, Kiến trúc phần mềm, ThoughtWorks Kiến trúc tiến hóa và thiết kế nổi dần: Thiết kế dựa theo thử nghiệm, Phần 1Cho phép thử nghiệm để điều khiển và cải tiến thiết kế của bạnNeal Ford, Kiến trúc phần mềm, ThoughtWorksTóm tắt: Hầu hết các nhà phát triển nghĩ rằng phần mang lại lợi ích nhất của việcáp dụng phát triển dựa theo thử nghiệm (TDD) là các thử nghiệm. Tuy nhiên, khiđã thực hiện đúng, TDD cải thiện thiết kế tổng thể của mã lệnh của bạn. Bài viếtnày trong loạt bài kiến trúc tiến hóa và thiết kế nổi dần thông qua một ví dụ mởrộng sẽ chỉ ra thiết kế có thể rõ nét dần từ các mối quan tâm nổi lên sau các thửnghiệm như thế nào. Việc thử nghiệm chỉ là hiệu quả phụ của TDD; phần quantrọng là làm thế nào để nó thay đổi mã lệnh của bạn cho tốt hơn.Một trong những biện pháp thực tiễn phổ biến để phát triển nhanh l à TDD. TDD làmột phong cách viết phần mềm có sử dụng các thử nghiệm để giúp bạn hiểu đ ượcbước cuối cùng của pha xác định các yêu cầu. Bạn viết các thử nghiệm trước khibạn viết mã lệnh, củng cố thêm hiểu biết của bạn về những cái mà mã lệnh phảilàm.Hầu hết các nhà phát triển cho rằng lợi ích hàng đầu thu được từ TDD là tập hợptoàn diện các thử nghiệm đơn vị mà bạn nhận được. Tuy nhiên, khi thực hiệnđúng, TDD có thể thay đổi thiết kế tổng thể của mã lệnh của bạn thành tốt hơn bởivì nó trì hoãn các quyết định cho đến thời điểm hợp lý cuối cùng. Bởi vì bạnkhông thực hiện các quyết định thiết kế từ trước, nó bỏ ngỏ cho bạn các tùy chọnthiết kế tốt hơn hoặc cấu trúc lại để thiết kế tốt hơn. Bài viết này đi từng bướcthông qua một ví dụ để minh họa sức mạnh của việc cho phép thiết kế nổi r õ lên từcác quyết định xung quanh các thử nghiệm đơn vị.Về loạt bài viết nàyLoạt bài này nhằm mục đích cung cấp một cách nhìn mới mẻ về các khái niệmthường được bàn luận nhưng khó nắm bắt ý nghĩa của thiết kế và kiến trúc phầnmềm. Thông qua các ví dụ cụ thể, Neal Ford sẽ mang lại cho bạn một nền móngvững chắc về các biện pháp thực hành nhanh kiến trúc tiến hóa và thiết kế nổi dần.Bằng cách lùi các quyết định thiết kế và kiến trúc quan trọng đến thời điểm hợp lýcuối cùng, bạn có thể ngăn ngừa không cho những sự phức tạp không cần thiếthủy hoại các dự án phần mềm của bạn.Luồng công việc của TDDMột từ quan trọng trong thuật ngữ phát triển dựa theo thử nghiệm là dựa theo, báohiệu rằng việc thử nghiệm điều khiển quá trình phát triển. Hình 1 cho thấy luồngcông việc của TDD:Hình 1. Luồng công việc của TDDLuồng công việc trong hình 1 là: 1. Viết một thử nghiệm không thành công. 2. Viết mã lệnh để làm cho nó thông qua. 3. Lặp lại các bước 1 và 2. 4. Đồng thời cấu trúc lại quyết liệt. 5. Khi bạn không thể nghĩ đến bất kỳ thử nghiệm nào thêm nữa, bạn đã xong việc.Dựa theo thử nghiệm so với thử nghiệm sauViệc phát triển - dựa theo thử nghiệm yêu cầu các thử nghiệm xuất hiện trước. Chỉsau khi bạn đã viết các thử nghiệm (và thất bại) bạn mới viết mã lệnh được thửnghiệm. Nhiều nhà phát triển sử dụng một biến thể cách làm thử nghiệm được gọilà phát triển thử nghiệm sau (TAD), ở đó bạn viết mã lệnh và sau đó viết các thửnghiệm đơn vị. Trong trường hợp này, bạn vẫn nhận được các thử nghiệm, nhưngbạn không nhận được các khía cạnh thiết kế nổi dần của TDD. Chẳng có gì ngăncản bạn viết mã lệnh cực kỳ ghớm guốc và sau đó lúng túng tìm cách để thửnghiệm nó như thế nào. Khi viết mã lệnh trước, bạn đã nhúng các định kiến củabạn về cách thức mã sẽ hoạt động ra sao, sau đó thử nghiệm nó. TDD đòi hỏi bạnphải làm ngược lại: viết các thử nghiệm trước và cho phép nó thông báo cho bạncách làm thế nào để viết mã lệnh làm cho thử nghiệm thông qua. Để minh họa sựkhác biệt quan trọng này, tôi sẽ bắt đầu một ví dụ mở rộng.Các số hoàn hảoĐể cho thấy các lợi ích thiết kế của TDD, tôi cần một bài toán để giải quyết. Trongcuốn sách Phát triển dựa theo thử nghiệm của mình (xem Tài nguyên), Kent Becksử dụng tiền tệ làm một ví dụ — một sự minh họa khá tốt về TDD, nhưng hơi đơngiản thái quá. Thách thức thực sự là phải tìm ra một ví dụ không phức tạp đến mứcmà bạn bị lạc lối trong lĩnh vực của bài toán nhưng đủ phức tạp để cho thấy giá trịthực sự.Vì mục đích ấy, tôi đã chọn các số hoàn hảo. Đối với những bạn không theo dõichuyện tầm phào toán học, khái niệm này có nguồn gốc từ trước Euclid (người đãthực hiện một trong các chứng minh sớm nhất về việc tìm ra các số hoàn hảo).Một số hoàn hảo là một số mà bằng tổng của các thừa số của nó. Ví dụ, 6 là một sốhoàn hảo bởi vì các thừa số của 6 (trừ chính số 6) là 1, 2 và 3 và 1 + 2 + 3 = 6.Một định nghĩa nhiều tính thuật toán hơn cho một số hoàn hảo là một số mà tổngcác thừa số (trừ chính số đó) bằng chính số đó. Trong ví dụ của tôi, phép tính là 1+ 2 + 3 +6 - 6 = 6.Và đây là lĩnh vực bài toán cần giải quyết: tạo ra một trình tìm ...