How do you review code with your team?

Code review is a human-driven process. Human input is important and will always remain important. However, it’s worth exploring ways to automate certain aspects of the code review process whenever possible. By automating mechanical tasks, we can save time and effort. Investing in the right tools can bring significant benefits. For example: ✅ Static Code Analysis Tools can help you find many issues in your code, like, security issues, redundant code, technical debt, etc. ✅ Prehooks can automatically run all tests, linters, formatters, or code review tools. These can be triggered at the point of commit (pre-commit, post-commit), merge (pre-submit), etc. Authors can get reviews on their code before passing it to the human reviewer.

my teamwork Reviews code in following ways: Automated Tools: We utilize automated code analysis tools and linters to catch common issues and ensure adherence to coding standards. Documentation: Detailed documentation and comments in the code help reviewers understand its purpose and functionality. Version Control: We use version control systems like Git to track code changes, making it easier to review and revert if needed. Code Review Tools: We employ code review tools such as GitHub, GitLab, or Bitbucket to streamline the process and track comments. Testing: Code reviews may involve testing the code changes to ensure they work as intended.

Code reviews serve more than one purpose. First, and foremost, they ensure quality and standards. A secondary benefit is teaching others. Whether a team member is brand new, or tenured, there is always something to learn when it comes to developing solutions. As humans, we all approach solutions differently. There is always a new perspective that can help others grow in their technical skills.

Code review literally implies "review by a human", a colleague, a teammate, or another developer. It helps to keep the code quality and compliance tools out of the discussion since it makes sense to automate as many aspects of quality assurance as you can before executing a human review. So to find out what the objective of a code review is, think of things that automation cannot add to the quality of production code. Also don't forget that code review is not just another QA process, it's also a process of collaboration to continuously improve team coherence and solutions.

My team have found Bitbucket as a useful tool for code reviews. Peers review codes, make comments and approve changes where accepted by a majority. Some automation such as tests have also been another layer of checks that has helped the team write and maintain quality code.

In my team, we have a robust process of how we deploy any code, what's the scene in your team? Some simple things that you should add if missing - Manageable PR Size: It's wise to limit PRs to around 500 lines of code changes. Smaller PRs are easier to understand and review. Test Reporting: Include test results from both local and staging environments in your PR. This transparency reassures reviewers about the code's reliability. Merging Safeguards: Configure settings that prevent merging without proper approval. Design Documentation: Even if a reviewer wasn't part of the development process, they can understand the changes, their purpose, and their alignment with the project's design and objectives. These things will help a lot :)

Teleconferences still rule and enhanced screen sharing helps bridge understanding between the code presenters and their reviewers. Regardless of the tools for presentation, code reviews must provide evidence of having solved a problem, adherence to an approved design, standards, and security constraints. At the end of the code review, the reviewers must communicate in writing what the purpose of the code review was for first-timers, the revelation of what code has been approved as well as what has not passed with clear recommendations for remediation. You still need source code control to preserve the history of changes. In a year, all the players may have changed. All verbal exchanges are likely lost. Only the written record remains.

In our team, the cycle is such that we try to avoid repeating it twice and again. In each of the software development departments, in addition to software visibility tools to control logging and automate tests. We put the quality control of each feature of the software in charge of the quality control elements of the tasks passed by the software developer :)

As far as I have experienced there should be a set of guidelines with regards to how the process works. In addition to code reviews and assignment of reviewers, code format and feedbacks I think there should be some introspection on the code review process itself to see how it works over certain period of time and update it accordingly if there might be some things do not work.

A code review process should be followed strictly by each person of a dev team. In some companies that I worked for, you should have at least two approvals from other team’s members if you want to push some commits into master branch. This part, by the way, is an automated process. By yourself, you can not push anything into master: you have to get all the approvals between test and stage phases, and only if all tests and “Legal To Merge” approvals required were successful so the platform (I use GitHub Actions) automatically will merge your Pull Request and deploy the master branch to production.

Some simple but practical examples for writing clean codes: 1. Use descriptive names in Variable&functions 2. Use empty lines to create a readable code 3. Do not send more than three parameters into a function(If we need to use more than three parameters, we can send one object to the function ) 4. Remember the functions must do only one thing 5. Functions must be small(If you need to do a function with many lines, you must consider that maybe it is more accurate to use a class instead of a function. Remember your function must do only one thing.) 6. Reduce the number of characters in a line 7.Make less comments. Your code should be descriptive and require fewer comments. 8. Learn Design Patterns

