Phát triển theo README (2010)
(tom.preston-werner.com)- Phát triển theo README: một cách tiếp cận viết README trước khi phát triển phần mềm
- Chúng ta thường nghe nhiều về các phương pháp và kỹ thuật phát triển như TDD, BDD, Extreme Programming, SCRUM, v.v.
- Nhưng nếu phần mềm chúng ta phát triển không đáp ứng được nhu cầu của người dùng thì mọi thứ đều vô nghĩa
- Ngay cả một bản triển khai hoàn hảo cũng vô giá trị nếu nó tuân theo một đặc tả sai, và một thư viện tuyệt đẹp nhưng không được tài liệu hóa cũng gần như vô giá trị
- Nếu phần mềm giải quyết sai vấn đề hoặc người dùng không biết cách sử dụng thì sẽ phát sinh vấn đề nghiêm trọng
Giải pháp: Viết README trước
- Vì sao phải viết README trước
- Hãy viết README trước cả khi viết code, test hay story
- Việc viết README là một bước thiết yếu để tạo ra phần mềm tốt
- Trước khi viết thành lời về phần mềm, bạn chưa thể thật sự rõ mình sẽ code gì
- README giúp bạn suy nghĩ về dự án một cách có hệ thống
- Lợi ích của việc ưu tiên README:
- Cơ hội suy nghĩ có hệ thống về dự án:
- Có thể suy nghĩ về dự án một cách có hệ thống mà không cần thay đổi code
- Có thể cân nhắc cấu trúc của dự án và API sẽ được đưa vào trước khi bắt đầu code
- Có được tài liệu chất lượng cao:
- Có thể viết tài liệu ngay từ giai đoạn đầu của dự án khi động lực và hứng thú còn cao
- Viết README về sau sẽ nhàm chán và dễ bỏ sót những chi tiết quan trọng
- Tăng hiệu quả làm việc nhóm:
- Các lập trình viên khác trong nhóm có thể chia sẻ thông tin về interface trước khi dự án hoàn thành để tự tin bắt đầu các phần việc khác
- Nếu làm việc mà không có interface rõ ràng, có thể sẽ cần tái cấu trúc một lượng lớn code
- Tạo nền tảng cho thảo luận cụ thể:
- Chỉ với hành động đơn giản là viết giải pháp được đề xuất dưới dạng văn bản, mọi người đã có thể thảo luận với ý tưởng rõ ràng
- Cơ hội suy nghĩ có hệ thống về dự án:
- Đặc điểm của phát triển theo README (RDD):
- Có thể xem RDD là một tập con hoặc phiên bản giới hạn của Documentation Driven Development (DDD)
- RDD giới hạn tài liệu thiết kế trong một tệp duy nhất để tránh vấn đề viết đặc tả quá mức
- Khuyến khích duy trì các thư viện nhỏ và được mô-đun hóa
Kết luận
- Hãy xem quá trình viết README là một "hành vi sáng tạo" thực sự
- Mọi ý tưởng độc đáo của bạn nên được thể hiện trong tài liệu này, và bản thân tài liệu phải trở thành bằng chứng chứng minh tính sáng tạo và khả năng biểu đạt
- README nên là tài liệu quan trọng nhất trong codebase, và việc viết nó đầu tiên là cách tiếp cận đúng đắn
9 bình luận
Dù là phần mềm, tiểu thuyết hay phim ảnh, khi tạo ra bất kỳ dạng tác phẩm nào, nếu vừa lên ý tưởng và thiết kế trên giấy trước khi bắt tay vào làm
thì có lẽ sẽ dễ chăm chút những chi tiết cụ thể hơn.. :)
Đã lâu rồi tôi quên mất điều cơ bản nhất, giờ phải bắt tay vào thực hành thôi.
Chúng tôi quyết định gọi nó là "thiết kế cơ bản".
Có vẻ vô tình khá giống với cách làm việc và bối cảnh công việc của tôi.
Có lẽ phần đó được tạo ra dưới dạng
README.Khi làm việc, tôi thường viết rõ ràng What, Why, How rồi vừa tiến hành vừa định hình khuôn dạng của những việc cần làm, nên khá giống với điều này.
Phát triển theo định hướng README
Bên tôi là một tổ chức nghiên cứu nên đã có khá nhiều trăn trở về việc phát hành các kết quả nghiên cứu dưới dạng mã nguồn, và tôi nghĩ phát triển theo hướng README có lẽ sẽ rất phù hợp với chúng tôi. Có vẻ đây là một cách làm đáng để cân nhắc ngay từ giai đoạn bắt đầu nghiên cứu.
Tương tự như vậy, khi làm backend tôi cũng thường nhìn vào giao diện rồi phác thảo tài liệu API trước,
việc đó đã giúp giảm khá nhiều lần thử sai.
Nghĩ kỹ thì có cảm giác như đây là tầm quan trọng của việc trước hết phải xác định thật chính xác vấn đề cần giải quyết.
Đây là một bài viết từ năm 2010, tôi tình cờ thấy khi đọc bài khác nên đăng lại lên đây.