Let’s imagine the following situation. You wrote the code and sent it to review. During the review, you were indicated for an error in the code and returned the task for revision.
Here we do not consider errors in the business logic of the written code-only errors at the level of the interpreter/compiler, due to which the application ‘falls’.
What should not be done
No need to obediently correct the indicated error and send the task to a repeated roar. Then wait for further fate and hope that reviewers will find anything else and miss the code further.
And you still do not need to make excuses. Everyone has an excuse (I’ll reveal a secret: the reviewer is not interested in why you made a mistake. First of all, it should be interesting to you personally – to draw the right conclusions so that such an error does not repeat).
What should be done
- No need to correct the error right away. Check the performance of the entire code. I repeat – check the performance. And correct all the mistakes caught.
- Go through the code by all possible leinners and analyzers (a leinter is like an automatic spelling check in MS Word, only for code).
- Run the code again (locally, at the test booth, somehow).
- “Chase” the code on various data. Talk to the director or tester to get the entrance data close to reality for testing.
- Correct the mistakes found.
- Repeat all the above.
Why?
The presence of an error is an occasion to think that the code is poorly tested by the developer himself. But the direct duty of the developer is primarily the provision of a working code.
Testers check the correctness of business logic, boundary and non-standard values. But only on the condition that the code works and can start on a test stand.
So, you need not only to correct a mistake but also to check the performance of your code. Each of its lines. And make sure that your code did not affect another functionality.
Remember: your colleague-revolutionary is not a linter. His duties do not include a constructive check of code for syntactic errors.
The role of a tester
The goal of the review is to look at your decision with a “fresh” look or from the perspective of experience and point out the moments of implementation that you did not take into account. But in no way search for errors at the code level.
And the task of the tester is to check the code for compliance with business requirements, as well as make sure that the new functionality did not damage stable nodes.
Of course, there are companies where the reviewer will run throughout the code and indicate in detail all the mistakes they found. But this is quite rare.
Conclusion
Of course, there are situations when the developer comes from the developer. No one has canceled force majeure, fatigue and inattention. But if such situations are repeated regularly, then this is a significant blow to your reputation as a developer.
Reviewers do not want to constantly be a nanny – they also want to fulfil their tasks, and instead, they are distracted by finding errors in your code.
There are errors in operating systems, compilers, frameworks and libraries, and your program can be correct. But the chances of attracting the developer’s attention to these errors are small if you cannot provide a detailed algorithm for playing them. A friendly developer can help you with this, but most often, if the problem is difficult to reproduce you simply ignore it.