The quality of code has a practical impact on both your agility and the cost of development:1
You can't change buggy code fast enough to be truly agile. Existing bugs can easily increase development costs (and time) by 10x. You can't afford not to fix them.
Caching Is Hard¶
There are only two hard things in Computer Science: cache invalidation and naming things.
A cache is just a memory leak you haven't met yet. — Dave Cheney
Don't abstract if you don't have to. Premature optimization often causes pain, leads to bloated code, and fewer developers understand what's going on. Instead, write tests so you can safely refactor when you really need to.
Maintaining small amounts of duplicate code is much easier and less burdensome than choosing the wrong abstraction.
Premature optimization is the root of all evil. — Donald Knuth
Breaking a problem down into small, coherent fragments lends itself to organization. Start with the basic low-level components and then proceed to higher-level abstractions.
Bottom-up development emphasizes coding and early testing, which can begin before having a detailed understanding of the final system - which in practice may never really happen as requirements are constantly evolving.
Advantages of the bottom-up approach are component reusability, agility, and testability.
I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the “top-down” method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first. — The Story of Mel
While we know this is difficult when working with a distributed team, branches, and pull requests, we encourage all contributors to refactor when they see a specific problem.
Ideally, when you are working on the same code anyway to implement a feature or improvement. This helps to verify that the changes are helpful in practice.
Ugly code is not a problem as long as there are tests, there are no security issues, and it can be easily refactored later. Nobody needs beautiful code that doesn't work.
Go Slow Before You Go Fast 🐰¶
You have to go slow before you can go fast. Keep it simple. Done is better than perfect. Be pragmatic. Stay focused.
Feel free to think ahead, just don't code ahead. But also, don't feel the need to decide so many details ahead. Learn enough to get started and build only what you need. — J. B. Rainsberger
Code That Cannot Be Tested Is Flawed¶
We strive for complete test coverage as it is a useful tool for finding untested parts of our code base. Test coverage is of limited use as a numerical statement of how good our tests are.
Use Quality Reports as Inspiration¶
goreportcard.com generates reports on the quality of Open Source Go projects. It uses several measures,
go lint and
You are welcome to support the developers on Patreon.
Not every problem reported by tools is really important and needs to be fixed immediately. Use the reports as inspiration when you need some.