Code quality is one of the biggest thing in the market right now. The more scalable, maintainable and decoupled code you write the more value you will be offered. There are some things that we should follow to review our code and raising a pull request.
1. Readiblity
Do not write complex code. Always write code which is simple to read and easy to understand from other developers. Remember to follow language conventions.
Simple code is less prone to bugs and it is easy to debug simple code.
More things to follow:
- Always follow consistent naming conventions.
- Variable and method names should be descriptive.
- Proper indendation.
2. Code Design
I have seen many people saying "We do not have enough time to make code plan". About 99 percent of People having such thinking faces big problems.
Writing code without disigning the architecture or plan is similiar to those desires, we do not have plan to achieve them.
Before starting to write your code, you shoud have in mind what your code will be doing, hou it will work and what libraries/modules it is going to use. Also, keep in mind about testing and debugging of code.
3. Test Cases
Test cases are good for projects. But writing test cases with 100% code coverage is not always affordable.
Scenarios when you need tests with higher coverage:
- when you are writing code for micro services/ modules which is not going to be touched for long time.
- While writing open source code.
- while writing code for financial channels.
Always remember that code having bad test cases can be more dangerous than code with no test case.
4. Code coupling
You should always try to follow micro service architecture. A monolithic program can have less run time than a program having micro service architecture, but only when you are thinking of running one server. Micro service architecture gives you the flexiblity of distribute service on different servers.
5. Do not write code in bad mood
In bad mood or tired state, developers makes 2 to 5 times more mistakes compare to the state having full energy. So, working more hours is not good for a developer. This is the reason more countries are thinking about making 6 working hours in a day. Working with mind is not same as working with your muscles.
6. Code review
There can be good or bad code reviews. You can only assign a developer to code review is he/she understands 95 percent of the code.
Main target of code review should be maintaing code quality and performance rather than a way to teaching to new tech guy.
7. Use version control system
While coding there will be times when you will be in a situation that you have made a huge mistake and now you want to rollback the whole code to go back on a pervious version of code. Now what you will do if your mistake involves various files in the codebase. The best possible solution is to use VCS and commit all the running states of code. This will make it easy to rollback on the earlier version in the situation of mistakes.
- Whenever you got free time, utilize it to learn new things. Performance starts to degrade when people stops learning.
More CONTENT to COME....STAY TUNED!