Contents
YAGNI (You aren't gonna need it)!
YAGNI principle means do just what you need at the moment. Don't put any efforts on useless things.
The effects of following YAGNI principle are better code and faster implementation.
Following the principle lets you get rid of extra functionality and extra complexity. It's about how to keep things simple.
YAGNI means don't waste your time at the moment and don't steal your time in the future. If you need something in a week or later than you just do it in a week or later.
You have a minimum of a code. Upfront thinking with guesses can pollute the code with unreasonable abstractions and useless complexity.
YAGNI has an important side effect you should remember. Simple implentation requires a detailed description of a functionality and a required result. Short iterations help you to decrease a value of this effect.
What to do next once implementation is done?
- It is done.
- Is it slow?
- No, it's fast enough.
- Than just keep it as is.
- OK, it is slow.
- Try to make it faster.
- Actually, not really too slow.
- Then just keep it.
- But It can work better.
- Is it needed now?
- No.
- Keep it.
- Hm.. Yes, it is needed now.
- OK. Improve it.
- I'm not sure if we needed it.
- Keep it and ask people who is responsible for planning.
The best things to optimize are smells in a code.
Duplicated code. Lots of duplications are dangerous and time wasting. Don't collect them. Extract a method or a class to save your time in the future.
Conditional complexity and nested conditions are hard to read. Usually we are spending 90% of our time reading the code. Don't keep it hard to read. Make a named operation and don't make you to remember your decision. Extract a method to save your time on replacing one conditional with another one faster.
Don't use comments a lot. They starts to lie during the time. Remove a comment and make it a part of an active code, make it readable and replaceable code. People don't always read comments as a part of a passive code. Just remove them and don't let them to lie in the future.
Temporary fields. Watch out of low cohesion and extra or optional fields. Remove them if it is possible and a code stays readable without them.
Combinatorial Explosion. It's a kind of a duplication. Keep it simple. Use the previous or the best method in all places if it is possible.
Feature Envy. It's a real time bomb. You become dependent of the envy usage. Don't let high cohesion to make things complicated. There should be only a single responsibility to edit the module. Prefer aggregation to inheritance. Move envy method or extract it.
Remember things change. Something looks important today but tomorrow it becames useless. Making all implementation as a proof of concept can help you to start replace and refactor instead of rewrite everything.