Bạn đã bao giờ tham gia một nhóm phần mềm trong một thời gian, và sau đó 1 người mới tham gia nhóm và bắt đầu đặt ra những câu hỏi thông thường về lý do tại sao công nghệ hoặc mô hình này hoặc kia được sử dụng trong dự án? Và sau đó vài tháng, một người khác tham gia và tất cả những câu hỏi tương tự lại xuất hiện? Hoặc có thể 1 số thành viên trong nhóm, dù mới hay không, liên tục muốn xem xét lại mọi lựa chọn, có khả năng gây bất lợi cho việc thực sự cung cấp phần mềm hoạt động với các quyết định đã có?
Nếu bạn thấy bất kỳ điều nào trong số này quen thuộc, hãy đọc tiếp để biết 1 kỹ thuật có thể hữu ích mà bạn có thể bắt đầu áp dụng.
Trong bất kỳ dự án phần mềm nào, sẽ có rất nhiều quyết định được đưa ra về cách xây dựng và cung cấp ứng dụng. Một số trong số này bạn thậm chí có thể không nghĩ đến vì chúng chỉ là "cách bạn làm mọi việc" nhưng dù sao chúng cũng là quyết định.
Các ví dụ bao gồm:
Chúng tôi đang xây dựng loại ứng dụng chạy trên nền tảng nào(web, desktop, mobile, embedded, etc...)?
Chúng ta sẽ sử dụng framework(s) nào?
Chúng ta sẽ viết code bằng language(s) nào?
Ứng dụng này sẽ chạy trên OS(s) nào?
Các nhà phát triển của chúng tôi sẽ sử dụng OS(s) nào?
Chúng tôi sẽ sử dụng những công cụ nào để xây dựng và kiểm thử phần mềm?
Chúng tôi sẽ lưu trữ dữ liệu như thế nào?
Các bộ phận khác nhau trong hệ thống của chúng ta sẽ giao tiếp với nhau như thế nào?
Chúng tôi sẽ lưu trữ ứng dụng ở đâu?
Chúng tôi sẽ cung cấp ứng dụng cho người dùng hoặc server như thế nào?
Chúng tôi sẽ sử dụng những pattern nào để duy trì persistence (data mapper, active record..)?
Chúng tôi sẽ thực hiện những loại kiểm thử nào trên hệ thống?
Logging strategy của chúng tôi là gì và chúng tôi sẽ sử dụng những công cụ nào để triển khai nó?
Không hẳn tất cả những điều này đều là quyết định về "kiến trúc" nhưng tất cả đều là ví dụ về các loại quyết định cần đưa ra khi một ứng dụng chuyển từ ý tưởng sang sản phẩm được giao. Một số quyết định được đưa ra dựa trên người xây dựng phần mềm: "Chúng tôi là một shop .NET Core nên chúng tôi đang xây dựng phần mềm này bằng C# trên Windows (và Mac/Linux nếu một số nhà phát triển muốn)." Các quyết định khác có thể yêu cầu cân nhắc các yêu cầu và họp để xác định và chọn giải pháp tốt nhất. Trong trường hợp sau, việc ghi lại quyết định và suy nghĩ đưa ra quyết định là hữu ích nhất.
Một bản ghi quyết định đơn giản
Architecture Decision Record là công cụ để ghi lại quyết định đã được đưa ra (hoặc đang được thảo luận) liên quan đến kiến trúc của một hệ thống hoặc ứng dụng cụ thể. Bạn sẽ tìm thấy nhiều mẫu có sẵn để giúp bạn bắt đầu nhưng nhìn chung khi bạn thấy cần phải đưa ra quyết định, bạn nên nghĩ đến việc ghi lại những điều sau:
Vấn đề bạn đang quyết định là gì (ngắn gọn và rõ ràng)
Bạn đã đưa ra quyết định gì (nếu có)
Trạng thái hiện tại (Đang thảo luận, Đã quyết định, v.v.)
Ai đã tham gia vào quyết định/cuộc thảo luận
Quyết định đã xảy ra khi nào?
Những lựa chọn nào đã được xem xét
Ưu và nhược điểm của các lựa chọn khác nhau là gì?
Tại sao quyết định được đưa ra như vậy?
Hậu quả của quyết định là gì?
Có các ví dụ và liên kết đến nhiều mẫu tại GitHub Architecture Decision Record của Joel Parker Henderson . Có rất nhiều thông tin tuyệt vời ở đó và tôi khuyến khích bạn xem qua. Có các ví dụ đầy đủ ở nhiều định dạng khác nhau cho các quyết định như:
Xin lưu ý rằng đây là những ví dụ về quyết định mà các nhóm khác có thể đưa ra dựa trên hoàn cảnh riêng của họ, chứ không phải là cơ sở để bạn lựa chọn cách giải quyết những vấn đề tương tự trong nhóm hoặc ứng dụng của mình.
Mẫu Decison Record của Michael Nygard cũng là một trong những mẫu được nhiều nhóm áp dụng phổ biến nhất.
Khi nào tôi nên bận tâm đến việc viết ADR?
Nếu bạn đã xem một số tài nguyên mà tôi liên kết ở trên và ngay lập tức nghĩ rằng nó quá nhiều việc, chúng ta hãy nói về thời điểm hợp lý để viết chúng ra. Nếu bạn không mong đợi vấn đề sẽ tái diễn trong tương lai, có lẽ bạn không cần phải viết ADR. Nếu không có quyết định rõ ràng nào được đưa ra, không có cuộc thảo luận nào được thực hiện, bạn chỉ đang tuân theo SOP (Standard Operating Procedure) chưa được viết của nhóm hoặc công ty, thì có lẽ bạn cũng không cần ADR cho việc đó.
Mặt khác, nếu bạn có nhiều chuỗi email dài xen kẽ với các cuộc họp và cuộc gọi để thảo luận về tất cả các lựa chọn với nhiều phe phái khác nhau thúc đẩy cách tiếp cận ưa thích của họ, cuối cùng dẫn đến một quyết định (mà một số bên liên quan có thể chỉ miễn cưỡng chấp nhận), thì việc ghi lại quá trình đó có thể có giá trị. Nếu việc đưa ra quyết định là xứng đáng, thì việc ghi lại những gì đã đi vào quyết định đó sẽ đáng giá để bạn có thể tận dụng thời gian đó một lần nữa trong tương lai.
Lưu trữ hồ sơ quyết định kiến trúc ở đâu?
Thông thường, các bản ghi quyết định về kiến trúc được lưu trữ ở bất kỳ nơi nào lưu trữ tài liệu khác cho nhóm hoặc dự án. Có thể là wiki hoặc có thể là một số loại hệ thống tài liệu. Tốt nhất là sử dụng một hệ thống natively supports versioning. Nếu bạn không có giải pháp tốt hơn, bạn có thể sử dụng git repo và chỉ cần lưu trữ các bản ghi dưới dạng text files (tôi khuyên dùng markdown). Sau đó, bất kỳ thay đổi nào cũng sẽ hiển thị trong version history và có thể yêu cầu các thay đổi mới dưới dạng pull requests để có thể thảo luận phù hợp trước khi áp dụng các thay đổi. Hãy nhớ rằng sau khi đã đưa ra quyết định, lý tưởng nhất là bản ghi đó phải được giữ nguyên không thể thay đổi. Nếu cần đưa ra quyết định mới sau này về cùng một chủ đề, hãy liên kết đến quyết định ban đầu nhưng bắt đầu thảo luận mới trong tệp riêng của quyết định đó.
Bản tóm tắt
Điều quan trọng nhất cần ghi lại trong hồ sơ quyết định này không phải là những gì bạn quyết định làm, mà là những gì bạn đã cân nhắc và quyết định không làm. Bạn muốn có một hồ sơ về các lựa chọn khác đã được cân nhắc, ưu và nhược điểm được nhận thức của chúng là gì và cuối cùng là lý do tại sao chúng không được chọn. Đây là điều bạn và những người khác có thể xem xét lại sau và nếu hoàn cảnh không thay đổi đáng kể, thì quyết định có thể vẫn được giữ nguyên. Nếu có thông tin mới xuất hiện khiến quyết định ban đầu trở nên lỗi thời, thì thông tin đó phải rõ ràng dựa trên thông tin trong hồ sơ.
Nguồn sưu tầm.