Perfect summary !
In the "1. Bugs" section we can add security issue (a kind of bug rarely tested in the continious integration).
Another advantage to do code review is it require to make small (atomic) commits and focus on separate your massive code into a list of structurated commits. So we avoid mixing "typo fix" and algorithm implementation.
Sadly we don't do code review in my team but checking your coworker code can be done without allocated time ;)
Thank you, Jeff!
May I ask why you're not doing code reviews? Did your team try and cancel, or someone doesn't like it at all, or the company culture doesn't allow you, or the stage of the project, or smth?
In the first team, one week after I joined I started writting code, before my first commit my team leader started complaining about everything ("Remove this space", "variable must be used more than one time", "this loop is not performant", "this variable name is not good" ...). I through I'll get fired but I stay. Since this time I review my code before each commit. In this team we made review but it was not in the process, it was our personnal initiative (when someone worked on a big feature or had bug).
In the second team we had no quality (no unit-tests) so ...
In the third team (my current one) we "have no time", but I don't make this suggestion because some of my coworker love refactor every line of code they saw. I think it will not be as positive :$
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Perfect summary !
In the "1. Bugs" section we can add security issue (a kind of bug rarely tested in the continious integration).
Another advantage to do code review is it require to make small (atomic) commits and focus on separate your massive code into a list of structurated commits. So we avoid mixing "typo fix" and algorithm implementation.
Sadly we don't do code review in my team but checking your coworker code can be done without allocated time ;)
Thank you, Jeff!
May I ask why you're not doing code reviews? Did your team try and cancel, or someone doesn't like it at all, or the company culture doesn't allow you, or the stage of the project, or smth?
In the first team, one week after I joined I started writting code, before my first commit my team leader started complaining about everything ("Remove this space", "variable must be used more than one time", "this loop is not performant", "this variable name is not good" ...). I through I'll get fired but I stay. Since this time I review my code before each commit. In this team we made review but it was not in the process, it was our personnal initiative (when someone worked on a big feature or had bug).
In the second team we had no quality (no unit-tests) so ...
In the third team (my current one) we "have no time", but I don't make this suggestion because some of my coworker love refactor every line of code they saw. I think it will not be as positive :$