- Tôi đang cố gắng cải thiện năng lực thiết kế phần mềm của mình và được khuyên rằng nên nghiên cứu những codebase hiện có được thiết kế tốt
- Tôi tò mò không biết trong số các codebase có thể truy cập công khai, đâu là những cái được xem là tiêu chuẩn vàng về thiết kế phần mềm
1. Các codebase được đề xuất
- Dự án lớn/tiêu biểu
- Git, Postgres, CPython
- "mô hình lieutenants" của Linux Kernel
- UNIX v6, BSDs
- Framework/thư viện
- Hệ thống/máy chủ
- Game/trường hợp đặc biệt
- Tài liệu học tập/giảng dạy
- Khác
- Monocypher (thư viện mật mã)
- phần triển khai ngôn ngữ Tcl
2. Đọc code vs học tài liệu/thiết kế
- Giới hạn của chỉ đọc code
- Codebase cho thấy phần triển khai, nhưng che giấu ý đồ thiết kế và các đánh đổi
- Tầm quan trọng của tài liệu thiết kế
- Các bản ghi quyết định như ADR (Architectural Decision Records), Rust RFCs, Python PEPs hữu ích hơn nhiều cho việc học thiết kế
- Việc tự viết tài liệu thiết kế cũng có thể là một hình thức rèn luyện
- Sách/tài liệu được khuyên đọc
3. Quan điểm học tập lấy thực hành làm trung tâm
- Kinh nghiệm và thử-sai
- Thiết kế là thứ được học bằng cách liên tục gặp vấn đề và học cách tránh chúng
- Chỉ đọc code thì không đủ; bạn học được nhiều hơn khi tự viết và giải quyết các thất bại
- Học dựa trên hứng thú
- Bạn sẽ học sâu hơn nếu xây dựng dự án mà bản thân thực sự hứng thú
- Chi phí thất bại thấp
- So với kỹ thuật vật lý, phần mềm có chi phí thất bại thấp hơn nên việc học qua thử nghiệm và thất bại rất hiệu quả
4. Tranh luận về bản chất của kỹ nghệ phần mềm
- Lập luận về tính chưa trưởng thành của một ngành kỹ thuật
- Nếu năm kỹ sư đưa ra năm cách giải khác nhau, đó là bằng chứng cho thấy lĩnh vực này còn chưa trưởng thành với tư cách một ngành kỹ thuật
- Quan điểm cho rằng phần mềm thân thiện với thử nghiệm
- Phần mềm có ít ràng buộc hơn nên tồn tại nhiều cách giải; không có một đáp án cố định như trong kỹ thuật vật lý
- Ranh giới giữa nghệ thuật và kỹ thuật
- Thiết kế cũng là một hành vi mang tính nghệ thuật vì có yếu tố thẩm mỹ, nhưng ở khía cạnh đáp ứng yêu cầu chức năng thì nó vẫn là kỹ thuật
- Phần mềm nằm giữa sự linh hoạt mang tính nghệ thuật và tính chặt chẽ của kỹ thuật
5. Các phương pháp học thay thế
- Phân tích code tệ
- Không chỉ code được thiết kế tốt, mà việc thử sửa một codebase kém chất lượng cũng mang lại hiệu quả học tập rất lớn
- Học từ codebase của chính mình
- Codebase nội bộ của nhóm thường được xem là tài liệu giúp học được nhiều nhất
- Tuy vậy, nếu code của nhóm quá kém thì vẫn cần kết hợp với các ví dụ bên ngoài
- Học theo đúng domain
- Đọc những codebase tương tự với loại vấn đề bạn muốn giải quyết là cách hiệu quả nhất
Insight chính
- Codebase được thiết kế tốt có ích, nhưng việc học cần đi kèm với hiểu được ý đồ thiết kế và trải qua thử-sai
- So với việc chỉ đọc code, tài liệu thiết kế và bản ghi quyết định mới là nguồn học tập cốt lõi
- Các dự án chất lượng cao tiêu biểu như Git, Postgres, CPython, thư viện
std của Rust, v.v. có giá trị học tập rất cao
- Về lâu dài, học từ code tốt thôi chưa đủ; code kém chất lượng và chính code của bạn còn mang lại giá trị thực tế hơn
Tóm tắt các bình luận nổi bật
Gợi ý các codebase tiêu biểu (CraigJPerry)
- Postfix mail server
- Kiến trúc lấy bảo mật làm trung tâm, cho thấy một cấu trúc tương tự microservices từ trước cả khi khái niệm này trở nên phổ biến
- Nếu microservices hiện đại tập trung vào sự phân tán ở quy mô tổ chức lớn, thì Postfix được thiết kế vì bảo mật và sự đơn giản
- Spring Framework
- Phản ánh một văn hóa phát triển rất chú trọng nhu cầu của lập trình viên Java trong môi trường doanh nghiệp
- Có thể học được cách tiếp cận thiết kế lấy người dùng làm trung tâm
- Git
- Khi hiểu được cơ sở dữ liệu đối tượng (blob, tree, commit) và khái niệm reference, phần còn lại chỉ là sự mở rộng dần dần
- Sự mở rộng nhất quán từ các khái niệm cốt lõi được nêu như một ví dụ điển hình của thiết kế tốt
- Varnish
- Vừa là reverse proxy hiệu năng cao, vừa là một codebase được tổ chức rất tốt đến mức có thể dùng như tài liệu học tập
- Linux Kernel Lieutenants Model
- Dù không phải là codebase, đây vẫn là một mô hình quản lý phần mềm quy mô lớn đáng để tham khảo
- Đây không chỉ đơn thuần là những ví dụ về "code được thiết kế tốt", mà là những trường hợp mà các quyết định thiết kế để lại ấn tượng rất mạnh
Nhấn mạnh việc học từ codebase thực tế trong công việc (crystal_revenge)
- Giá trị học tập lớn nhất đến từ codebase của chính nhóm bạn
- Trong quá trình kết nối đầy lộn xộn giữa yêu cầu thực tế và phần triển khai, bạn sẽ cùng lúc trải nghiệm cả lựa chọn tốt lẫn lựa chọn tệ
- Trong các ràng buộc thực tế, yếu tố lớn nhất là áp lực thời gian; điều cốt lõi là học cách cân bằng giữa thiết kế lý tưởng và hiện thực
- Phần mềm tốt là phần mềm giải quyết được nhu cầu của người dùng; qua trải nghiệm lặp lại, bạn sẽ học được cách thiết kế để tăng khả năng thành công
Liên kết đến các thảo luận và tài liệu trước đây (sprobertson)
- Chủ đề này đã được thảo luận nhiều lần trên HN
Code vs tài liệu thiết kế (alphazard)
- Codebase chỉ là kết quả của phần triển khai, không phải bản thân thiết kế
- Để học thiết kế, việc viết tài liệu thiết kế hiệu quả hơn
- Tài liệu phải đủ rõ ràng để người khác có thể triển khai nguyên vẹn
- Nếu liệt kê các phương án thay thế và ghi lại lý do loại bỏ chúng, đó sẽ là bằng chứng cho quá trình cân nhắc thiết kế
- Một nhà thiết kế giỏi là người xem xét một không gian thiết kế rộng hơn và chọn ra điểm phù hợp
Nhấn mạnh việc hiểu toàn bộ hệ thống (RossBencina)
- Quá trình hiểu được toàn bộ codebase là cực kỳ có giá trị
- Không chỉ là đọc code được thiết kế tốt, mà còn là luyện khả năng nhìn ra bức tranh lớn của cả hệ thống
- Việc trực quan hóa các mối quan hệ bằng sơ đồ như UML có thể rất hữu ích
- Cách tiếp cận khi học:
- Đọc code của những phần mềm tương tự với thứ bạn đang phát triển là rất hiệu quả
- Nên bắt đầu từ code thuộc domain bạn đã quen, như web framework, web server, thư viện chuẩn Python, VSCode, v.v.
- Ban đầu nên tiếp cận từ chương trình nhỏ và domain quen thuộc
Tiêu chí của thiết kế tốt (mamcx)
- Thiết kế tốt là mục tiêu và ý tưởng, còn codebase cho thấy mức độ hiện thực hóa của chúng
- Thiết kế tốt không chỉ là các nhãn như "nhanh" hay "an toàn", mà cần bao gồm những cân nhắc cụ thể và bản ghi về các đánh đổi
- Ví dụ: có thể quan sát đặc điểm này trong Erlang, Pascal thời kỳ đầu, và thiết kế của nhiều RDBMS
- Thư viện
std của Rust là tài liệu học tốt vì nhấn mạnh bảo mật và tính nhất quán, và cả code lẫn tài liệu đều phản ánh điều đó rất trung thực
Những quyết định thiết kế vô hình (ben30)
- Khi nhìn vào một codebase được thiết kế tốt, phần quan trọng nhất là những gì không nhìn thấy
- Loại bỏ độ phức tạp, tránh các lớp trừu tượng không cần thiết, từ chối một số pattern nhất định — những quyết định về sự vắng mặt này mới là cốt lõi
- Để bù lại, có thể dùng ADR (Architectural Decision Records)
- Ghi lại các phương án thay thế, lý do loại bỏ và căn cứ lựa chọn để lưu giữ ngữ cảnh
- Điều này rất hữu ích cho cả người bảo trì sau này lẫn các công cụ AI
- Khi học, ngoài code, sẽ hiệu quả hơn nếu xem các dự án có kèm tài liệu quyết định thiết kế như ADR, RFC, PEP
Chưa có bình luận nào.