"Just Enough Software Architecture" xuất bản năm 2010

Giới thiệu sách về kiến trúc phần mềm

Đặc điểm của sách

• Thiết kế dựa trên rủi ro: Nhấn mạnh thiết kế đơn giản khi rủi ro thấp và thiết kế kỹ lưỡng khi rủi ro cao.
• Dân chủ hóa kiến trúc: Hướng tới việc giúp mọi lập trình viên đều hiểu về kiến trúc.
• Tri thức khai báo: Cung cấp các khái niệm rõ ràng về thiết kế và xây dựng hệ thống.
• Nhấn mạnh tính kỹ nghệ: Tập trung vào khía cạnh kỹ thuật để hỗ trợ đưa ra các quyết định thiết kế theo nguyên tắc.
• Lời khuyên thực tiễn: Trình bày các phương pháp thiết kế thực dụng thông qua các mô hình ở nhiều mức độ trừu tượng khác nhau.

Cấu trúc của sách

Part I: Kiến trúc phần mềm dựa trên rủi ro

• Định nghĩa kiến trúc phần mềm: Đóng vai trò là bộ khung của hệ thống và ảnh hưởng đến các thuộc tính chất lượng.
• Mô hình dựa trên rủi ro: Giải thích cách xác định và sắp xếp ưu tiên rủi ro, sau đó áp dụng các kỹ thuật thiết kế phù hợp để giảm rủi ro.
• Lời khuyên khi dùng mô hình: Trình bày cách sử dụng mô hình để giải quyết vấn đề, thêm các ràng buộc một cách cẩn trọng, và phân bổ kỹ năng kiến trúc cho toàn bộ nhóm.

Part II: Mô hình hóa kiến trúc

• Cấu trúc mô hình khái niệm: Gồm mô hình miền, mô hình thiết kế và mô hình mã nguồn.
• Xây dựng ranh giới đóng gói: Che giấu cách vận hành bên trong của component hoặc module để có thể tập trung giải quyết các vấn đề khác.
• Xây dựng mô hình hiệu quả: Giải thích cách tích hợp nhiều kỹ thuật kiến trúc khác nhau để xây dựng và gỡ lỗi các mô hình thực dụng, nhấn mạnh các thuộc tính chất lượng và tính năng.
• Lời khuyên khi dùng mô hình: Đề cập cả ưu điểm lẫn nhược điểm của mô hình và đưa ra cách sử dụng hiệu quả.

Ebook và bản bìa cứng

• Ebook: Đang được bán trên Google Play dưới dạng DRM-free ($9.99).
• Bản bìa cứng: Có thể mua trên Amazon.

Đánh giá về sách và tài liệu bổ sung

• Đánh giá: Có nhiều bài đánh giá và tiểu luận từ IEEE Software và các nguồn khác.
• Tài liệu bổ sung: Có video và ấn phẩm về nhiều chủ đề như thiết kế liên tục, phong cách kiến trúc, mô hình hóa, v.v.

Ý kiến của GN⁺

• Tầm quan trọng của cách tiếp cận dựa trên rủi ro: Thiết kế dựa trên rủi ro rất hữu ích trong việc nâng cao khả năng thành công của dự án.
• Dân chủ hóa kiến trúc: Khi mọi lập trình viên đều hiểu kiến trúc, hiệu quả của cả nhóm có thể được nâng cao.
• Lời khuyên thực tiễn: Cuốn sách này cung cấp nhiều lời khuyên thực tế hơn là lý thuyết, nên có thể áp dụng ngay vào các dự án thực tế.
• Tập trung kỹ thuật: Tập trung vào khía cạnh kỹ thuật để giúp lập trình viên giải quyết các vấn đề thực chất.
• Tài liệu học tập bổ sung: Có thể học sâu hơn thông qua nhiều tài liệu bổ sung đa dạng.

[GN⁺]

Ý kiến trên Hacker News

• Cần phân biệt giữa rủi ro quản lý dự án và rủi ro kỹ thuật phần mềm. Năng lực kỹ thuật thường không giải quyết được rủi ro quản lý.
• Chất lượng mã, tổ chức, kiểm thử, tài liệu hóa và việc dùng công cụ tiêu chuẩn đều giúp ích cho cả hai phía.
• Lý do người ta hay dùng giả thuyết "bị xe buýt tông" là để tạo ra phần mềm có thể tái tạo và dễ hiểu.
• Để tránh sắc thái tiêu cực, nên dùng cách diễn đạt "trúng xổ số".
• Kiến trúc chỉ để có kiến trúc là điều tệ nhất. Nó làm tăng độ phức tạp một cách không cần thiết.
• Mục tiêu cuối cùng của kiến trúc tốt là giảm chi phí. Nếu mất nhiều thời gian hơn cho phát triển và bảo trì thì đó là kiến trúc thất bại.
• Tò mò không biết một cuốn sách xuất bản năm 2010 còn đứng vững đến mức nào.
• Sách "Design It" có các hoạt động workshop hữu ích cho người làm kỹ thuật, và điểm hay là không thiên lệch về một phong cách kiến trúc kỹ thuật cụ thể nào.
• Cuốn 'A Philosophy of Software Design' của John Ousterhout rất hữu ích. Có nhiều lời khuyên và ví dụ dễ hiểu.
• Có lẽ "phụ thuộc vào rủi ro" sẽ là tên gọi hay hơn. Cũng tò mò vì sao lập trình viên lại thích cách nói "dựa trên [X]".
• Không biết cuốn sách cụ thể đó, nhưng bài viết của tác giả về "kiểm soát trí tuệ" rất sâu sắc.
• Vài năm trước công ty đã làm book club về sách này, nhưng cảm thấy nó rất lặp lại.
• Tò mò không biết đây có phải là tài nguyên tốt cho người bắt đầu một dự án mã nguồn mở đáng kể hoặc cho solopreneur hay không. Có người cũng muốn được gợi ý sách hay tài nguyên hữu ích cho lập trình viên solo.
• Kiến trúc phần mềm giống với kiến trúc nói chung, nhưng trong phần mềm không có nhân vật như Isaac Newton nên không tồn tại ngành kỹ nghệ dân dụng tương đương. Người gần nhất có lẽ là Claude Shannon.
• Cần định hướng khi đọc các thuật ngữ tùy tiện. Muốn có mô hình toán học. Những thuật ngữ mơ hồ do con người tạo ra chẳng qua chỉ là cách chắp vá để diễn đạt ý tưởng.