BDD có rẻ hơn không?
Testing
24
Software Engineering
36
White

Ngoc Dao viết ngày 22/03/2016

Hỏi

Đây là câu thường được hỏi. Tình huống thế này: Tôi vừa thảo luận với sếp, công ty chuyên làm web bằng Rails. Ông hoài nghi việc dùng BDD cho tất cả project, thường dùng câu "Còn tuỳ project nữa" để chống chế. "Project ngắn quá, nếu bỏ thời gian cho test thì không bù được chi phí". Ông nhấn mạnh viết test sẽ tốn thêm tiền vì phải viết 2 lần: viết test trước, rồi mới viết code.

Theo kinh nghiệm thực tế thì có thật thế không? BDD có đắt hơn không? Biết nhiều người sẽ trả lời "Không, vì test sẽ giúp đỡ nhức đầu về sau", nên xin nhấn mạnh câu hỏi là BDD với RSpec có làm project tốn kém thêm ở giai đoạn thực hiện, và có bao nhiêu phần đúng trong câu nói BDD không dành cho tất cả project?

Đáp

Ngưỡng của tôi là 100 dòng. Đoạn code trên 100 dòng thường tốn công hơn nếu test thủ công, nên tôi sẽ viết test tự động. Theo kinh nghiệm thì với đoạn code nhiều hơn 100 dòng, project sẽ chậm nếu không dùng TDD/BDD.

Đây là vấn đề của CTO. Lúc đầu nó SẼ làm chậm việc phát triển với project nhỏ mà không phức tạp. Nhưng với project trung bình trở lên BDD làm giảm rất nhiều chi phí bảo trì và thêm tính năng. Do đó, nếu làm theo hợp đồng, xong hợp đồng thì bye bye mà không phải bảo trì hoặc thêm tính năng, thì nên tính kĩ. Nhưng nếu tôi là khách hàng của bạn thì tôi sẽ chẳng quay lại nhờ bạn làm thêm project nào nữa nếu bị chơi kiểu này. Nếu được thuê để xây và bảo trì, thì tôi chẳng thấy hại gì nếu dùng BDD.

Tôi nghĩ còn tuỳ vào loại project và kinh nghiệm của lập trình viên về loại đó, BDD và kinh nghiệm dùng BDD vào loại đó. Nghĩa là, không phải là không công bằng khi tổng quát hoá là những việc đơn giản và ngắn có thể thực hiện nhanh hơn mà không cần test. Viết prototype, viết chương trình để thử nghiệm công nghệ mới (xây để học) là lúc BDD làm chậm tiến độ. Sau khi làm xong prototype hoặc thử nghiệm công nghệ mới xong, bắt tay viết chương trình thật thì tôi sẽ dùng BDD.

Tôi đã vài lần thấy BDD tăng tốc tiến độ project vài lần và giúp bóc tách vấn đề phức tạp thành nhiều vấn đề nhỏ dễ giải quyết hơn. Với project "ngắn hạn", tôi cho là cần đặt câu hỏi project này sẽ sống lâu không, và lập trình viên có đủ kỉ luật để viết test ngay khi nó trở nên phức tạp hay không. Nếu câu trả lời cho câu hỏi sau là không, thì việc viết test trước có vẻ là giải pháp để ngăn thảm hoạ.

Còn cái nữa... bạn hỏi "có làm project tốn kém thêm ở giai đoạn thực hiện". BDD không chỉ nằm ở giai đoạn thực hiện, mà còn nằm ở giai đoạn thiết kế. Tất nhiên tôi có thể làm project nhanh hơn mà không dùng BDD, sau đó test thủ công. Tôi có tự tin là project hoạt động đúng không? Có chứ. Tuy nhiên, nếu ngay từ đầu tôi đã dùng TDD/BDD thì cuối cùng tôi sẽ tự tin hơn về thiết kế. Code dễ test thường đi tay trong tay với thiết kế tốt, trong khi code khó test thường đi kèm với thiết kế bốc mùi. Nghĩa là nếu code xong mới viết test tự động thì việc viết test có nguy cơ rất mất thời gian và tốn kém vì code không được thiết kế tốt nên rất khó test, thường là cần phải refactor nhiều.

BDD, cũng như các practice khác, có hại nếu không áp dụng đúng tình huống. Mà tình huống thì còn tuỳ lập trình viên/team, khó mà định ngưỡng cho tất cả mọi người.

Tất nhiên BDD sẽ làm chậm tiến độ. Hầu hết project đều ngày càng to ra và phức tạp thêm. Nếu bạn được trả tiền để làm và nó không phải là prototype, thì hầu như nó luôn cần spec. Câu hỏi đúng phải là: Project có đáng tiền hay không? Đáng bao tiền?

