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

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à viết một đặc tả 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.

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 .

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.

Cam kết thiết kế & ADR

Được rồi, chúng tôi đã xác định các yêu cầu kỹ thuật và thu thập yêu cầu từ các nhóm khác . Cái gì tiếp theo?

Ở giai đoạn này, cần hoàn thiện thiết kế hệ thống 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 ADR .

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 ADR 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.

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) hiểu đượ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ọ.

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.

Một điểm quan trọ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.

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 không phải trên cơ sở mã đượ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 cơ sở thiết kế bao gồm các kịch bản quan trọng mà phải được xử lý chính xác . 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.

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 thiết kế , viết mã và thông số kỹ thuật cũng như biên soạn kế hoạch thử nghiệm . Nghe có vẻ khá chắc chắn rồi! Nhưng chúng ta có thể thêm gì nữa?

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 để cải thiện hệ số xe buý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ó.

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 ủy quyền hoàn toàn 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.

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ể cải thiện đáng kể yếu tố xe buýt và tránh sự phụ thuộc vào các cá nhân cụ thể. Đó không phải là điều chúng ta muốn sao?

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 có thể chính là mã , 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.

Tài liệu bao gồm RFC (Yêu cầu nhận xét), ADR (Bản ghi kiến trúc), Thông số kỹ thuật , Kế hoạch kiểm tra , Kế hoạch triển khai , v.v. Điều này sẽ đảm bảo việc lưu giữ kiến thức trong nhóm , đơn giản hóa quá trình tích hợp nhân viên mới vào dự án và 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 .