Even if you and your team have not implemented code review in their daily work you should keep in mind that someone will review your code over and over again under it’s lifetime, and you will have to face criticism about one or more of the following points:
- Bad coding.
- Not following standard.
- Bad performance.
- Not appropriate comments.
- Poor readability.
- Access modifiers (public/private/protected/default).
- Hard coded values.
- Poor error handling.
- No modularity.
- Repeated code.
- Entanglements.
- Bad naming of classes/methods.
It’s a lot to think about when writing code, specially because you also need to solve problems, design and create architecture, understand others legacy code and try to integrate you solution to another piece of code or system, and in the same time you need to do it fast and without bugs.
So if you would like to not getting a lump in your stomach whenever the team is introduced to a new developer and you need to show him/her what you have been working on for the past year, keep the above points in mind and start reviewing your own code.
Start to take your time, it will be cheaper in the end and less stressful, and you will feel more proud and confident about you and your work.
