13 Simple Rules for Good Coding (from my 15 years of experience) - By
Simple REST API for $0 Trading 13 Simple Rules for Good Coding (from my 15 years of experience)
January 9th 2017
Hi guys, i work as a programmer more than 15 years and was using many different languages, paradigms, frameworks and other shit. And i want to share with you my rules of writing good code.
- Optimization VS Readability. Fuck the optimization.
Always write code that simple to read and which will be understandable for developers. Because time and resources that will be spent on hard readable code will be much higher than what you get from optimization.
If you need to make optimization, then make it like independent module with DI, with 100% test coverage and which will not be touched for at least one year. - Architecture first.
I saw many people who was saying "We need doing things fast we have no time on making architecture". And about 99% of them got big problems because of such thinking.
Writing code without thinking of its architecture is useless in the same way as dreaming about your desires without a plan of achieving them.
Before writing the first line of the code, you should understand what it will be doing, how, what it will use, how modules, services will work with each other, what structure will it have, how it will be tested and debugged, and how it will be updated. - Test coverage.
Tests are good thing but they are not always affordable and make sense for the project.
When you need tests:
- When you are writing modules, micro-services which will be not touched for at least one month.
- When you are writing open source code.
- When you are writing code that touches financial channels.
- When you have resources for updating tests at the same time as code was updated.
When you don't need test:
- When you are a startup.
- When you have small team and code changing is fast.
- When you write scripts that can be simply tested manually by their output.
Remember that code with badly written tests can be more harmful then code without tests. - Keep It Simple, Stupid.
Don't write complex code. More it simpler then less bugs it may have and less time needed to debug them. Code should do only what it need without tons of abstraction and other OOP shit (especially it concerns java developers) + 20% of things that may be needed in future to update it in simple way. - Comments.
Comments showing bad code. Good code should be understandable without a line of comments. But what to do to save time for new developers? — Write simple inline documentation describing what and how method work. This will save much time for understanding and even more — it will give people more chances to come up with better implementation of this method. And also it will be good start for global code documentation. - Hard coupled VS Less Coupled.
Always try to use micro-service architecture. Monolithic software can run faster than micro-service software, but only in the context of one server.
Micro-services give you possibility to distribute your soft efficiently not only on many servers but sometimes even on one machine(i mean process distribution).
Read full article from 13 Simple Rules for Good Coding (from my 15 years of experience) - By
No comments:
Post a Comment