Giới thiệu sách: A Philosophy of Software Design

[ltd (Lê Trần Đạt)]

Chào mọi người,

Hôm nay mình muốn giới thiệu đến anh em một cuốn sách cực kỳ giá trị cho bất kỳ ai làm trong lĩnh vực phát triển phần mềm: “A Philosophy of Software Design” của John Ousterhout và Bryan O’Sullivan.

Cuốn sách này không đi sâu vào các pattern hay kỹ thuật cụ thể, mà tập trung vào những nguyên lý cốt lõi và triết lý đằng sau việc thiết kế một hệ thống phần mềm tốt . Từ việc quản lý độ phức tạp, thiết kế module, đến việc viết code dễ đọc và bảo trì, “A Philosophy of Software Design” mang đến những góc nhìn sâu sắc và thực tế, giúp chúng ta suy nghĩ thấu đáo hơn về công việc hàng ngày của mình.

Nếu bạn đang tìm kiếm một nguồn tài liệu giúp nâng cao tư duy thiết kế, xây dựng những ứng dụng bền vững và dễ hiểu, thì đây chắc chắn là một cuốn sách không thể bỏ qua.

P/S: Mình từng áp dụng “Clean Code” và thấy nhiều điểm hay. Tuy nhiên, dần dà mình nhận ra một số khía cạnh mà “Clean Code” chưa hẳn đã bao quát hết. Đến khi đọc “A Philosophy of Software Design”, mình thấy quyển sách này giải thích những điểm đó rất tốt và phù hợp với cách mình tư duy hơn. Mình cảm thấy những nguyên lý trong “Philosophy of Software Design” thiết thực và đáng để mình áp dụng hơn trong công việc.

[Joe (Schwarz)]

I haven’t read the book, but your enthusiasm has piqued my interest. So I searched the Web for all the comments and information about Prof. John Ousterhout’s book. Here are some of them. Read them and form your own opinion:

• My learnings from the book “A Philosophy of Software Design”
• Lessons from “A Philosophy of Software Design”
• Not my philosophy of software design
• Book review: “A Philosophy of Software Design”
• or HERE

My opinion is that software design is a dynamic process that is determined by the nature of the problem the software is intended to solve.

As the goal grows over time, so does the software. It’s a dynamic process. If the new goal deviates from the original to some extent, complexity also increases. Because changes in the future are unknown at the time of design, it’s nearly impossible to create a generic, architectural software design. Therefore, reducing complexity is difficult. As commentator Tiger Abrodi wrote, “If you write code that seems simple to you, but others consider it complex, then it is complex.”

one of the goals of software design is to reduce the number of dependencies and to make the dependencies that remain as simple and obvious as possible.

This contradicts most IDE frameworks. I’ve seen a lot of Github code and noticed that some approaches were packaged with numerous small modules or interfaces. I doubt they’re all easy to read if you constantly have to jump back and forth between code to find the independences and their function. In other words, it makes the software more obscure and more complex…

Deep and shallow modules. The best modules are deep: they allow a lot of functionality to be accessed through a simple interface. A shallow module is one with a relatively complex interface, but not much functionality: it doesn’t hide much complexity.