Table Of Content
This kind of decomposition has a different purpose to designingpublic interfaces, but sometimes get added to the public API of a class ormodule. The primary focus of the book is about attempting to eliminate or at least reduce complexity in software. This can be achieved by taking more time and consideration in the design and thinking about the implications of design. Related to the concept of deep modules is the advice to make them “somewhat general purpose”.
Chapter 9 — Better Together Or Better Apart?
You often throw an exception because you don’t know what to do in that case. But if you have trouble knowing what to do, chances are the caller also has trouble knowing what to do. If you can define your functionality such that it never needs to throw an exception, then you have reduced the complexity of the system. There are few books that discuss software design in a simple and approachable way, while leaving the reader novel and practical concepts to use. A Philosophy of Software Design is a standout and recommended read for this reason.
Test-driven development
However, it turns out that the most common use of unset was to clean up temporary state created by a previous operation. But it was hard to know how far the previous operation had progressed, so it was hard to know if a variable had been created or not. Thus you had to be prepared to handle exceptions from unset in a lot of places. It would have been much more useful, and simpler, if unset had been defined to mean that it ensures a variable with that name does not exist after it has been run, regardless of if it existed before or not. If your code throws an exception, you are forcing all callers of that code to be prepared to handle it if it happens.
Deep modules
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.
Writing up, sharing, and debating design with other peers is a practice more and more common in tech companies. This includes both whiteboarding and presenting to a group of peers, as well as more formal RFC-like design processes. While it might be less applicable to the course John taught, it's a practice that comes with many benefits. These days, as shared editing and commenting tools are more common, with editors like Google Docs and O365.
However, in my opinion, the documentation of a system is not the sum of the comments. It is a separate document that describes how the system fits together. Extracting the JavaDoc comments from all the classes does not become the documentation. Nothing highlights which classes are most important, and what the overall structure is. The chapter on optimization starts by listing typical times taken by various operations such as network communication, I/O to storage (disk, flash), memory allocation and cache misses.
Chapter 6 — General-Purpose Modules are Deeper
It was one of the primary sources of making procedural/spaghetti code and the source of many unpredictable bugs. I agree with the author that we should write comments if we have to explain something tricky (such as an algorithm or something similar) or non-obvious (why, not how). In addition, the author mentions a famous API design antipattern involving overexposing internals, which later adds to an architecture debt. One way to make code more obvious to the reader is to have blank lines betweenparts that are logically separate, and maybe to preface the code block with animplementation comment. The overall complexity of a system can be determined by the complexity of eachpart, weighted by the fraction of time developers spend working on that part. Ifyou isolate complexity in a place where it will never be seen, then that'salmost as good as eliminating it entirely.
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.
It continues with the standard advice of always measuring instead of assuming. When optimizing, the biggest gains can usually be had by fundamental changes. For example by introducing a cache, or changing the algorithm or data structure. As a budding developer, using jQuery extensively taught me the importance of simple interfaces in driving adoption of your code. On page 68, the author mentions the GOTO command to eliminate duplication by refactoring the code so that we can escape from the nested code. This is a big surprise, as the GOTO command has been considered a terrible idea by most authors for decades now.
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.
What Is DevOps? - dummies - Dummies.com
What Is DevOps? - dummies.
Posted: Wed, 16 Aug 2023 07:00:00 GMT [source]
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.
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.
Still, they all present interesting viewpoints, backed with examples. They also make for potentially sound advice to give, when mentoring less experienced engineers. Ousterhout argues that the best modules are those that provide powerfulfunctionality, but have a simple interface. He describes these as deep modules,in contrast to shallow modules, which have a complex interface but not muchfunctionality, thereby not hiding significant complexity. After that, you have to concentrate on speeding up the most commonly executed path. Currently maybe several method calls are used, but perhaps all the work could be done in a single method call.
No comments:
Post a Comment