Bạn muốn lái thử một số mã, nhưng bạn gặp khó khăn. Có thể bạn không hoàn toàn chắc chắn về giao diện đối tượng của mình trông như thế nào. Có thể bạn đang bị phân tâm bởi một ngày hè đầy nắng khác. Bạn có thể không chắc mình có thể kiểm tra những gì bạn đang nghĩ đến việc xây dựng. Hoặc bạn có thể trì hoãn, bởi vì bạn cảm thấy không thích viết bài kiểm tra ngay bây giờ. Làm cách nào để bạn nhận được những lợi ích của TDD khi bạn cảm thấy không thích TDDing?
Tạo mẫu hoặc xây dựng một cái để vứt bỏ
“Khi một khái niệm hệ thống mới hoặc công nghệ mới được sử dụng, người ta phải xây dựng một hệ thống để loại bỏ, vì ngay cả việc lập kế hoạch tốt nhất cũng không phải là toàn trí để có được nó ngay lần đầu tiên. Do đó, hãy lên kế hoạch vứt bỏ một cái đi; dù sao thì bạn cũng sẽ làm được. ” - Fred Brooks
Đôi khi, khi tôi bắt đầu một tính năng mới, tôi sẽ cảm thấy tê liệt khi nghĩ về việc viết các bài kiểm tra đầu tiên của mình. Có rất nhiều quyết định phải đưa ra về cách API sẽ trông như thế nào, các mẫu và thực hành nào sẽ phù hợp nhất và tất cả chúng phải phù hợp với nhau như thế nào.
Tôi có một số cách để bắt đầu khi tôi gặp khó khăn như vậy. Xây dựng nguyên mẫu là một việc khác.
Khi bạn viết một nguyên mẫu, bạn nên nghĩ về nó giống như một bản phác thảo. Động não và thử mọi thứ. Đừng bận tâm với các bài kiểm tra hoặc TDD. Thay vào đó, hãy khám phá những quyết định bạn đang gặp khó khăn bằng mã. Hãy thử một vài mẫu và xem mẫu nào phù hợp với tính năng bạn đang cố gắng thiết kế. Tìm ra vị trí của các phần bị rung trong ứng dụng của bạn, điều gì cần suy nghĩ thêm và điều gì bạn đang lo lắng mà không có lý do thực sự.
Sau đó, vứt bỏ và xây dựng lại. Lần này, sử dụng TDD và kiến thức mới tìm thấy của bạn về cách bạn có thể xây dựng tính năng tốt nhất.
Bạn biết khi bạn vô tình chạy git checkout -f sau khi bạn viết một cái gì đó, và bạn có cảm giác như vừa bị đá vào bụng? Nhưng sau đó bạn hình dung, điều này phải được xây dựng, vì vậy tôi đoán tôi sẽ làm lại, và nó hóa ra tốt hơn nhiều so với lần đầu tiên? Điều này cũng đúng với việc xây dựng lại nguyên mẫu. Bây giờ bạn đã có một số ý tưởng vững chắc về cách tính năng có thể nhìn này, TDDing tính năng đó sẽ hoạt động dễ dàng hơn rất nhiều.
TDD đảo ngược
Bạn đã bao giờ gặp phải tình huống mà bạn biết cách xây dựng một thứ gì đó, nhưng bạn lại không biết cách viết các bài kiểm tra cho nó trước chưa? Hoặc có thể đó là một thay đổi một dòng đối với một phương pháp, nhưng nó có thể cần một số điều chỉnh, vì vậy bạn không muốn khóa nó lại bằng một bài kiểm tra trước khi bạn biết thay đổi thực sự sẽ như thế nào?
Có một quy trình đơn giản giúp ích rất nhiều cho những tình huống này:
- Viết mã mà không cần kiểm tra.
- Viết một bài kiểm tra cho mã. Đảm bảo rằng nó vượt qua.
- Nhận xét mã bạn đã viết hoặc hoàn nguyên tệp mà bạn đã thực hiện thay đổi mã.
- Chạy thử nghiệm lại. Đảm bảo rằng nó không thành công.
- Viết lại mã. Chạy thử nghiệm của bạn. Đảm bảo rằng họ vượt qua.
- Cấu trúc lại mã , tận dụng các thử nghiệm mới của bạn.
Tôi nghĩ đây là TDD ngược hoặc Green-Red-Green-Refactor. Bạn sẽ không nhận được phần “thiết kế hướng thử nghiệm” của TDD, nhưng bạn vẫn sẽ thấy các thử nghiệm của mình không thành công khi mã của bạn bị hỏng. Điều đó quan trọng, vì bạn không thể tin tưởng vào các bài kiểm tra không thất bại ít nhất một lần.
TDD ngược thường hoạt động tốt nhất với những thay đổi nhỏ không cần thiết kế nhiều. Hãy nghĩ đến các bản sửa lỗi hoặc các thay đổi được bản địa hóa cho một dòng, phương thức hoặc lớp. Nhưng tôi sử dụng kỹ thuật này rất nhiều, đặc biệt là đối với những thay đổi nhỏ mà tôi vẫn đang thực hiện.
Trò chơi Ghép đôi
Trò chơi Ghép nối là một cách tuyệt vời để thoát ra khỏi thói quen Red-Green-Refactor của bạn khi bạn có một nhà phát triển khác xung quanh. Nó hoạt động như thế này:
- Tìm một đối tác.
- Bạn viết một bài kiểm tra sẽ bị hỏng.
- Đối tác của bạn cố gắng khắc phục bài kiểm tra đó bằng mã đơn giản nhất có thể.
- Bạn viết một bài kiểm tra khác sẽ không thành công trên mã đó.
- Đối tác của bạn viết mã sẽ vượt qua bài kiểm tra đó.
- Lặp lại…
- Tại một số thời điểm khi các bài kiểm tra có màu xanh lục, bạn có thể chọn cấu trúc lại một số mã thay vì viết một bài kiểm tra.
- Sau khi cấu trúc lại, hãy hoán đổi vị trí của người kiểm tra và người viết mã.
Tôi sẽ cho bạn biết một bí mật:chơi Trò chơi ghép đôi trên máy tính điểm bowling là cách tôi học TDD ban đầu. Nó sẽ giúp bạn thực hành viết mã đơn giản dựa trên các bài kiểm tra không đạt và viết các bài kiểm tra đó để bắt đầu. Cả hai nhà phát triển sẽ tìm hiểu rất nhiều về phong cách viết mã và các kỹ thuật yêu thích của nhau. Và bạn sẽ đạt được dòng chảy gần như ngay lập tức, có nghĩa là bạn sẽ cảm thấy tuyệt vời khi hoàn thành.
Bạn có thể không tạo ra mã nhanh chóng, nhưng nó rất thú vị và một trải nghiệm học tập tuyệt vời.
Hãy vui vẻ và thử nghiệm
TDD không nên giáo điều. Có nhiều cách bạn có thể chơi với các khái niệm TDD cốt lõi có thể dẫn bạn đến một số địa điểm thực sự thú vị. Và bạn có thể nhận được mã tốt hơn nữa.
Vì vậy, hãy thử nghiệm. Thử các cách tiếp cận mới để viết mã và TDD. Xem cách họ làm cho bạn cảm thấy và loại mã bạn kết thúc. Và tiếp tục khám phá lại niềm vui và dòng chảy trong công việc bạn làm mỗi ngày.