Nghệ thuật System Design: 5 Bước biến ý tưởng sơ khai thành giải pháp kiến trúc vững chắc

Tôi là một kỹ sư phần mềm đã từng làm việc trên nhiều hệ thống, từ những dự án nhỏ đơn giản đến những hệ thống lớn và phức tạp. Tôi đã có cơ hội thiết kế, xây dựng, bảo trì và hỗ trợ các hệ thống đó. Trong những năm tháng kinh nghiệm của mình, tôi nhận ra rằng chất lượng bắt đầu từ ngay giai đoạn thiết kế. Tôi cố gắng tóm tắt kinh nghiệm đó và gửi đến bạn một số lời khuyên, thậm chí là các danh sách kiểm tra (checklist) mà bạn có thể sử dụng trong nhiệm vụ thiết kế tiếp theo của mình. Nội dung này mang tính tổng quát, vì vậy bạn cần điều chỉnh một số bước cho phù hợp với trường hợp sử dụng cụ thể của mình.

Các ý kiến được trình bày hoàn toàn là của riêng tôi và không thể hiện quan điểm hoặc ý kiến của nhà tuyển dụng/công ty tôi đang làm việc.

Bước 0: Xác định Vấn đề (The Problem Statement)

Mọi dự án kỹ thuật thành công đều bắt đầu với một tuyên bố vấn đề được xác định rõ ràng. Mỗi dự án đều khác nhau. Thường có một khoảng cách giữa những gì bạn nghĩ là cần thiết và những gì thực sự cần thiết. Đôi khi, Giám đốc Sản phẩm/Dự án (PM) có thể diễn đạt các yêu cầu đó thành một tài liệu đẹp đẽ. Những lúc khác, bạn sẽ phải tự làm điều đó. Dù trong trường hợp nào, đây là một số việc hữu ích cần làm:

• Đặt thật nhiều câu hỏi. Câu hỏi ngu ngốc duy nhất là câu hỏi bạn không dám hỏi.
• Diễn giải lại và xác nhận. Ít nhất là đối với các phần quan trọng, hãy diễn giải lại yêu cầu bằng lời của bạn và đảm bảo bạn đã hiểu đúng.
• Thực hiện phân tích khả thi.
  • Các PM giỏi thường rất xuất sắc trong việc loại bỏ những yêu cầu viển vông. Tuy nhiên, bạn vẫn nên thực hiện thẩm định kỹ thuật (due diligence) để bổ sung.
  • Trong một số trường hợp, bạn có thể cần thực hiện phân tích kỹ thuật sâu. Hãy chắc chắn dành ngân sách thời gian cho việc đó.
• Kiểm tra các dấu hiệu cảnh báo (red flags):
  • Rủi ro bảo mật.
  • Lo ngại về quyền riêng tư.
  • Vấn đề về tính sẵn sàng của dữ liệu.
• Thống nhất về các sự đánh đổi (trade-offs). Ghi lại các sự đánh đổi dựa trên tính khả thi, bảo mật và quyền riêng tư. Thảo luận và thống nhất về các đề xuất này. Làm như vậy sẽ giúp mọi thứ rõ ràng và hỗ trợ quá trình thiết kế của bạn.

Bước 1: Thu thập (Collecting)

Chúng ta có một vấn đề, một vấn đề hay ho. Bạn biết nơi mình muốn đến nhưng chưa biết đi bằng cách nào. Nó giống như bạn biết mình muốn đến Grand Canyon, nhưng chưa tìm được chuyến bay rẻ nhất hay lộ trình tốt nhất. Có rất nhiều mảnh ghép chuyển động.

Bạn có thể có rất nhiều thông tin trong tay hoặc hầu như không biết gì vào thời điểm này. Đó là bình thường. Khi tôi ở trong tình huống này, tôi làm như sau:

1. Lấy giấy và bút.
2. Vẽ một vài "chiếc hộp" sơ sài đại diện cho những "thứ" giúp hệ thống vận hành. Đừng lo lắng về việc vẽ chính xác tất cả các hộp vào lúc này.
3. Nối tất cả các "thứ" đó bằng các đường thẳng. Bây giờ, bạn đã có một luồng (flow) sơ bộ.
4. Lặp lại và tinh chỉnh luồng đó cho đến khi tôi có một sơ đồ giải quyết được vấn đề.

Bước 2: Phân loại (Categorizing)

Bây giờ bạn đã có tất cả các "chiếc hộp" cần thiết, đã đến lúc chia để trị. Bạn có thể chia các hộp sơ bộ thành 3 loại:

• 1. Rõ ràng (Clear):
  • Đã có các giải pháp đã được kiểm chứng cho những phần này, hoặc ít nhất là một con đường rõ ràng phía trước.
  • Những "cơ bản" này đã có sẵn cho bạn: Đặc tả kỹ thuật, Tài liệu, Kế hoạch hỗ trợ.
