Tài liệu giới thiệu về các phương pháp phát triển phần mềm như BDD (Behavior Driven Development), Agile và Waterfall, nêu rõ các ưu điểm và ứng dụng của từng phương pháp. Agile cho phép phản hồi nhanh chóng và linh hoạt với yêu cầu của khách hàng, trong khi Waterfall thường cứng nhắc và khó điều chỉnh. BDD kết hợp việc xác định yêu cầu và kiểm tra mã, giúp đảm bảo sản phẩm cuối cùng đáp ứng đúng nhu cầu của khách.

1. Nhập môn BDD Waterfall Agile TDD BDD Đào Thanh Ngọc

2. Q: Tại sao con gà băng qua đường? À quên tại sao lập trình viên lại viết chương trình? A: Để thoả mãn yêu cầu của khách hàng. Q: Chương trình cần có test, test để làm gì? A: Để kiểm tra xem mã do lập trình viên tạo ra có lỗi hay không. Q: Lập trình viên các bác chỉ được cái quanh co. Sao không kiểm tra thẳng xem chương trình có thoả mãn nhu cầu của khách hàng hay không? A: À, cái đó gọi là BDD!

3. Phương pháp phát triển phần mềm Để thanh toán project, qui trình luôn gồm 5 phần: phân tích yêu cầu, thiết kế, viết chương trình, kiểm tra, bảo trì Không nhất thiết phải theo đúng thứ tự + 1 phần có thể đi qua nhiều lần Tùy cách sắp xếp các phần mà cho ra phương pháp phát triển phần mềm khác nhau (← cũng là đi bộ, nhưng sắp xếp thứ tự bước đi theo kiểu Đoàn Dự thì thành ra Bát Bộ?)‏

4. Waterfall Là phương pháp phát triển phần mềm cổ truyền, “hạ sách” (← sách lược default, không nghĩ ra cách gì khác thì sẽ dùng sách này)‏ Là cách đánh tổng lực kiểu con nhà giàu, dàn hàng ngang mà càn quét toàn bộ chiến trường www.relativitycorp.com

5. Agile Là cách đánh du kích, tiết kiệm từng viên đạn, tính toán từng cân lương thực Thanh toán từng phần nhỏ của chiến trường Thanh toán 1 lần chưa thỏa mãn yêu cầu thì lặp lại -> vòng xoắn ốc Vòng xoắn ốc của Mác: sự vật hiện tượng phát triển theo hình xoắn ốc, đến một lúc nào đó sẽ quay lại hình thức cũ nhưng ở cấp độ cao hơn

6. google: “xoắn ốc” Mác Dân nhậu sau thời gian hiến gan và bao tử cho rượu Tây, bia lon thì nay tìm về rượu nấu, rượu ngâm, rượu dân tộc (tắc kè, bổ củi, chuối hột...)‏ Giờ mà ăn bò nhúng dấm, gà quay, vịt luột, cá hấp… thì tầm thường quá. Trở về chơi lại dế chiên bột, đuông dừa, gà ăn mày, cá kèo nướng, cá lóc nướng trui… Đi du lịch thì chán chê Vũng Tàu Đà Lạt giờ chỉ khoái về quê tát đìa bắt cá, hun chuột đồng, tắm sông hay hái trái cây

7. Agile www.woods-info.co.jp

8. Agile www.rallydev.com

9. Waterfall VS Agile Còn đang tranh luận: project lớn (← thế nào là lớn?) nên dùng waterfall, nhỏ nên dùng agile? Watefall: bản chất là tĩnh, khó đáp ứng thay đổi yêu cầu của khách (← Có project nào mà khách không đổi ý? Project càng lớn thì càng kí hợp đồng sao cho không cho khách đổi ý miễn phí!), lấy thịt đè người Agile: vì bản chất đã động nên khách “thích thì chiều”, chỉ cần dùng team nhỏ nhưng gồm tinh binh (senior developer) có responsetiveness (phản ứng với phản hồi từ khách) cao

10. Waterfall VS Agile behaviour-driven.org

11. Lợi ích của Agile Early Return on Investment: thấy thành quả của project ngay do cứ vài ngày lại có small release, giảm thiểu được risk vì nếu có gì sai sót thì sửa được sớm Increased Control: đo được ngay mức độ hiệu quả của công việc, thấy tiến triển chậm thì chuyển hướng ngay Responsiveness to Change: team được trang bị lí thuyết và công cụ để đối phó với thay đổi

