Tôi đang bị lung lay về lối nghĩ.
Tôi cho rằng nghiệp vụ là quan trọng và cần hướng cả thẩy về suy nghĩ này; từ các công việc liên quan như nhận yêu cầu, thiết kế và lập trình. Tôi tìm kiếm những phương pháp hỗ trợ cho lối nghĩ này.
Tuy nhiên, tôi ngày càng thấy đa số không theo lối nghĩ này và thường tiếp cận theo hướng GUI. Có thể nó là tự nhiên. Và nên tìm cách vận dụng nó. Bởi vì engineering là thứ có qui củ hay lối mòn; hay tốt nhất là lắp ráp được.
Tôi đang nghĩ cổ động cho việc mô tả dựa trên các màn hình. Cần có người chuyên biệt về nó.
Một mô hình thoáng trong đầu rằng sau khi thu thập yêu cầu, sẽ là quá trình phân tích tính khả thi, công nghệ v.v... Kết quả là một yêu cầu sáng sủa hơn có thể prototype. Sẽ có người làm về GUI để phác thảo màn hình logic và mô tả chúng. Trao đổi với khách hàng nếu cần thiết. Sau đó sẽ do designer hiện thực và làm cho chúng đẹp.
Các bước trên được lặp hoặc tổ chức sao cho kết quả là tập tài liệu mô tả màn hình hệ thống.
Programmer tiến hành code theo tập tài liệu mô tả màn hình.
QC làm việc dựa vào tập tài liệu mô tả màn hình.
Khi có một thay đổi, sự thay đổi được cụ thể bằng việc modify lại tài liệu mô tả màn hình.
Programmer tiến hành code theo tập tài liệu mô tả màn hình đã chỉnh sửa.
QC làm việc dựa vào tập tài liệu mô tả màn hình đã chỉnh sửa.
Kết quả là: programer lẫn qc có quyền không làm việc nếu không nhận được tập tài liệu mô tả màn hình.
Cách nghĩ này khiến tôi liên tưởng tới một tình huống buồn cười:
- BDD dựa trên lập luận của TDD, chỉ thay đổi một ít về danh xưng.
- RSpec là một hiện thực của BDD cho Ruby.
- Một người theo trường phái TDD nói, đại ý rằng, tôi viết unit test cho mã nguồn ruby theo framework RSpec.
No comments:
Post a Comment