I'd say this is the part that can (and possibly should) be automated as much as possible. Enforcing unified code style is easy with reasonably strict linter. I prefer strict no-config linters (such as ktfmt for Kotlin) that don't even allow for any discussion on how things should look. They simply have to look the way the linter mandates. Once everyone gets used to the "no discussion" policy, it's liberating. Less time spent on arguing about code style and more on actual coding 👍 If there are rules or best practices that you use on top of what your linter enforces, just write your own rules for automated checks. It saves a lot of time during CRs (no need to repeat yourself all the time).

I advocate for writing succinct, testable code blocks that adhere to SOLID principles, as they can be easily combined to create more complex structures. Strive for readability and self-explanatory code to reduce the need for extensive comments, which can become a maintenance burden. While unit tests serve as excellent documentation, they aren't a substitute for well-structured code. Aim for low coupling and high cohesion, but remember that the goal isn't to minimize coupling at all costs; it's about striking the right balance.

Follow coding standards. Commit your code with proper definition. Learn to make code simpler and more readable. Lastly I would suggest learn one design pattern and try to use that in your coding.

Read the "Effective" series of books by Wagner publishing for your target language. I'm in a C# shop, so I've read both "Effective C#" and "More Effective C#". They have them for most mainstream languages. They cover the basic principles of 'clean code'. Also think about taking a SOLID course. Pluralsight has a few really good ones.

We teach our developers how to perfectly masterize `git rebase -i` and `git add -p`. The atomicity of the commits is one of the key aspect for efficient review. Especially, don't merge cosmetics changes, refactoring and new features. Usually, a good PR start by refactoring the existing code to prepare the new feature (so the reviewers check that nothing is broken by these commits), then the new feature is implemented. The cosmetics changes must be placed in separate patches. Thus, the difficult changes are not polluted with cosmetics changes.

When you request a code review, it's crucial to provide your reviewers with the necessary context and explanations to help them understand your code changes effectively. This process ensures a smoother and more productive review process.

I would love to add an example for the review request - Title: "Fixing Login Bug" Summary: "This PR addresses the login issue reported in Ticket #123. I've identified the problem as a misconfigured authentication middleware. In this fix, I've updated the middleware settings to ensure proper user authentication." Link to Relevant Tickets: a link to the ticket/thread Highlighting Key Changes: Updated authentication middleware settings Indicating Areas of Uncertainty: "I'm not entirely sure about the performance impact of this change. Any insights would be greatly appreciated." Visual Aids: Attach a screenshot/screen recording Prompt and Polite Responses: Why this approach? Explain the main reason, why you chose that approach!

Our Teams in the Web Development Department have an excellent way of creating Pull Requests. Title and Description are almost very common. Additionally, we attach snapshots of what we have done in the PR. If there is any change on the front end, we attach photos. If we have setup responsiveness, we use tools to generate images for different devices and paste them along with the PR. Sometimes, we can catch issues just by looking at the images.

When you ask someone to check your code, make sure they know the "why" and "what" of your changes. Give your request a clear title, link to any related tasks or details, point out major changes you've made, and show any pictures or videos of how your code works. If there's something you're unsure about, let them know you need extra attention there. And if they have questions or feedback, answer them quickly and nicely.

I've realized the true value of objective and constructive code reviews. It's not just about identifying potential issues but also understanding the context and the rationale behind the solutions implemented. Time-boxing each review is essential to maintain focus and provide actionable feedback without getting lost in the details. It encourages a culture of appreciation, fostering a positive and collaborative environment. Moreover, being open to different perspectives during reviews can be a rich source of learning and growth, fostering innovation and excellence in our code quality. It's a collaborative effort that goes beyond mere quality checks, serving as a platform for teamwork and continuous improvement.

Understanding an author's intent is much easier when legibility is a team priority. Reviews are a team exercise, and objective, constructive feedback tends to flow more freely when goals are clear, diffs are small, and commit history is clean.

The code review is an important part of the development. It must be objective and constructive. Some people tend to take it too personally, which is not a good way. The purpose of the review is not only about the only solving the current task, but it is also about developing communication skills. Clear communication between team members is a key element to finishing the main goal -> delivering the best product.

