How do you code review large or complex changes without getting overwhelmed?

1 Break it down

The first step to code review large or complex changes is to break them down into smaller and manageable chunks. Ideally, the author of the change should do this before submitting it for review, by splitting the work into multiple commits, branches, or pull requests that each address a specific task, feature, or bug. This way, you can review each chunk separately, focus on one aspect of the change at a time, and provide more meaningful feedback. If the author did not do this, you can ask them to do so, or use tools like git diff or code review platforms to filter or group the changes by file, function, or module.

2 Understand the context

The next step is to understand the context and the purpose of the change. Why was it made? What problem does it solve? How does it fit into the overall project or system? You can get this information from the change description, the commit messages, the issue tracker, or the documentation. You can also ask the author for clarification or explanation if anything is unclear or missing. Understanding the context will help you evaluate the change from a high-level perspective, and check if it meets the requirements, follows the design, and aligns with the goals and vision of the project.

4 Review the style

The fourth step is to review the style and the readability of the change. How is it written? Is it clear, consistent, and easy to understand? Does it follow the coding standards, conventions, and best practices of the project? You can review the style by looking at the formatting, naming, commenting, and structure of the code. You can also use tools like code linters, formatters, or style guides to check for common issues like indentation, whitespace, or naming inconsistency. Reviewing the style will help you improve the maintainability, readability, and quality of the code, and ensure that it is easy to modify, reuse, or extend.

5 Review the impact

The fifth step is to review the impact and the compatibility of the change. How does it affect the rest of the project or system? Does it introduce any breaking changes, dependencies, or conflicts? Does it work well with different environments, platforms, or configurations? You can review the impact by looking at the documentation, the configuration, the deployment, or the integration of the change. You can also use tools like code review platforms, continuous integration, or continuous delivery to check for common issues like merge conflicts, build failures, or test failures. Reviewing the impact will help you ensure that the change is compatible, stable, and scalable, and that it does not cause any unexpected problems or side effects.

6 Communicate feedback

The final step is to communicate feedback and suggestions to the author of the change. How do you convey your opinions, questions, or concerns? How do you provide constructive and respectful feedback? You can communicate feedback by using clear, concise, and polite language, by explaining your reasoning and providing examples or references, by focusing on the code and not the person, by acknowledging the positive aspects and the efforts of the change, and by using tools like code review platforms, comments, or emojis to facilitate the communication. Communicating feedback will help you collaborate with the author, resolve any issues or disagreements, and reach a consensus on the change.