Intuition and experience are the sole arbiters here. To Ousterhout, the interface is just a comment and some discussion about whether it’s simple to use and think about. It sounds pretty nice to say “interfaces should be shorter than the implementation.” How do you test it? When specifications are longer than the code Unfortunately, it’s also objectively wrong. A good module is deep: the interface should be much simpler than the implementation.īeautiful, obvious, and impossible to disagree with. Many modules are shallow: they take a lot to explain, but don’t actually do that much. It also includes informal elements: high-level behavior, constraints on ordering anything a developer needs to know to use it. An interface, explains Ousterhout, is not just the function signatures written in the code. But it’s Chapter 4 where he introduces the book’s central idea: deep modules. Chapter 5 is one of the most approachable introductions I’ve seen to Parnas’s ideas about information hiding. Its early chapters are a grand tour of the basic concepts of software organization: separating levels of abstraction, isolating complexity, and when to break up functions. ![]() ![]() On the whole, the book’s advice is higher-level than beginner books like Clean Code, but most of its contents will be familiar to a senior software engineer, and the novel parts are hit-and-miss.įollowing other books like Code Simplicity, PoSD starts with a high-minded explanation of the benefits of good code and the dangers of complexity. He demonstrates the lack of principles comically in Chapter 19, where he promises to apply the books’ “principles” to several software trends, and then fills the rest of the chapter with standard (but solid) advice on unit-testing and OOP, with nary a reference to the rest of the book. His few attempts to jump from tactical advice to principles are either done by trying to blur together similar-sounding tips, or are hamstrung by his inability to see the meaning of a program beyond the code (more on that later). About a quarter of it is spent on naming and comments, and much of the rest is about specific patterns. PoSD is best read as a tactical guide of how-to’s. He’s had plenty of impact too: he’s the creator of the Tcl language and its Tk framework, which I learned in 2005 as The Way to Write GUIs(™). And, given that he’s a busy professor managing a large lab, he’s written a surprising amount of it himself. RAMCloud, Ousterhout’s distributed in-memory storage system, is now on my shortlist: from a 5-minute glance, it’s among the cleanest and best-documented code I’ve seen. I enjoy tearing apart open-source projects and turning them into case studies of what not to do, so much that my students have requested I write a case study about good code for once. John’s background is in systems rather than in software engineering or programming languages, and he never claims special expertise. ![]() I know him also as the father of Kay Ousterhout, whom I recently met as a fellow speaker at Strange Loop, and Amy Ousterhout, whom together are the first pair of sisters to both win the prestigious Hertz Fellowship.Īt 170 pages, “A Philosophy of Software Design” (henceforth: PoSD) is a humble book. I remember John Ousterhout from Stanford’s grad student visit day as the tall guy who introduced himself with a self-deprecating joke and invited all the Ph. And so, when I heard about John Ousterhout’s new book “A Philosophy of Software Design,” I ordered my copy immediately. This is very easy because not very much has been written: it turns out that it’s much easier to write an article about how to write a Tetris AI as a containerized Kotlin microservice than it is to shed insight on how to write good code. ![]() I’m trying to read all the good writing about software design.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |