The Art of the Code Review

Great developers continually seek to improve the code they work on and write. We discuss a few different scenarios, outside the formal “Code Review” that can provide you a chance to improve your code. From there we outline benefits reviewing code offers to not only reviewees and reviewers, but also teams and projects. Finally we provide five general guidelines you can follow to make every code review a positive learning experience. Types of code reviews Formal “Code Review”: Evaluating code and its purpose with another developer(s). Part of the QA process: reviewing code output. Automated reviews: automated testing, linters, performance benchmarking Pair programming: Writing code with another developer PR reviews: submitting code to be merged into a project by another developer. Benefits of code reviews Project benefits: Keeps project codebase clean and stable. Team benefits: Aligns team members on coding standards and shares knowledge. Reviewee benefits: Enforces code quality and improves making common mistakes Reviewer benefits: Provides visibility into other methods of approaches. General code review guidelines No bad attitudes: Keep a positive mindset, code reviews are a learning experience. Set goals: what is the purpose of this code review? Less is more: No more than 400 lines at a time, 30 - 60 minutes max. Annotate: Keep code commented to provide information about what it does. Document: Outcome of code review, action plan of next steps. Listener Challenges Next time you work on a piece of code, try to leave it better than you found it. Sr. Developers, have a Jr. Developer review some of your code. Jr. Developers, ask a Sr. Developer to sit with you and review a some of your code. Links from this episode Best Practices for Code Reviews Previous episodes mentioned Leading by Example To get more done as a developer you need a personal task management system