My Takeaways: 1) No 1 Thing to look at in Code Reviews: Readability (and Tools don't have clue) 2) Coding is nearer to Art rather than Science. Automation can help review parts of coding that are nearer to Science. 3) Best time to plant a tree is 20 years ago! The best time to bring automated reviews is Yesterday.
code review: algorithmic review, logic sequences, workflow sanity... No wonder there are that many opinions. It's code. You can not consider that language, so it's a style discussion about semantics from the getgo.
I worked for very short time in a company where code review was happening and in that brief period I learned how to replace if statements with optional for null check.
One aspect that I think is fundamental to code reviews is checking code adherence to the established architecture (considering functional and non-functional requirements). In a team, code naturally drifts apart since people have different experiences and perspectives on how to solve a problem, so it is important during the reviews to check that everyone has the same target and work within the boundaries defined by the architecture.
1. Code review is not just gatekeeping. It adds value to people and best practices beyond automation checks 2. Code review is not a science it's an art 3. Readability is utmost important, leave the code in better shape than how it was before you touched it 4. Boy Scout Rule. Keep things simple than to show off 5. Sonar, Textile, PMD, Google Java format tool, Fortify, ESlint & Tslint, setup as early as possible 6. Look at test cases for review when code flow is not clear 7. Keep the PR files short and submit often whenever possible 8. Use feature flags to add code incrementally but it depends on work culture 9. Use pair programming for complex stories. It's a balance of comments and video calls 10. Code reviews are not just finding faults but it makes you learn new things
My 3 key take aways are 1. Code checkin should be frequent so that reviewers can catch even smaller issues, easy to correct. Code review focus on whether problem is solved, efficiency, readability, maintainability is there a better way to solve problem 2. Unit test should test all cases for a problem, Logging should be ensured yo work correctly 3. Use pair programming for discussion of design and approach
My 3 takes away: 1 Readability and ensuring implementation of automations effectively, like implementation of SONAR is fine , but fixing what Sonar highlights is important :-) 2. Maintainability, exception handling for complex scenarios. 3. Constructive and appreciative feedbacks
Thank you so much..for such an open minded discussion its like sharing the experience . Please continue the serious. This are very informative discussions which opens developers minds.
My takeaways: 1. Always raise small PR's, it is easy review and fix the changes. 2. Provide proper review comment, don't provide the comment based on person. Provide comment based approach. 3. Change the developers mindset, code review is not finding faults, which well strength the code and we will gain lot of experience and learnings. Appreciate the good code or new ways of code which we might not aware before.
One of the quality gateway for a PR is qualified to merge to master is to have unittests and integration tests and code coverage should be almost 100%...
1. Code is meant to be read more than executed. So readability is paramount. And, readability over aesthetics. 2. Can you look at the logs and tell - what ops happened, what went right, what went wrong. 3. Reviews take time, and start automating reviews now if not already. Take the initiative, and dive in. 4. Unit tests shows understanding of the task. What all scenarios are covered.
Streams get a five line loop into one or two lines, lends to better concurrency performance. So a for loop isn’t necessarily a route to impress seniors
For me self review check list is very important and each developer should fill this before raise pull request for code review. In my team I implemented this and the code quality issue has reduced to 10%.
Hi Ranga/Koushik, Please guide how to prepare for an entry level architecture role interview. I have 10 plus experience in handling development experience and also a tech lead. Looking forward for your reply.
Check out the previous videos of the series here - th-cam.com/play/PLBBog2r6uMCS0FX6Ym_8NYeTNykUF5970.html
My Takeaways:
1) No 1 Thing to look at in Code Reviews: Readability (and Tools don't have clue)
2) Coding is nearer to Art rather than Science. Automation can help review parts of coding that are nearer to Science.
3) Best time to plant a tree is 20 years ago! The best time to bring automated reviews is Yesterday.
Code understand reviews
code review: algorithmic review, logic sequences, workflow sanity... No wonder there are that many opinions. It's code. You can not consider that language, so it's a style discussion about semantics from the getgo.
I worked for very short time in a company where code review was happening and in that brief period I learned how to replace if statements with optional for null check.
Great discussion. Liked the Feedback Sandwich at the end
Awesome content. Need more series with Koushik and Siva.Thank you for all of your time and knowledge.
One aspect that I think is fundamental to code reviews is checking code adherence to the established architecture (considering functional and non-functional requirements). In a team, code naturally drifts apart since people have different experiences and perspectives on how to solve a problem, so it is important during the reviews to check that everyone has the same target and work within the boundaries defined by the architecture.
1. Code review is not just gatekeeping. It adds value to people and best practices beyond automation checks
2. Code review is not a science it's an art
3. Readability is utmost important, leave the code in better shape than how it was before you touched it
4. Boy Scout Rule. Keep things simple than to show off
5. Sonar, Textile, PMD, Google Java format tool, Fortify, ESlint & Tslint, setup as early as possible
6. Look at test cases for review when code flow is not clear
7. Keep the PR files short and submit often whenever possible
8. Use feature flags to add code incrementally but it depends on work culture
9. Use pair programming for complex stories. It's a balance of comments and video calls
10. Code reviews are not just finding faults but it makes you learn new things
Thanks Ranga for arranging these awesome sessions. You very well understand what an IT Professional needs to know today to sustain.
My 3 key take aways are 1. Code checkin should be frequent so that reviewers can catch even smaller issues, easy to correct. Code review focus on whether problem is solved, efficiency, readability, maintainability is there a better way to solve problem 2. Unit test should test all cases for a problem, Logging should be ensured yo work correctly 3. Use pair programming for discussion of design and approach
My 3 takes away:
1 Readability and ensuring implementation of automations effectively, like implementation of SONAR is fine , but fixing what Sonar highlights is important :-)
2. Maintainability, exception handling for complex scenarios.
3. Constructive and appreciative feedbacks
Thank you Ranga for doing videos of this format.
This is a great discussion 🙏. Thank you so much Ranga..
Thank you so much..for such an open minded discussion its like sharing the experience . Please continue the serious. This are very informative discussions which opens developers minds.
My takeaways:
1. Always raise small PR's, it is easy review and fix the changes.
2. Provide proper review comment, don't provide the comment based on person. Provide comment based approach.
3. Change the developers mindset, code review is not finding faults, which well strength the code and we will gain lot of experience and learnings. Appreciate the good code or new ways of code which we might not aware before.
Thank you team, very useful session
One of the quality gateway for a PR is qualified to merge to master is to have unittests and integration tests and code coverage should be almost 100%...
1. Code is meant to be read more than executed. So readability is paramount. And, readability over aesthetics.
2. Can you look at the logs and tell - what ops happened, what went right, what went wrong.
3. Reviews take time, and start automating reviews now if not already. Take the initiative, and dive in.
4. Unit tests shows understanding of the task. What all scenarios are covered.
Streams get a five line loop into one or two lines, lends to better concurrency performance. So a for loop isn’t necessarily a route to impress seniors
How much time should be allocated for code review and how agile can be better used to control code review cycles
Nice discussions
For me self review check list is very important and each developer should fill this before raise pull request for code review. In my team I implemented this and the code quality issue has reduced to 10%.
Hi Ranga/Koushik,
Please guide how to prepare for an entry level architecture role interview. I have 10 plus experience in handling development experience and also a tech lead. Looking forward for your reply.
Can you please create a session on design patterns as well.
With real life example
Good session.
Great on going knowledgeable session :)
Pls make a video on most used productivity tools in linux envir, like Some useful packages
Thank you❤
What is that main challenge to be an architect
Please check the first videos of the series - th-cam.com/play/PLBBog2r6uMCS0FX6Ym_8NYeTNykUF5970.html
Kowshik looks quite similar to sundar pichai. Agree?
1 comment❤️❤️
Very informative 👌🏽