How can you make your code/service more stable?

I separate this by 3 part :

1. Code stability.
2. Easy integration.
3. Monitoring.

Code stability.

About unit test all know, but formal unit tests responsible for only freeze code behavior. You spend time to test, you spend time when you change code. And no one guarantees that this code works correctly.

To make unit test effective you need to step backward and focus on the code.

For my mentee I highlight a couple things.

1. Use libraries if possible. Even if you know that it is too big to use - please explore its architecture and code. In any case you will know something new. Maybe repeating it will be easier for you. Maybe you will realise that you can’t repeat it having the week for implementation the same as work as someone spent years.?
2. Never write code “for future”, without using it at a business level - now or soon. It has one exception, when we have specs and it is a business requirement. For example, we making library for another company.?
3. If you know tenses rules while learning foreign language it means that you know the rules and no one guarantees that you can write. If you know what SOLID means, but have no expense discussion about it on review, if you don’t think about solid when you are сoding… The same - it doesn’t work. Practice it.
4. Think about implementation before starting coding. One way to do it - write a simple example of implementation before.??
5. Write code simple as is possible when business needs are not clear, or you still don`t know what you will write. If you have duplicates, do not hurry to extract common code. When you don’t know now what this code needs to do, extracting is easy but makes further changes more difficult. “In the future I just change one function and change behavior” is a trap. You will add functionality and args again and again. This code will be your nightmare. Only when you are sure what you need - kill duplicates.??
6. Prepare to refactoring duplicates of code - make all similar code similar. It is not a book, you don’t need variety. Every common line helps you in refactoring when you will know architecture. Maybe you will know it after you almost finish the task - it is ok, refactoring code coding process. Don't be afraid of redundancy. Сode should read like a poem, not like a book.
7. Count places where we can catch the bug. If a function uses 1 external service and 2 internal functions we have at least 3 possible bug sources. It is called a side effect. If you have a clear function - it means that we don’t call any external function, don’t change any external variable. Clear function getting arguments and return data. Nothing else. Percent of code with side effects is one of the stability metrics.
8. Inheritance has logarithmic complexity. It is a good instrument. But be careful with it. If you can replace class by a couple clear functions - do it.
9. One line function with call another function with call another function with call another function with call another function not is a “SOLID first principle”. It is alien`s egg. It will kill you or your colleague. Inline it please. Just inline - it is enough to transform terrible code to reasonable.?
10. Don’t try to write perfect code in the first attempt. Don’t try to refactor from bad to good code in one step. Reasonable will be enough. The project with only reasonable code quality is better than a project with bad code. No one can be perfect for the first try (except Linus Torvalds), but you will spend time. Time is limited. Maybe code will die because business requirements changed, maybe budget will end, maybe competitors?release before you and the project just will be canceled.
11. Code has not only algorithmic complexity, it has logic complexity. One architecture/implementation has linear complexity. Another - arithmetic complexity. And logarithms complexity also exist. No one of its is bad, no one method is perfect. Maybe you need to start fast. If you work on a small project / business prototype then logarithmic complexity will be the perfect choice. For middle size - arithmetic complexity. For the long term good choice linear as it is possible, but it takes time at the start.?

The same rules work for stability requirements - non predictable speed of performance with code with logarithms complexity is not about stability and quality:) Also you can lose key developers - they don’t like when every change is it like a visit to hell. You will lose control of code in this case.

To be continued…