Table Of Content
"If you reduce the number of methods in an API without reducing its overallcapabilities, then you are probably creating more general-purpose methods." An abstraction is asimplified view of an entity which omits unimportant details, making it easierfor us to think about and manipulate complex things. It is more important for a module to have a simple interface than a simple implementation. That being said, we have to be wary of Classitis a term I have come to appreciate and can relate too, as I have worked on many software systems in the past that actually have this issue.
Other materials, books, articles, etc.
If you're interested in whether to read this book, my recommendation is that you probably should, for a few reasons I list in my conclusion. When you’re performing a code review on a class, smell around for special purpose code mixed with general purpose code. This mixture represents an opportunity to split off the general purpose code into something more reusable. But yours is a great review and a valuable service to the IT community that increasingly finds itself facing Technical Debt to the point of bankruptcy. Like reusing a common class, consistent naming lessens cognitive load by enabling readers to quickly draw assumptions when they see the name in a different context because they have already seen it in one.
Chapter 15 — Write The Comments First
Ousterhoutdiscusses the different types and causes of complexity, and then varioussoftware design considerations and their relationship to complexity - patterns,antipatterns, questions to ask, etc. While the book does a good job covering architecture concepts when writing code, there are several areas that it does not touch on. Most of these are outside the scope of the software design course itself. The importance of good and simple naming (Chapter 14) mirror my experience on how simple names often mean simple functionality. Complex names - or difficulty to name something - is usually a code or architecture smell.
Software Design Book
The Philosophy of Grant Petty and the Future of Blackmagic Design - No Film School
The Philosophy of Grant Petty and the Future of Blackmagic Design.
Posted: Fri, 28 Apr 2023 07:00:00 GMT [source]
To add to this, we haven't completely identified all of the issues we will confront. In essence, we still have to discover the Unknown Unknowns as we cautiously proceed. There are also a few weaker chapters towards the end of the book, for example Code Should Be Obvious and Software Trends. Code Complete has a lot more to say about names, and does it better. However, I really liked the story of how a too generic variable name (block) caused a bug that took six months to find. In a lot of places, the author uses comments and documentation interchangeably.
Otherwise, you are better off implementing the system without that particular element. For example, a class can reduce complexity by encapsulating functionality so that users of the class needn’t be aware of it. Classitis may result in classes that are individually simple, but it increases the complexity of the overall system. Small classes don’t contribute much functionality, so there have to be a lot of them, each with its own interface.
Instead you can define it to return the characters of the string (if any) with index greater than or equal to beginIndex and less than endIndex. That way no exception needs to be thrown, which greatly simplifies the usage. Python does something similar when returning an empty result for out-of-range list slices. An example is when you have implemented a message protocol with a sender and a receiver.
List of software development philosophies
Technical debt and architecture debt also don't get much mention or discussion, which is in contrast to my day to day work. It would be nice to see a later version touch on these topics, as well. The book is an easy read, thanks to its short sections and good bolding. Most importantly, the book stays humble, does not try to convince, but offers perspectives backed by easy to follow examples.
A Philosophy of Software Design — Book Summary & Notes
If the code is so complex, we need to comment on it; maybe we can rewrite it to be more straightforward and understandable. Most people use a tactical approach, where the goal is to make something work. However, the result is a bad design with a lot of tech complexity, which usually results in spaghetti code. Complexity is not a single line but many lines in a project, which we overlook as a whole. His recommendation is to take a strategic approach where the working code is not the only goal, but the goal should be great design, which simplifies development and minimizes complexity. It involves breaking down software systems into smaller, independent modules or components, each responsible for a specific functionality or feature.
i. Good code is self-documenting
A singleshortcut or tactical decision that adds complexity won't have much impact, butsmall decisions can accumulate to dozens or hundreds of things that do have animpact. Then refactoring becomes a big task that you can't easily schedule withthe business, so you look for quick patches, and this creates yet morecomplexity, which requires more patches, and so forth. Ousterhout advocates for a strategic approach to software development, ratherthan a wholly tactical approach. This essentially just means ongoing, regularinvestment of some of your development time towards system design, rather thanjust working code. When building software systems, the core challenge is managingcomplexity.
Pass-through variables add complexity because they force intermediate methods tobe aware of their existence, even though the methods have no use for thevariables. Below are the notes I made on takeaways from the book and my thoughts on acouple of the ideas (minus some fun references to real code that I've workedon). I'm publishing the notes as it's a nice way for me to re-read them andretain the information. This doesn't cover all the content in the book, and it'spossible that I misrepresent the author in some of my paraphrasing. If you'reinterested in the content I definitely recommend buying a copy - it's notexpensive and it's an easy read. What makes it especially great from a software related book, is that there is really not a lot of code to read and for what there is, it is just to relay an idea.
We need more resources to remind us not overcomplicate software architecture. It will become complicated enough, module after module, layer after layer. The author argues that if your code throws an exception, you force all callers of that code to know how to handle this exception. Yet, in many cases, callers don’t know what to do about the exception which is thrown. He says we should define our functionality so we never need to throw an exception.
No comments:
Post a Comment