- Chỉ những kỹ sư trực tiếp làm việc với mã nguồn mới có thể thực sự tham gia thiết kế trong các hệ thống quy mô lớn; các lời khuyên mang tính trừu tượng phần lớn là vô nghĩa
- Lời khuyên thiết kế chung (generic design) thường được đưa ra khi chưa biết codebase mà chỉ hiểu miền nghiệp vụ
- Trong công việc thực tế, các ràng buộc cụ thể và việc duy trì tính nhất quán quan trọng hơn nhiều so với các nguyên tắc thiết kế, và cốt lõi là hiểu được trạng thái hiện tại của mã nguồn
- Khi thiết kế hệ thống mới hoặc quyết định định hướng kỹ thuật cho toàn công ty, các nguyên tắc thiết kế chung có thể phát huy tác dụng hữu ích ở một mức độ nhất định
- Tuy nhiên, mô hình thiết kế lấy kiến trúc sư làm trung tâm nhưng tách rời hiện trường rất dễ thất bại, và người đề xuất thiết kế phải chịu trách nhiệm cho kết quả
Giới hạn của thiết kế phần mềm tổng quát
- Thiết kế hệ thống quy mô lớn đòi hỏi sự hiểu biết sâu sắc về các chi tiết cụ thể của mã nguồn
- Lời khuyên mang tính trừu tượng hầu như không giúp ích cho việc giải quyết vấn đề thực tế
- Trong thực tiễn, tính nhất quán (consistency) quan trọng hơn cả ‘thiết kế tốt’
- Vì codebase thực tế rất phức tạp và tạo ra các kết quả khó lường, các cách triển khai có thể lựa chọn để thay đổi một cách an toàn là rất hạn chế
- Codebase dùng chung ở quy mô lớn luôn ở trong trạng thái trung gian nơi nhiều kiểu thiết kế bị trộn lẫn với nhau, nên trạng thái kết dính hiện tại của mã nguồn quan trọng hơn mục tiêu lý tưởng
- Vì phần lớn hệ thống không thể được viết lại toàn bộ (rewrite), nên phải dựa vào tính nhất quán nội bộ và sự cẩn trọng của kỹ sư
Đặc điểm của thiết kế phần mềm cụ thể
- Các cuộc thảo luận thiết kế hiệu quả diễn ra giữa một số ít kỹ sư làm việc với hệ thống mỗi ngày
- Chủ đề thảo luận không phải là các nguyên tắc chung mà là bối cảnh cụ thể như cấu trúc chi tiết của hệ thống hay luồng dữ liệu
- Ví dụ, thay vì hỏi “DRY có tốt không”, người ta sẽ bàn về những chi tiết kỹ thuật tinh vi như “có thể đưa tính năng này vào subsystem A không, thông tin B có thể được truy cập trong context C không”
- Những đóng góp quan trọng xuất phát từ việc sửa lại các hiểu nhầm nhỏ hoặc tác động chi tiết của thay đổi mã nguồn
Khi nào lời khuyên thiết kế chung hữu ích
- Khi lần đầu thiết kế một dự án mới, vì chưa có các ràng buộc cụ thể nên các nguyên tắc chung sẽ hữu ích
- Khi khó lựa chọn giữa nhiều phương án triển khai, các nguyên tắc chung có thể đóng vai trò tiêu chí phân định (tie-breaker)
- Nó cũng giúp duy trì tính nhất quán ở cấp độ toàn công ty, và đây là một trong những vai trò chính thức của kiến trúc sư phần mềm
- Trong các lựa chọn công nghệ quy mô lớn như cloud vs on-premise, AWS vs Azure, các nguyên tắc chung cũng có thể được dùng làm tham chiếu, nhưng vẫn không thể bỏ qua các ràng buộc cụ thể
Kiến trúc sư và vấn đề ‘cực tiểu cục bộ’
- Nhiều doanh nghiệp rơi vào mô hình thiết kế trừu tượng lấy kiến trúc sư làm trung tâm nhưng thiếu kinh nghiệm thực địa
- Cách làm này nhìn bề ngoài có vẻ hiệu quả, nhưng trên thực tế lại tạo ra những thiết kế mà kỹ sư hiện trường không thể triển khai
- Vì kiến trúc sư không trực tiếp hiện thực hóa, họ thiếu trách nhiệm gắn với kết quả (skin in the game)
- Nếu thiết kế thành công thì họ nhận công, còn nếu thất bại thì có thể đổ lỗi cho đội thực thi
- Cấu trúc như vậy có xu hướng củng cố hoạt động thiết kế mang tính hình thức hơn là giá trị thực chất
Kết luận và đề xuất
- Những thảo luận thiết kế hữu ích diễn ra trong các cuộc trao đổi cụ thể ở cấp độ mã nguồn, và người thiết kế nhất định phải quen thuộc với codebase
- Các nguyên tắc kiến trúc chung nên chỉ được giới hạn ở việc thiết kế hệ thống mới, hỗ trợ các quyết định chi tiết trong hệ thống hiện có, và xác định định hướng kỹ thuật ở cấp công ty
- Người đề xuất thiết kế dự án phải chịu trách nhiệm cho thành công và thất bại của nó, và các kỹ sư trực tiếp làm việc với mã nguồn phải là chủ thể của hoạt động thiết kế
- Qua đó, người thực sự hiểu và có thể triển khai hệ thống mới có thể được công nhận là nhà thiết kế thực thụ
3 bình luận
> Trong công việc thực tế, các ràng buộc cụ thể và việc duy trì tính nhất quán quan trọng hơn nhiều so với các nguyên tắc thiết kế, và điều cốt lõi là phải hiểu được trạng thái hiện tại của mã nguồn
Đây đúng là quan điểm thường ngày của tôi, đọc mà thấy ấm lòng.
Thảo nào dạo này các guru mới nói là người mới vào nghề lại dùng agent giỏi hơn hẳn. Vì đây là thứ đã giúp họ kiếm tiền lâu nay nên họ không chịu unlearn.
Nếu cải thiện quy trình hoàn thiện kiến trúc thì có thể giải quyết đầy đủ những vấn đề đã được nêu ra, phải không?