• 2. Mờ ảo (Frosted):
  • Giống như các hộp "Rõ ràng", ngoại trừ việc thiếu một số yếu tố cơ bản.
• 3. Mơ hồ (Fuzzy):
  • Đây là những phần thú vị nhất (theo hướng tốt hoặc xấu).
  • Hầu hết các yếu tố cơ bản đều thiếu, nhưng bạn lờ mờ thấy được con đường phía trước.

Bước 3: Ưu tiên hóa (Prioritizing)

“Nếu mọi thứ đều là ưu tiên, thì chẳng có gì là ưu tiên cả.” - Frank Sonnenberg

Chắc hẳn bạn đã nghe câu này nhiều lần. Hãy nghĩ về những điều mà sản phẩm này cần làm. Đó là hiệu quả tài nguyên, độ trễ thấp, tính sẵn sàng cao, hay tất cả những thứ đó? Cái nào đứng nhất, cái nào đứng nhì, v.v. Danh sách ưu tiên này rất quan trọng đối với cách bạn tiếp cận việc thiết kế sản phẩm.

Bước 4: Khám phá (Discovery)

Bây giờ bạn đã có các hộp sơ bộ và những đường nối nguệch ngoạc, đã đến lúc đi sâu hơn. Trong bước này, bạn thử nghiệm hoặc kiểm tra các tùy chọn khác nhau cho mỗi hộp. Bạn sẽ cần một vài thứ cho mỗi hộp:

• Đặc tả kỹ thuật & Tài liệu người dùng.
• Liên hệ: Nếu một thành phần đến từ nhóm khác, bạn sẽ cần ít nhất một đầu mối liên hệ. Điều này hữu ích nếu bạn có câu hỏi trong khi tìm hiểu thành phần đó.
• Môi trường kiểm thử (Test Rig):
  • Rất có thể, người xây dựng các thành phần bạn đang sử dụng đã có sẵn môi trường test. Hãy "xin xỏ" hoặc mượn để không phải phát minh lại bánh xe.
  • Nếu không có, hãy tự xây dựng một cái đơn giản. Chỉ cần làm đủ để kiểm tra các chức năng cơ bản bạn cần.
• Phân tích sự phụ thuộc (Dependency Analysis):
  • Tạo danh sách các dependency đã biết.
  • Kiểm tra các lỗ hổng bảo mật đã biết. Sự hiện diện của các lỗ hổng có thể ảnh hưởng đến quyết định sử dụng thư viện đó hay không.
• Ghi chú: Giữ các ghi chú được tổ chức tốt để tham khảo sau này, đặc biệt là đối với các hệ thống lớn với nhiều chi tiết nhỏ.

Việc thu thập các mục từ danh sách cho từng hộp một là hoàn toàn ổn. Ý tưởng là không để bị choáng ngợp bởi độ rộng của hệ thống và làm việc theo từng phần nhỏ, dễ xử lý.

Bước 5: Lắp ráp (Assembly)

Đến lúc này, bạn đã có ý tưởng khá tốt về việc mọi thứ hoạt động như thế nào. Bây giờ là lúc cầm bút và giấy lên một lần nữa. Lần này, hãy nhìn vào bản vẽ ban đầu của bạn và tạo ra một phiên bản chi tiết hơn. Bản vẽ này sẽ cho bạn bức tranh toàn cảnh về cách mọi thứ vận hành.

Đến lúc cho một checklist khác:

• Liệt kê các kịch bản:
  • Happy path (Luồng chạy suôn sẻ).
  • Stuff is on fire (Xử lý lỗi/Sự cố).
  • Transient failures (Lỗi thoáng qua - Cần cơ chế Retry/Backoff).
• Vẽ sơ đồ: Vẽ biểu đồ trình tự (sequence diagram) hoặc lưu đồ (flow chart) cho mỗi kịch bản.
• Kế hoạch kiểm thử: Viết một kế hoạch kiểm thử toàn diện.
• Xem xét lại Dependency: Kiểm tra lại danh sách các phụ thuộc và lỗ hổng. Bạn có cần thêm hoặc bớt gì không? Một dependency có quá khó xử lý không? Bạn có thể phải làm lại bước khám phá cho chức năng đó.
• Tài liệu hóa: Tổng hợp thiết kế thành một tài liệu gọn gàng.

Lời kết

Thiết kế sẽ không hoàn hảo ngay trong lần lặp đầu tiên. Không có gì xấu hổ khi quay lại và làm lại một số phần. Hãy chắc chắn rằng bạn đang cân nhắc chi phí, rủi ro và lợi ích một cách khôn ngoan. Cuối cùng, hãy ước tính và đưa mọi thứ vào công cụ theo dõi công việc mà công ty bạn sử dụng.