Code reviews should take place when the development is complete and before the programmer of the code passes the code on to the QA department. Before any code is checked into version control, all the code should build and run without errors, warnings, or information. You can ensure this by doing the following:
- You should run static code analysis on your programs to see whether any issues are raised. If you receive any errors, warnings, or information, then address each point raised. Do not ignore them as they can cause problems further down the line. You can access the Code Analysis configuration dialog on the Code Analysis page of the Visual Studio 2019 Project Properties tab. Right-click on your project and select Properties | Code Analysis.
- You should also make sure that all your tests run successfully, and you should aim to have all your new code to be fully covered by normal and exceptional use cases that test the correctness of your code against the specification you are working on.
- If you employ a continuous development software practice within your place of work that integrates your code into a larger system, then you need to make sure that the system integration is successful and that all tests run without failing. If any errors are encountered, then you must fix them before you go any further.
When your code is complete, fully documented, and your tests work, and your system integration all works without any issues, then that is the best time to undergo a peer code review. Once you have reached the point that your peer code review is approved, your code can then be passed on to the QA department. The following diagram shows the Software Development Life Cycle (SDLC) from the development of the code through to the end of the life of the code:
The programmer codes the software as per specifications. They submit the source code to the version control repository and issue a pull request. The request is reviewed. If the request fails, then the request is rejected with comments. If the code review passes, then the code is deployed to the QA team that carry out their own internal testing. Any bugs found are raised for the developers to fix. If the internal testing passes QA, then it is deployed into User Acceptance Testing (UAT).
If UAT fails, then bugs are raised with the DevOps team, who could be developers or infrastructure. If UAT passes QA, then it is deployed to staging. Staging is the team responsible for deploying the product in the production environment. When the software is in the hands of the customer, they raise a bug report if they encounter any bugs. Developers then work on fixing the customer's bugs, and the process is restarted. Once the product reaches the end of its life, it is retired from service.
