Post on 17-Jan-2017
transcript
HOW HAVE WE DEVELOPED PRODUCT WITHOUT BUGS
What is all this about?
We have developed product of very high code quality
How did we succeed?
WHAT DOES WELL-DONE PIECE OF MECHANICS LOOK LIKE?
ADVICE #1
General rule Do the simplest thing possible. Simplest solutions, simplest code, simplest
abstractions
Your interfaces should contain as little as possible
But it's very difficult to be simple
ADVICE #2
Write immutable. Write error-prone 95% of your code can and should be immutable. I mean, class fields
declaration should start with
public class … {
private final ...
ADVICE #3
Do love code deletion
ADVICE #3
Less code: Easier to understand
Less places to mistake
C'mon it's statistics! Bugs are in the code. Less code → less bugs
Yes, that means you can never repeat yourself in the codebase
ADVICE #4
Do code review. No, really, DO it. Even if it takes time.
Small PRs (5-7 classes per PR)
Process of Code Review should become quite similar to writing the code
It has to be easy to understand the code for reviewer
Short classes, small methods
Yes, it takes time! You need to pay for quality
ADVICE #5
Test it
If something has no test, it doesn't exist
If your method has an “if” in it, probably it has a bug!
Even if this test looks obvious and too simple, it wont when your program grows 1000 times
Make no assumptions. Test it before rely on it
ADVICE #6
“Premature optimization is the root of all evil.”Donald Knuth, Turing Award Lecture 1974
Do not optimize unless its unavoidable
Use human-readable formats, ignore binary
ADVICE #6
It's disputable, but it worked for us
ADVICE #7
Dependency Injection
Approach is good, but do you need managed context for this?
Can you create architecture which doesn't need it?
ADVICE #8
Watch for your libs
Ask yourself if using this particular lib worth it?
It's not good to have 4 different JSON libs in one project. Definitely not the simplest way of dealing with JSON
ADVICE #9
I am kinda obvious, but still...
Use CI and CD
SOLID
Good logging
Use self-descriptive names
ADVICE #10
Validate inputs
ADVICE #11
Restrict requirements
Wait before implement new feature. Maybe you don't need it
If some new user's requirement harms your architecture, maybe user don't need it
Or maybe its a place for new project
Or maybe you should change your product indeed :)
ADVICE #12
You are a human being
Never deliver on Friday
Take pauses. It's OK to think about best architecture and write no code for hours or days if you need to. It's worth it
P.S.
Several words about Scala...
Q&A