Kiến Trúc Phần Mềm: Nguyên Lý Tối Ưu và Chiến Lược “Fit for Purpose”
Last updated: August 29, 2025 Xem trên toàn màn hình



- 04 Jan 2023
Phát triển phần mềm linh hoạt theo mô hình Big Bang 593
- 18 May 2021
Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 526
- 03 Mar 2020
Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 427
- 03 May 2022
Mô hình Hybrid Agile là gì? 409
- 18 Mar 2021
Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 389
- 02 Aug 2023
Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 333
- 14 Apr 2019
Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 312
- 20 Jul 2021
Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 311
- 02 Aug 2021
Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 307
- 01 Aug 2023
Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 297
- 28 Jun 2024
Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 260
- 08 Jan 2022
Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 194
- 10 May 2021
Phát triển Phần mềm Tinh gọn (Lean Software Development) 179
- 24 Mar 2019
Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 164
- 08 Feb 2021
Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 162
- 14 Dec 2022
Phương pháp kiểm tra Fagan Inspection là gì? 152
- 21 Apr 2020
Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 144
- 09 Dec 2024
10 nghịch lý quản trị khiến tổ chức mãi loay hoay 93
- 10 Aug 2020
Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 91
- 22 Jul 2020
Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 86
- 28 Feb 2025
“Học giỏi” hay “giỏi học”? 70
- 19 Jul 2023
3 cấp độ của thất bại và bí quyết "cái khó ló cái khôn" 61
- 29 Aug 2023
"Function inlining" là gì? 51
- 11 Mar 2025
Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 49
- 09 Aug 2023
"Loop unrolling" là gì? 47
- 02 May 2025
Vì sao học giỏi mà vẫn nghèo, học dốt lại thành đạt trong cuộc sống? 41
- 16 Apr 2025
Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 25
- 01 Apr 2025
CTO ra quyết định như thế nào? 23
- 15 Aug 2025
Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 21
- 16 Aug 2025
Hoài nghi khoa học với 20 thuật ngữ bi quan về hiệu quả của Scrum 17
Mục đích tồn tại của phần mềm
Mục đích tồn tại của phần mềm một cách rõ ràng là để phục vụ các nỗ lực của con người. Phần mềm là công cụ giúp chúng ta khuếch đại năng lực: tính toán nhanh hơn, giao tiếp xuyên khoảng cách, tự động hóa các công việc tẻ nhạt, quản lý sự phức tạp hay phối hợp con người và nguồn lực. Đằng sau mỗi phần mềm đều là một nhu cầu, một mục tiêu hay một sự tò mò của con người — có thể là thương mại, sáng tạo, kết nối hay kiểm soát.
Sự lộn xộn trong kỹ nghệ phần mềm (Messiness of the software engineering)
Kỹ nghệ phần mềm trong thế giới thực vốn dĩ rất lộn xộn. Sự lộn xộn này xuất phát từ va chạm giữa yêu cầu không đầy đủ, thiết kế đơn giản hóa và những ràng buộc thực tiễn. Codebase thừa hưởng các quyết định từ quá khứ, sở thích của người dùng thay đổi theo thời gian, yêu cầu có thể đổi hướng giữa chừng, đội ngũ thì đa dạng về kỹ năng, và những quyết định đánh đổi được đưa ra dưới áp lực. Sơ đồ kiến trúc thì gọn gàng, nhưng log trong môi trường thực tế thì không. Các kỹ sư phải đối mặt với những tình huống bất ngờ, sự mơ hồ, vấn đề tích hợp, thông tin thiếu hụt, chính trị trong tổ chức và mục tiêu liên tục thay đổi — tất cả trong khi vẫn phải giữ hệ thống vận hành ổn định.
Chiến lược đối phó với sự bất định/lộn xộn
Có nhiều cách tiếp cận để quản lý sự bất định trong hệ thống phần mềm:
- Phong cách phản ứng (Reactive / “chữa cháy”): Chỉ hành động khi vấn đề đã xảy ra. Đặc trưng bởi việc giải quyết sự cố nhanh chóng, phản ứng tức thời với khủng hoảng.
- Phong cách chủ động (Proactive / “dự đoán trước”): Tập trung dự đoán trước những bất định tiềm ẩn và chuẩn bị phương án ứng phó. Bao gồm nhận diện rủi ro, xây dựng kế hoạch dự phòng, áp dụng biện pháp phòng ngừa.
- Phong cách kết hợp (Hybrid / “thích ứng”): Pha trộn cả hai cách tiếp cận trên. Lập kế hoạch chiến lược và giảm thiểu rủi ro cho những tình huống đã biết hoặc có khả năng xảy ra, đồng thời vẫn linh hoạt để phản ứng hiệu quả trước sự kiện bất ngờ.
- Phương pháp 3P (Protection – Prevention – Precaution) giúp nhà quản lý cân bằng giữa hành động và không hành động: Protection là ứng phó khẩn cấp với quy trình định sẵn cho tình huống không thể trì hoãn (như cô lập hệ thống khi bị tấn công mạng); Prevention là chủ động phòng ngừa bằng giám sát và cảnh báo sớm để giảm rủi ro và tránh quyết định vội vàng (như DevOps theo dõi hiệu suất); còn Precaution là thận trọng qua giáo dục, truyền thông nhằm nâng cao nhận thức và phòng ngừa dài hạn (như Google khuyến khích bật xác thực 2 lớp).
Phần mềm trong đời sống hiện đại
Hệ thống phần mềm vừa quan trọng vừa hiện diện khắp mọi nơi trong đời sống hiện đại, ăn sâu vào nhiều lĩnh vực. Khi chúng thất bại, hậu quả có thể làm gián đoạn cuộc sống, dừng hoạt động hoặc bào mòn niềm tin. Khi sự phụ thuộc vào phần mềm ngày càng lớn, yêu cầu về độ tin cậy, bảo mật và khả năng sử dụng cũng tăng lên, biến phần mềm không chỉ là công cụ mà còn là xương sống của xã hội và kinh doanh hiện đại.
Nassim Taleb, trong cuốn Antifragile, lập luận rằng dự báo là trò của những kẻ khờ. Thay vì cố gắng đoán trước điều không thể đoán, chúng ta nên tập trung xây dựng các hệ thống có khả năng đối phó với kết quả bất định và hoạt động trong nhiều kịch bản tương lai khác nhau.
Dù sự phản ứng tức thời là điều không thể tránh trong quản lý phần mềm, tôi cho rằng cần lấy phong cách chủ động làm mặc định, nhất là khi phải đối diện với những sự kiện vừa có xác suất cao vừa có chi phí lớn.
Thực tế hiện nay
Từ trải nghiệm của tôi khi làm kỹ sư phần mềm trong các đội ngũ chủ chốt tại nhiều công ty uy tín, tôi nhận thấy phong cách phản ứng thường được dùng nhiều hơn mức cần thiết. Điều này thường dẫn đến sự đánh đổi ở khía cạnh người dùng, chẳng hạn chức năng, khả năng sử dụng hay độ tin cậy. Thêm nữa, nó còn ảnh hưởng đến khả năng vận hành, gây leo thang chi phí, trì hoãn dự án hoặc duy trì tình trạng “chữa cháy triền miên”.
Theo thời gian, tôi càng trân trọng hai mục tiêu cốt lõi:
- Tạo ra phần mềm thân thiện với người dùng.
- Thực hiện điều đó một cách hiệu quả (đúng hạn, không lãng phí nhân sự, tự tin triển khai...).
Điều này dẫn tôi đến việc học hỏi từ các bậc thầy, đồng nghiệp, người hướng dẫn, cũng như các học trò — đồng thời phát triển những ý tưởng riêng. Tôi đã chắt lọc và chia sẻ những bài học này qua nhiều bài blog, buổi nói chuyện, và bài viết này đóng vai trò tổng hợp lại.
Kiến trúc phần mềm
- Chi phí xây dựng một nền tảng ≤ (khoản tiết kiệm cho mỗi khách hàng × số lượng khách hàng).
- Nền tảng có thể định nghĩa và tiêu thụ dịch vụ, hoặc định nghĩa và cung cấp dịch vụ, hoặc đóng vai trò trung gian giữa nhà cung cấp và người tiêu thụ dịch vụ.
- Vấn đề trong phần mềm thường đa chiều. Giải pháp phải vừa đáp ứng một chiều, vừa tối ưu các chiều khác. Đây chính là bản chất của nguyên lý Optimality (tối ưu). Nhiều nguyên tắc trong kỹ nghệ phần mềm là ứng dụng của nguyên lý này.
- Chất lượng phần mềm (NFR) có thể độc lập, cản trở hoặc hỗ trợ lẫn nhau. Cần khảo sát mối quan hệ này.
- Hệ sinh thái lưu trữ dữ liệu rất rộng và đa dạng, không thể chỉ chia thành column-store hay key-value store. Một góc nhìn khác là đánh giá chúng theo nhiều chiều.
- Không có phong cách kiến trúc “phổ quát”. Vấn đề và giải pháp nên được phân loại theo từng chiều độc lập để lựa chọn giải pháp “phù hợp với mục đích”.
- Ngôn ngữ tự nhiên tuy dễ dùng nhưng lỏng lẻo, dễ gây ra lỗi. Thay thế bằng mô hình cấu trúc và biểu diễn trực quan sẽ giúp giao tiếp chính xác hơn, nâng cao chất lượng.
- Kỹ nghệ phần mềm thực tế là sự kết hợp giữa khoa học máy tính và khoa học thông tin. Các khía cạnh như trích xuất, phân giải, mô hình hóa, xử lý, nén và lan truyền thông tin đều quan trọng.
- Trong thế giới microservices, khái niệm interface như một thực thể hạng nhất bị lãng quên. Mô hình client–service–server là phần mở rộng của mô hình client–server, lấp khoảng trống trong tư duy của lập trình viên.
Tư duy (Mindset)
- Human-driven development: phát triển phần mềm thân thiện với con người.
- Fat server, thin client: chuyển trách nhiệm xử lý về phía server thay vì client.
- Composable features: xây dựng thành phần có thể kết hợp và điều phối.
- Minimalism: giảm thiểu số dòng code, số tham số, số phụ thuộc.
- South-shift mindset: chuyển trách nhiệm từ người dùng sang phần mềm.
Giao tiếp kỹ thuật
- Hình dung phần mềm: giới thiệu ngắn gọn và đơn giản.
- Cách viết tài liệu thiết kế phần mềm.
Lập trình hàm (Functional Programming)
- Vì sao lập trình hàm quan trọng.
- Các khái niệm: kiểu đại số, pattern matching, monoid, functor, monad, applicative functor.
- Lập trình với hiệu ứng.
- Phương pháp railway-oriented programming.
Tài chính
-
Khởi nghiệp, cổ phiếu, quyền chọn và thuế.
