Tại sao chúng ta lại cần bất kỳ tài liệu nào trong quá trình phát triển? Điều gì về tuyên bố này rằng ? chính tài liệu mã Hãy xem xét kịch bản phổ biến nhất: mã của hệ thống (có thể là chương trình, dự án hoặc sản phẩm) được viết trong một thời gian dài và nhóm dần dần thay đổi trong quá trình này, mang theo những kiến thức nhất định về hệ thống khi các nhà phát triển rời đi. Chúng ta có thể làm gì trong trường hợp như vậy? Câu trả lời đơn giản nhất là nắm bắt tất cả các chi tiết triển khai để đảm bảo hệ thống đáp ứng các yêu cầu ban đầu. viết một đặc tả Tuy nhiên, một tài liệu như vậy rất khó viết trước và trong quá trình phát triển, một số chi tiết triển khai có thể thay đổi (thích ứng với thị trường/yêu cầu mới về cơ khí, v.v.). Vậy chúng ta có thể nghĩ ra điều gì để cải thiện ? hệ số xe buýt Hãy thử đi theo một quy trình có thể là một trong những giải pháp khả thi để giải quyết vấn đề nêu trên. Yêu cầu & RFC Đầu tiên, chúng ta cần mô tả thiết kế ban đầu dựa trên yêu cầu từ các bên liên quan và ghi lại nó. Sau đó, tài liệu này có thể được chia sẻ với các nhóm khác và yêu cầu phản hồi của họ: yêu cầu triển khai một số tính năng nhất định, nhận xét về thiết kế ban đầu, sửa một giao diện nhất định, v.v. Tài liệu như vậy có thể được gọi là . RFC hay "Yêu cầu nhận xét" là tài liệu được phân phối giữa các bên quan tâm—bao gồm nhà phát triển, kiến trúc sư và các nhóm khác—để thu thập phản hồi, nhận xét và đề xuất. Nó ít chi tiết hơn một bản đặc tả và chỉ bao gồm miền vấn đề, nhiệm vụ và giải pháp ban đầu. Linh hoạt hơn, nó cho phép chủ động chấp nhận những thay đổi trong thiết kế, đảm bảo sự hiểu biết sâu sắc về nhiệm vụ và tạo điều kiện thuận lợi cho việc ra quyết định chu đáo và chất lượng. RFC Cam kết thiết kế & ADR Được rồi, chúng tôi đã và . Cái gì tiếp theo? xác định các yêu cầu kỹ thuật thu thập yêu cầu từ các nhóm khác Ở giai đoạn này, cần và tất cả các chức năng chính mà nó sẽ thực hiện. Vì mục đích này, chúng tôi viết . hoàn thiện thiết kế hệ thống ADR hay "Bản ghi quyết định kiến trúc" là tài liệu ghi lại các quyết định kiến trúc quan trọng được thực hiện trong quá trình phát triển phần mềm. Mỗi mô tả một quyết định kiến trúc cấp cao cụ thể, bối cảnh của nó, các lựa chọn thay thế được xem xét, quyết định được đưa ra và động lực để chọn những chi tiết cụ thể này thay vì những chi tiết khác. ADR ADR Một tài liệu như vậy cho phép mọi thành viên trong nhóm (và cả các nhóm khác) các nguyên tắc và giá trị làm nền tảng cho thiết kế. Nếu một nhà phát triển mới gia nhập nhóm nhiều năm sau đó và hỏi: "Tại sao bạn lại làm theo cách này?", họ có thể được xem tài liệu này để trả lời tất cả các câu hỏi của họ. hiểu được Sự chỉ rõ Bây giờ là lúc viết mã và thông số kỹ thuật của nó. Ở giai đoạn này, chúng tôi nghiên cứu kỹ lưỡng từng tính năng, đồng thời tổng hợp tất cả thông tin và chi tiết triển khai vào một tài liệu đặc biệt. Tài liệu này phải phản ánh các yêu cầu cấp thấp hiện tại đối với hệ thống. : trong vòng đời của phần mềm, thông số kỹ thuật như vậy có thể thay đổi đáng kể và điều đó không sao cả. Tuy nhiên, điều rất quan trọng là vẫn tuân theo thiết kế và kiến trúc ban đầu để ngăn cơ sở mã trở thành thứ gì đó không thể quản lý được. Một điểm quan trọng kế hoạch kiểm tra Tại sao nó lại cần thiết? Điều quan trọng là kế hoạch kiểm thử phải được xây dựng được viết theo đặc tả (chúng tôi viết mã và kiểm tra mã này để chúng vượt qua), mà trên bao gồm các kịch bản quan trọng mà . Cũng rất thuận tiện khi bạn có thể gửi kế hoạch kiểm tra như vậy để các nhóm khác xem xét (để tích hợp hoặc chỉ để kiểm tra bổ sung), làm rõ cách hệ thống sẽ hoạt động trong các tình huống khác nhau. không phải trên cơ sở mã cơ sở thiết kế phải được xử lý chính xác Nó bao gồm những gì? Tất cả các kịch bản vận hành hệ thống có thể xảy ra Con đường hạnh phúc Con đường buồn Xử lý lỗi Tất cả các bất biến có thể phải được duy trì trong quá trình vận hành hệ thống Kiểm tra chấp nhận để kiểm tra trạng thái hệ thống khi bắt đầu (nên xem xét môi trường, ví dụ: dữ liệu trên mạng) Chúng tôi đã hoàn thiện , viết mã và cũng như biên soạn . Nghe có vẻ khá chắc chắn rồi! Nhưng chúng ta có thể thêm gì nữa? thiết kế thông số kỹ thuật kế hoạch thử nghiệm Kế hoạch triển khai Ở một mức độ nào đó, một kế hoạch như vậy có thể cần thiết để và tạo điều kiện để bất kỳ thành viên nào trong nhóm có thể triển khai hệ thống và xác minh trạng thái của nó. cải thiện hệ số xe buýt Tại sao chúng ta không thể làm mà không có nó? Chúng ta có thể, nhưng trong thế giới thực, các nhóm lớn nơi nhiều người chịu trách nhiệm về các phần khác nhau của hệ thống và quá trình triển khai có thể được cho DevOps. Điều đó có vấn đề gì, vì chúng ta đã viết các bài kiểm tra, đưa chúng vào CI và kiểm tra các lỗ hổng, chúng ta có cần thêm gì nữa không? Có thể là không, nhưng thường các bài kiểm tra không xem xét trạng thái hiện tại của hệ thống và kiểm tra không hoàn toàn như những gì chúng ta mong muốn. ủy quyền hoàn toàn Kế hoạch triển khai nào : có thể chứa Mô tả đầy đủ các hành động cần được thực hiện để triển khai diễn ra Các thông số triển khai: Biến môi trường Trạng thái ban đầu Các thông số khởi động Một kế hoạch nếu có sự cố xảy ra ở bất kỳ bước nào Một kế hoạch dự phòng, nếu có thể Trạng thái cần thiết mà hệ thống phải đạt được trong trường hợp không thể tiếp tục triển khai Các hành động cần thực hiện sau khi triển khai Thông báo cho các đội khác Kích hoạt tích hợp cần thiết, nếu cần Không có gì phức tạp phải không? Việc có một tài liệu như vậy cho một bản cập nhật cụ thể có thể và vào các cá nhân cụ thể. Đó không phải là điều chúng ta muốn sao? cải thiện đáng kể yếu tố xe buýt tránh sự phụ thuộc Phần kết luận Trong quá trình phát triển phần mềm, điều quan trọng không chỉ là viết mã mà còn phải tạo tài liệu đảm bảo sự hiểu biết và nhất quán trong tất cả các giai đoạn phát triển. Tài liệu , nhưng kinh nghiệm đã chỉ ra rằng tài liệu rất quan trọng để duy trì chất lượng, tính ổn định và khả năng mở rộng trong tương lai của hệ thống, đặc biệt là khi nhóm thay đổi trong quá trình phát triển cũng như khi dự án phát triển và thích ứng với các yêu cầu mới. có thể chính là mã Tài liệu bao gồm (Yêu cầu nhận xét), (Bản ghi kiến trúc), , , , v.v. Điều này sẽ đảm bảo việc , đơn giản hóa quá trình vào dự án và . RFC ADR Thông số kỹ thuật Kế hoạch kiểm tra Kế hoạch triển khai lưu giữ kiến thức trong nhóm tích hợp nhân viên mới tăng độ tin cậy tổng thể cũng như khả năng chống lại những thay đổi của hệ thống

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Making security fun one episode at a time

Bạn biết gì về phát triển dựa trên tài liệu?

dài quá đọc không nổi

Roman Kolpakov

STORY’S CREDIBILITY

Guide

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

Bạn biết gì về phát triển dựa trên tài liệu?

dài quá đọc không nổi

Roman Kolpakov

STORY’S CREDIBILITY

Guide

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

NHỮNG BÀI VIẾT LIÊN QUAN