Pears of Wisdom - Code Reviews

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?