One Diagram to Remember for Cš¼š±š² Rš²šš¶š²šš
An essential step in the software development lifecycle is code review. Code reviews are powerful means to improve code quality, establish best practices, opportunity to learn, and knowledge sharing and mentoring, as well as promotes team cohesion.
What to look for in a code review? Try to look for things such as š±š²šš¶š“š» (does this integrate well with the rest of the system and are interactions of different components make sense), š³šš»š°šš¶š¼š»š®š¹š¶šš (does this change is what the developer intended), š°š¼šŗš½š¹š²š š¶šš (is this code more complex than it should be), š»š®šŗš¶š»š“ (is naming good?), š²š»š“. š½šæš¶š»š°š¶š½š¹š²š (solid, kiss, dry), šš²ššš (are different kinds of tests used appropriately, code coverage), šššš¹š² (does it follow style guidelines), š±š¼š°ššŗš²š»šš®šš¶š¼š», etc.
Code review is a conversation, not a queue of commands.
Code review checklist
A checklist helps you to create a structured approach to code reviews. Also, they remind you of all the quality checks you need to perform to approve code into the codebase.
š. š§šæš šš¼ šæš²šš¶š²š šš¼ššæ š¼šš» š°š¼š±š² š³š¶šæšš
Before sending a code to your colleagues, try to read and understand it first. Then, search for parts that confuse you.
š®. šŖšæš¶šš² š® ššµš¼šæš š±š²šš°šæš¶š½šš¶š¼š» š¼š³ ššµš®š š¶š š°šµš®š»š“š²š±
It should explain what changes were at a high level and why those changes were made.
šÆ. šššš¼šŗš®šš² ššµš®š š°š®š» šÆš² š®ššš¼šŗš®šš²š±
Leave to the system everything that can be automated,
PMD, FindBugs, and Checkstyle are the most popular open-source code analyzers,
Jenkins for CI-CD some code smells and bugs (SonarQube).
š°. šš¼š»'š šæšššµ
You need to understand what is changed in every line of it. Read multiple times if required, class by class.
š±. šš¼šŗšŗš²š»š šš¶ššµ šøš¶š»š±š»š²šš
Never mention the person (you), always focus on changes as questions or suggestions and leave at least one positive comment. Explain the "why" in your comments and suggestions for improving it.
š². šš½š½šæš¼šš² š£š„ ššµš²š» š¶šš š“š¼š¼š± š²š»š¼šš“šµ
Don't strive for perfection, but hold to high standards. Don't be a nitpicker.
š³. š š®šøš² šæš²šš¶š²šš šŗš®š»š®š“š²š®šÆš¹š² š¶š» šš¶šš²
We should limit the number of lines of code for review in one sitting. Our brains cannot process so much information at once. The ideal number of LOC is 200 to 400 lines of the core at one time, which is usually 60 to 90 minutes.
8) Review logic, not semicolons
Automation reduces the needless checks and let's you focus on the logic behind the changes rather than syntax errors and typos.
What is your code review process? What works for you, and what does not?
Image credit (Code Review Pyramid): Gunnar Morling
#softwareengineering #programming #systemdesign #developers #bestpractice #coders #software #review #codereview
An essential step in the software development lifecycle is code review. Code reviews are powerful means to improve code quality, establish best practices, opportunity to learn, and knowledge sharing and mentoring, as well as promotes team cohesion.
What to look for in a code review? Try to look for things such as š±š²šš¶š“š» (does this integrate well with the rest of the system and are interactions of different components make sense), š³šš»š°šš¶š¼š»š®š¹š¶šš (does this change is what the developer intended), š°š¼šŗš½š¹š²š š¶šš (is this code more complex than it should be), š»š®šŗš¶š»š“ (is naming good?), š²š»š“. š½šæš¶š»š°š¶š½š¹š²š (solid, kiss, dry), šš²ššš (are different kinds of tests used appropriately, code coverage), šššš¹š² (does it follow style guidelines), š±š¼š°ššŗš²š»šš®šš¶š¼š», etc.
Code review is a conversation, not a queue of commands.
Code review checklist
A checklist helps you to create a structured approach to code reviews. Also, they remind you of all the quality checks you need to perform to approve code into the codebase.
š. š§šæš šš¼ šæš²šš¶š²š šš¼ššæ š¼šš» š°š¼š±š² š³š¶šæšš
Before sending a code to your colleagues, try to read and understand it first. Then, search for parts that confuse you.
š®. šŖšæš¶šš² š® ššµš¼šæš š±š²šš°šæš¶š½šš¶š¼š» š¼š³ ššµš®š š¶š š°šµš®š»š“š²š±
It should explain what changes were at a high level and why those changes were made.
šÆ. šššš¼šŗš®šš² ššµš®š š°š®š» šÆš² š®ššš¼šŗš®šš²š±
Leave to the system everything that can be automated,
PMD, FindBugs, and Checkstyle are the most popular open-source code analyzers,
Jenkins for CI-CD some code smells and bugs (SonarQube).
š°. šš¼š»'š šæšššµ
You need to understand what is changed in every line of it. Read multiple times if required, class by class.
š±. šš¼šŗšŗš²š»š šš¶ššµ šøš¶š»š±š»š²šš
Never mention the person (you), always focus on changes as questions or suggestions and leave at least one positive comment. Explain the "why" in your comments and suggestions for improving it.
š². šš½š½šæš¼šš² š£š„ ššµš²š» š¶šš š“š¼š¼š± š²š»š¼šš“šµ
Don't strive for perfection, but hold to high standards. Don't be a nitpicker.
š³. š š®šøš² šæš²šš¶š²šš šŗš®š»š®š“š²š®šÆš¹š² š¶š» šš¶šš²
We should limit the number of lines of code for review in one sitting. Our brains cannot process so much information at once. The ideal number of LOC is 200 to 400 lines of the core at one time, which is usually 60 to 90 minutes.
8) Review logic, not semicolons
Automation reduces the needless checks and let's you focus on the logic behind the changes rather than syntax errors and typos.
What is your code review process? What works for you, and what does not?
Image credit (Code Review Pyramid): Gunnar Morling
#softwareengineering #programming #systemdesign #developers #bestpractice #coders #software #review #codereview