*Reasons For Code Reviews* 1. To ensure consistent application of best practice in coding throughout the group/organization. 2. To explain each team member's code to all others: team members get better vision of entire system. 3. To avoid over-dependence on group leader for system overview or integration bugs. 4. To provide basis for discussions on code between team members so as to stimulate new ideas. 5. To avoid coder's blind spot, i.e. inability of authors to see their own coding limitations or biases. 6. To reach a more objective idea of code readability. What's clear to one coder may not be to others. 7. To amend inadequate tests for the code.
6:26 bike shedding is not nitpicking It’s making suggestions that are “At least something” but not actually helping improve the core solution Basically instead of addressing an actual problem, make suggestions that take the project in a different direction Suggesting technical changes that do not address the actual problem Seeing all problems as nails when you are an expert at hammering kind of thing
After my third video looking for a concise explanation on best practices for code reviewing , I can say you got to the point right away and really well explained, thanks for this!
Just wanted to have an insight . What ate the most common problems/mistakes are pointed out by reviewers I have just got to check null pointer exception
*Reasons For Code Reviews*
1. To ensure consistent application of best practice in coding throughout the group/organization.
2. To explain each team member's code to all others: team members get better vision of entire system.
3. To avoid over-dependence on group leader for system overview or integration bugs.
4. To provide basis for discussions on code between team members so as to stimulate new ideas.
5. To avoid coder's blind spot, i.e. inability of authors to see their own coding limitations or biases.
6. To reach a more objective idea of code readability. What's clear to one coder may not be to others.
7. To amend inadequate tests for the code.
6:26 bike shedding is not nitpicking
It’s making suggestions that are “At least something” but not actually helping improve the core solution
Basically instead of addressing an actual problem, make suggestions that take the project in a different direction
Suggesting technical changes that do not address the actual problem
Seeing all problems as nails when you are an expert at hammering kind of thing
After my third video looking for a concise explanation on best practices for code reviewing , I can say you got to the point right away and really well explained, thanks for this!
thank you for this! I am a Codecademy FSE student, currently at 20%
7% :0
@@rockyvolcano122 13%! :)
Yes, the communication part is very important (2 and 5)!
I think that you meant `Increase Bus Factor` instead of `reduce buss factor` !! Am I missing something ?
Very informative and clear video, thank you very much for this!
Thank you for sharing such nice tips on code review.
Just wanted to have an insight . What ate the most common problems/mistakes are pointed out by reviewers I have just got to check null pointer exception
Thank you
important thnks
Thank you!
Thanks!
thanks
Please add CC for deaf viewers
thank U
great
The level of sus when boss requests code review from junior 🧐
Philly
this code sucks lol
ur mum sucks
I'm trying to learn HTML and CSS.
How's it going?
@@PierreLaBaguette I'm doing okay.
Thank you!