12. Agile và offshore Agile cung cấp nhiều mẹo (practices)‏ Mẹo khó dùng cho offshore: khách và lập trình viên ngồi chung phòng (← giải quyết phần nào bằng BSE)‏ Mẹo dùng được: TDD/BDD, dùng nhóm nhỏ tinh binh, small automated integrated release...

13. Agile và test Test tự động là yếu tố sống còn của agile, trong vòng xoắn ốc luôn phải có test! Lí do: để có thể tự tin sửa mã chương trình, đảm bảo sau khi thay đổi nếu phát sinh bug thì phát hiện và sửa được ngay, phải có test tự động!

14. TDD, BDD là gì? Cộng sản Cuba Trung Quốc Việt Nam ... Agile TDD (Test Driven Development)‏ BDD (Behavior Driven Development)‏ ... Ý tưởng (tập hợp rất nhiều mẹo vặt)‏ Thực hiện cụ thể (thực hiện tập hợp con các mẹo vặt)‏

15. TDD = BDD Một cách chặt chẽ: 2 cái là 1 Là design hơn là test, test chỉ là hệ quả (hiểu lầm thường gặp: TDD = BDD = test first)‏ Design process Requirements Capturing Behavior Specification Regression Test Suite

16. TDD = BDD (1) Đối với từng phần của chương trình, thay vì bộp cái coding chi tiết ngay, tạo khung trước (ví dụ: chỉ viết tên hàm, thân hàm bỏ trống)‏ (2) Viết test cho khung này một cách khá đầy đủ xong (3) Rồi mới đắp dần dần mã vào khung sao cho pass lần lượt tất cả test -> (1) và (2) có tác dụng phân tích yêu cầu và thiết kế chương trình

17. TDD VS BDD Một cách thiếu chặt chẽ: BDD = functional test = interface/specification test = lôi tất cả yêu cầu của khách ra để thử nghiệm TDD = unit test = implementation test = lôi tất cả method của tất cả class (= unit) ra để thử nghiệm Unit test Functional test

18. TDD VS BDD BDD là cách diễn đạt dễ hiểu hơn TDD (“lựa lời mà nói cho vừa lòng nhau”)‏: TDD = assert, BDD = should TDD = viết test để test mã chạy có đúng không, BDD = viết test để (1) nêu ra requirement và (2) test mã có thực hiện đúng requirement không Ở (2)‏ TDD: nhìn test thấy code (← LTV tự sướng)‏ BDD: nhìn test thấy yêu cầu (← thỏa mãn khách)‏ TDD = verification, BDD = specification

19. Vấn đề của TDD Lập trình viên cằn nhằn: Có chút xíu mã, viết test làm quách gì? Cấp quản lí cằn nhằn: Viết trước thành ra viết thừa, phí thời gian? -> Nguồn gốc vấn đề: Dễ gây nhầm lẫn giữa test first và test driven, không nói rõ mục đích TDD là để design hơn là test Thiếu tính chỉ dẫn (intuitive, ← D thứ 1)‏

20. Vấn đề của TDD Tính chỉ dẫn: Bắt đầu từ đâu? Cần test cái gì? Không cần test cái gì? Trong 1 test, cần test những gì? Đặt tên test là gì?

21. BDD giải quyết vấn đề của TDD Làm rõ mục đích: TDD/BDD = spec first (design, documentation), chứ không phải test first‏ (verification)‏ Test = specification = kết quả của phân tích yêu cầu, định nghĩa chương trình phải đáp ứng những yêu cầu gì ~ thiết kế Bao giờ cũng phải phân tích nhu cầu trước -> BDD đến một cách tự nhiên ngay từ giai đoạn đầu của project Có tính chỉ dẫn (học thực hành cụ thể sẽ rõ)‏

22. Lợi ích của BDD Các lợi ích của Agile 1 phát 2 chim (requirement specification + code verification)‏: có spec rõ ràng thì viết mã được ngay, mã viết xong khỏi test (vì đã viết xong test!)‏ Nương theo yêu cầu của khách để viết test, nên không test thừa (như TDD) hay thiếu Qui trình phát triển (← D thứ 2, level của công ty xác định bởi cái này) hình thành một cách tự nhiên, xuất phát từ nhu cầu (← D thứ 1)‏

23. Lợi ích của BDD Business Q: Are we building the right product? A: Executable specifications Technology Q: Are we building the product right? A: Automated tests