Pears of Wisdom - Code Reviews

Alex Poiry
Note by Alex Poiry, updated more than 1 year ago
Alex Poiry
Created by Alex Poiry about 3 years ago


General ideas around good code review practices

Resource summary

Page 1

Code Review Steps to Consider Prepare a code review, but don't make it generally available yet. Give your brain a break then review the code yourself. As your reviewing the code make notes of the following: Does what you have written meet the definition of done? Did you add a bug? Did you get tired and code something poorly? Keep a tally of these items so you can personally track your own errors. Use this to inform future code reviews and continually improve your abilities. Did you follow best practices? Did you follow industry best practices? Did you follow language best practices? Did you follow your team's best practices? Can other people read your code?  Assume they can't and think about where people might struggle the most. Are there magic numbers/words? Is your code commented appropriately? Are there no comments or too few comments? Are there too many comments suggesting that your code is hard to understand? Are there tests? Do the tests cover the expected changes in behavior? Do the tests make sense?  E.g., are your unit tests real unit tests or are they integration tests? Have you considered edge case? Do you test bad as well as good inputs? Have you considered null cases? Go over your naming conventions and see if they make sense. Do methods, variables, and classes follow naming conventions, i.e., verb_a_noun vs. noun_verber Do names correctly indicate what the thing does, could they be misconstrued? Could the names be shortened or lengthened to be made more clear? Did you run a linter, etc.? After getting comments, have you validated that your changes work?   Brainstorm - Reviewing Code Reviews Everything committed? Commit is in correct format? Is Jira or other tracking software updated? Is the code structure correct? Did you consider other alternatives when coding, especially in libs, patterns, etc.? Did you follow OO practices?  Could something be factored out, reused, etc.? Is all documentation updated, READMEs, Javadocs, comments, etc.? Do you have the correct level of mutability? Have you considered error handling? Do your tests test something?  Or do they just exercise code?  Can your tests fail? Are their vestigial portions of code that can be removed? Can something be factored out?

Show full summary Hide full summary


Python Quiz
Kingsley Bawuah
Java & Programming Quizz
National 5 - Computing
Ryan Thompson
NMPED Professional Development
Chris Dorantes
Professional Growth
Barbara Moran
Pears of Wisdom - Java Programming
Alex Poiry
Codes and Conventions of Film Trailers
Mollie Green
Roland Barthes' 5 Code Theory
Hannah Morris
Data Structures and Algorithm analysis
Bart Allen
GoConqr Practice