More on this book
Community
Kindle Notes & Highlights
Thus, the best way to determine the obviousness of code is through code reviews. If someone reading your code says it’s not obvious, then it’s not obvious, no matter how clear it may seem to you.
Sounds useful; pretty much the theory behind peer review.
Red Flag: Nonobvious Code If the meaning and behavior of code cannot be understood with a quick reading, it is a red flag. Often this means that there is important information that is not immediately clear to someone reading the code.
This example illustrates a general rule: software should be designed for ease of reading, not ease of writing.
This is absolute gold, and is also true for every other communication.
Another way of thinking about obviousness is in terms of information. If code is nonobvious, that usually means there is important information about the code that the reader does not have:
One of the risks of agile development is that it can lead to tactical programming. Agile development tends to focus developers on features, not abstractions, and it encourages developers to put off design decisions in order to produce working software as soon as possible.
Agreed; this is the model of development i use to use and it accelerated me into walls.
Developing incrementally is generally a good idea, but the increments of development should be abstractions, not features.
Absolutely agreed.
With a good set of tests, developers can be more confident when refactoring because the test suite will find most bugs that are introduced.
The problem with test-driven development is that it focuses attention on getting specific features working, rather than finding the best design.
When a measure becomes a target, it ceases to be a good measure.
There’s no obvious time to do design, so it’s easy to end up with a mess.
Same with having a life which is too busy.
The notion of design patterns was popularized by the book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides, and design patterns are now widely used in object-oriented software development.
This will be a good book to read next.
Imagine instead that you are writing a new method that implements just the critical path, which is the minimum amount of code that must be executed in the the most common case.
I.e. Ignore all the extra functionality and try to find the key function performed by your application and optimise for that key function, i.e. Critical path. Allows to simplify and get rid of superfluities that might be slowing the code down
Let’s call this code “the ideal.” The ideal code probably clashes with your existing class structure, and it may not be practical, but it provides a good target: this represents the simplest and fastest that the code can ever be.
One of the most important things that happens in this process is to remove special cases from the critical path. When code is slow, it’s often because it must handle a variety of situations, and the code gets structured to simplify the handling of all the different cases.
This is a great point; a big part of the simplification process is to define what is important, and optimise around that. Spreading yourself too thin will result in increased complexity and lowered performance.
The most important overall lesson from this chapter is that clean design and high performance are compatible.
Because a simple design inevitably creates less code to run, thus reducing the run time.
This book is about one thing: complexity. Dealing with complexity is the most important challenge in software design.
Dealing with complexity is an existential problem of everything which exists.
if you aren’t used to thinking about design issues, then you will slow down even more while you learn good design techniques. If the only thing that matters to you is making your current code work as soon as possible, then thinking about design will seem like drudge work that is getting in the way of your real goal.
The biggest mistake when trying to impliment something elegant.
It’s fun to explore different approaches, and it’s a great feeling to discover a solution that is both simple and powerful. A clean, simple, and obvious design is a beautiful thing.
The elegant solution. The beauty one should always look for in ones work.
The time you spent honing your design skills will also pay for itself: as your skills and experience grow, you will find that you can produce good designs more and more quickly. Good design doesn’t really take much longer than quick-and-dirty design, once you know how.
This allows for scalability in productivity, and follows the law of diminishing return. The rule is not to work hard, but to work on your strategy as much as possible so then every hour of your time is worth more.
If you improve your design skills, not only will you produce higher quality software more quickly, but the software development process will be more enjoyable.
