Some heuristics I find useful at work. Something like this, but dumbed down and more concise.
These are not meant to be dogmas but general rules of thumb that should help you be a better dev. Ditch them as soon as they donât.
Fast Feedback
Both at small (TDD) and large (CD) scale.
Donât just think itâs OK, actually see if it is in practice.
Expect fuckups to occur, try to know about them fast.
Baby steps
Refactoring
Start small, even if small means apparently irrelevant, peripheral changes (variable names, directory structure, etc.).
New Feature
Find the smallest meaningful piece of the system and build up from there.
Complexity
The root of all evil. It is sometimes necessary, but often accidental.
Be skeptical of the former and avoid the latter at all cost.
Divide and conquer
Split everything up as much as possible, even if it seems absurd.
As long as it doesnât take more effort to split the task than to actually do it, the smaller, the better.
Decide as late as possible
Chances are, the later you decide, the more knowledge and experience you have.
Anything that can be decided further down the road without causing a major setback, should.
Respect the Legacy
We know at least two things about all Legacy Code:
- It works.
- It makes money.
Respect Legacy Code and the people who wrote it.
Go fast, write great code
The only sustainable way to go fast is writing great code.
The only sustainable way to write great code is going fast.
Start anew
Donât build the project of tomorrow with the crap from yesterday.
Listen to your gut feeling
Donât dismiss it with a âmeh, it worksâ.
If you feel something could be better, make it better.
Be water my friend
Flexible with other peoples code.
Strict with yours.
Commits
Keep âem coming and keep âem small.
Think of them as checkpoints, safe states you can return to. You can always squash them later.
Boy Scout Rule
Leave the system (code, docs, etc.) better than you found it.
Code
Readable
Code for other people, not for the CPU.
Naming is not relevant
Itâs extremely important.
Simplistic naming
Complex naming schemes might indicate inadequate modelling.
Expl!c!t language
When in doubt be explicit.
Boring, repetitive, predictable
Boring code is good code.
No surprises, no âWTFâ.
Write code like a manual
Show what it does and how to use it.
Hide how it works.
Syntax
Nouns for classes.
Verbs for functions.
Adjectives for interfaces.
Design
Unix
Do âone thingâ, do it well.
Abstract dependencies
Depend on abstractions, not concretions.
Extend existing behavior
Donât modify it.
Coupling and Cohesion
They are the same thing. The latter just has some though into it.
Demeter, donât ask
Units (classes, modules, functions) should talk to one another only if they share the same concern, and in such a way that keeps them ignorant of one anotherâs inner workings.
Avoid changes in abstraction levels
They are hard to follow and indicate that something might need to be in a different layer.
Avoid generalizations
They are easy to build but a pain to remove.
Donâts
Donât do a perfect job
Perfection is hardly relevant. A bad test is better than no test.
Donât waste time and mental space on perfection.
Donât follow the rules
Follow the principles.
Donât be clever
Donât get fancy. Keep it simple.
Donât be an âarchitectâ
Bug-less code with meh-architecture is better than awesome architecture with buggy code.
Donât fear duplication
Itâs better than poor abstraction.
The DRY principle is about avoiding duplicate logic or knowledge.
Duplicate lines might imply logic duplication, but they might not.
Donât test someone elseâs code
Either trust the framework/library or chose another one.
If you canât trust it, donât depend on it.
Donât get sentimental
No emotional attachment to code. Not to yours, not to others.