Nếu chẳng đáng gì cả, thì nó không cần spec. Nếu nó sẽ to ra và không phải do lập trình viên ban đầu bảo trì thì nó cần spec.

Rất nhiều lần tôi phải vội, phải có sản phẩm gì đó, lúc đó tôi không làm spec. Để rồi sau đó chắc chắc sẽ gặp bug, và luôn hối hận là đã không làm spec. Tôi chẳng phải thần thánh gì, nên lặp đi lặp lại sai lầm này suốt. Tuy nhiên với code viết xong chỉ để vứt, thì cũng không cần test là gì, ví dụ code để migrate dữ liệu từ phiên bản cũ lên phiên bản mới. Cho nên thường ta hay nghe câu: "Nếu code dưới X dòng, thì không cần test".

Vấn đề là đo đạc chi phí như thế nào. Nếu bạn đo từ lúc viết dòng code đầu tiên đến lúc viết dòng code cuối cùng, thì vâng, bạn sẽ cho là bỏ test đi sẽ rẻ hơn. Tuy nhiên tôi chẳng đo kiểu này. Lí do là project của tôi đều trải qua nhiều lần release tiếp theo (phiên bản 2 đến N). Nghĩa là, ROI của test trở nên rõ ràng hơn ở những lần release tiếp theo chứ không phải lần đầu, chuyển từ release này sang release sau sẽ ít tốn kém hơn, bởi vì khi có test tự động và thiết kế tốt chống lưng, sẽ dễ dàng thay đổi thêm tính năng hơn.

Kinh nghiệm của tôi là thêm test vào code có sẵn khó hơn là vừa test vừa code. Test tự động giống như kiểm tra 2 lần cái gì đó. Nếu lưỡng lự có nên dùng BDD với project nhỏ hay không, hãy hỏi sếp: "Sếp có bắt kế toán kiểm tra 2 lần khi nhập số tiền nhỏ hay không?"

BDD với RSpec có làm project tốn kém thêm ở giai đoạn thực hiện: BDD thiên về thiết kế hơn là test và RSpec cho phép chạy thiết kế. Nếu điều bạn đang làm là thiết kế trong giai đoạn thực hiện, thì vâng bạn đang lãng phí thời gian. Thời gian không bao giờ lãng phí ở giai đoạn thiết kế spec. Thời gian lãng phí ở chỗ cắm đầu thực hiện mà không thử xem thiết kế có nghĩa và đáng thực hiện hay không.

Có khoa ở trường đại học nọ nhấn mạnh vào thiết kế hoàn chỉnh trước. Họ nhấn mạnh là phải thiết kế hoàn chỉnh bằng UML, rồi từ đó cứ thế thực hiện. Lại là lí do nữa để tôi chẳng bao giờ muốn làm việc trong môi trường nhà nước.

Nguồn: ruby-forum.com

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Ngoc Dao

102 bài viết.
252 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
56 6
Làm thế nào để nâng cấp trang web mà không làm gián đoạn dịch vụ? Đây là câu hỏi phỏng vấn các công ty lớn thường hỏi khi bạn xin vào vị trí làm lậ...
Ngoc Dao viết gần 2 năm trước
56 6
White
32 0
Bài viết này giải thích sự khác khác nhau giữa hai ngành khoa học máy tính (computer science) và kĩ thuật phần mềm (software engineering), hi vọng ...
Ngoc Dao viết gần 2 năm trước
32 0
White
28 1
Nếu là team leader, giám đốc công ty hay tướng chỉ huy quân đội, vấn đề cơ bản bạn gặp phải là “hướng mọi người đi theo con đường bạn chỉ ra”. Thử...
Ngoc Dao viết gần 2 năm trước
28 1
Bài viết liên quan
White
4 0
1. Định nghĩa Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào...
Thiên Hoàng Minh Vũ viết 1 tháng trước
4 0
White
7 2
Khi test tự động có đụng đến DB, thường ta phải tạo rồi xóa DB rất nhiều lần. Do đó nếu lưu DB trên đĩa cứng bình thường thì mỗi lần chạy test phải...
Ngoc Dao viết gần 2 năm trước
7 2
White
5 0
Test framework của RSpec luôn làm tôi bất ngờ với nhiều hàm dường như rất ít được biết đến nhưng khá là hữu dụng. Hôm nay trong khi phỏng vấn một ứ...
Lơi Rệ viết hơn 2 năm trước
5 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
102 bài viết.
252 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!