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