When checking someone's code, focus on the code itself and not the person who wrote it. Understand what they tried to do, test the code to see if it works well, and give clear, kind feedback. Point out what they did right, and if something's unclear, ask about it. Stay open to new ways of doing things and avoid blaming or attacking the person. Also, try to review the code quickly and based on what's important for your team.

Fully agree, especially on "Remain open-minded and willing to learn from different perspectives and approaches." During a code review, the primary objective should revolve around assuring the uniformity of coding styles, and in no way suppress innovative algorithmic approaches.

A code review is also a form of communication. Sometimes it is not even that important to formally review the quality of the code, but to keep track of what is happening in the codebase. People may not learn to be better programmers, but they will learn about the system.

Agree here. Management of the process is a symbiotic relationship with governance of the same (continuous improvement). Have meaningful and evolving metrics that the teams are behind to minimize risk. E.g. total defects equaling zero doesn’t mean it functions to spec or is without risk.

This is how I recommend you to see the PR process - Continuous Learning: Code reviews are not just about checking code. Use them to pick up new skills, techniques, and insights from your peers. Mutual Growth: Share your experiences during code reviews. It's a two-way street where everyone can contribute Self-Reflection: Code reviews also offer a mirror to your coding abilities. Identify areas where you can improve and take steps to enhance your skills. Constructive Feedback: Seek and provide constructive feedback on code quality and performance. This helps both you and your colleagues grow. Team Triumphs: Celebrate the wins that come from effective code reviews. When the team's code gets better, it's a collective achievement. Yay :)

I have seen code reviews differently over the past two decades. At first I handed out code listings in color to expose keywords and reserved words to prospective reviewers days ahead of time, delivered baked goods and coffee to the conference room, then led walkthroughs on a large screen in front of the group. It was a fun, social, and technical event. Ten years later, code reviews became impersonal, asynchronous events enabled by tools attached to source-code control systems with no incentive to make or respond to comments. Ten years later during Covid, knowledge-transfer sessions via teleconference carried the day, relying on imagery and assertions but little evidence of working code that left a lot of questions in the wake.

I relate to Steve Hodge above in terms of having code review meetings especially for large changes, where the developer goes through the high level design changes followed by the class level code changes for the important part of the feature being coded. That would act as a starting point for the reviewer to get started with the review. And in terms of the learning experience from code review, I remember my first year of my work where those 3-4 code review sessions with a couple of senior developers in my team taught me practicalities of coding for a professional project, which I carry with me even till date.

In my opinion code review is a very small but crucial step in the development cycle. It must start with defining the clear guidelines around how the code should be written. Following are some of the things we must have in our guidelines. 1. Naming conventions for classes, variables, functions, properties based on different access modifiers. 2. How the child members should be organised. 3. Best practices to be followed. 4. How many lines of code we should have in a single function, class. And the last and very important point which I personally follow and also request my team to follow is before sending the review to others we must review our own code against all the guidelines. This saves a lot of time spent on code review.

When I review code with my team, we follow a structured process. We start by establishing coding standards and guidelines to ensure consistency. Using a code review tool, we assign reviewers with expertise in the relevant area. Each reviewer independently examines the code before the review meeting, where we discuss findings and provide specific, constructive feedback. We maintain a positive atmosphere and encourage collaboration. After addressing feedback, we approve and merge the code, documenting the review for future reference. Continuous improvement is key, as we strive to make our code review process more efficient and effective.

Code review is highly important but it should not depend on reviewers ability instead it should follow the standard framework. It helps with standardizing code format so every one in the team follow making it much easy to manage and understand.

Every company and developer I have worked with says they value code reviews but very few have actually been any good at it. Most code reviews don't provide any valuable feedback and just get approved.Nine times out of ten the code review process is pointless. If you doubt that, test it. Look at the last 10 code reviews. What percentage has valuable feedback? Then purposefully add bugs, perf issues and bad readability and count how many get picked up in a code review(without warning). If your team picks up everything then great, keep doing what you doing. If its not working then you can try improve that process or try alternatives. A better way is to pair program or get on a call with another developer and talk them through your code.

It would be much more beneficial if we did "plan reviews". By the time a developer submits their work for a code review, it's the hardest to make changes to it. If implementation paths would be discussed earlier, it would be much easier to act on feedback thus work would be more efficient. It would also reduce the number of occasional surprises on code reviews when it turns out the whole solution needs to be rewritten. So in conclusion: review ideas, review plans, review early so that code reviews can go smoothly and quickly.