Recordings are available on the page, you may explore-https://practice.geeksforgeeks.org/batch/wip-1 Click on Live tab>Scroll down>explore archieved session.
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
Java Hyd Team
Photo
Telegram isn't allowing video so i will upload on YouTube directly