We often discuss the principles we use to write what we consider good code - test-driven development, object-oriented programming, SOLID, DRY, Law of Demeter - the list goes on. Sometimes it’s useful to remind ourselves of the fundamentals.
Code makes an application work for users. Getting tests passing or removing duplication is useful, but the code needs to be shipped so that users can use it.
Code needs to work. Assuming that as a prerequisite…
When code is easy to understand, we can change or extend it faster and are less likely to make a mistake in the process. Readability counts.
When code is easy to change, we can iterate on user feedback faster.
When code is fun to work with, we’re happier. Building software is our full time job. If we go home every day feeling wrung dry, something is wrong with our process.
Yes. Following certain principles can result in shipping products faster with fewer bugs and more programmer happiness.
Test-driven development helps us understand code because we state the reason for each line of application code in the test. It also makes us happy by providing a clear process for working.
An automated test suite helps us change code because we have an early warning system when we break an existing component. It is fun to work with because we’re more confident and less fearful.
Removing duplication helps us read code by introducing semantic concepts and abstracting details. It also helps us change code by reducing the amount of code that needs to be touched for each change.
SOLID principles create individual components that help us understand code. SOLID helps us change code because components are reusable, swappable, and small.
Slow or brittle tests make code harder to change. We have to be careful about writing the correct tests and the correct amount of tests.
Code isn’t good when it’s tested, DRY, or SOLID. Code is good when it works and we can work with it. When our teammates can understand our code quickly, respond to change, and are relaxed and happy, we’re writing good code.