How Microsoft does it’s code review?
How Microsoft does it’s code review?
We discussed how Google practices code review at our other blog which made us more curious about how code reviews are done at organizations that are older than Google. For this, there could have been no better option than Microsoft. Founded in 1975, Microsoft is one of the largest software developing companies. With sky-high popularity of Microsoft, it’s products are undoubtedly high quality. Where there is a high-quality product there is high code quality, and behind that is a rigorous code review process.
Microsoft employs around 60,000 engineers who work to build and maintain products MS Office, Windows, Direct 3D, Skype or the various Visual Studio tools. While everyone has the same base and tasks, they are divided into teams and sub-teams to take care of different products. So having a predefined process becomes a necessity for an organization like Microsoft.
Code reviews are a highly integral part of Microsoft, with almost 75% of engineers do it for at least one time in a day. This is a high percentage stating the fact that code reviews consume most of the time of a developer at MS. Developers usually do code reviews for finding defects, improving code, and readability.
Microsoft’s tool for code review
Until last year, Microsoft code reviews were done mostly on a tool called Codeflow which is an automated code review tool. Even though it lacks a lot of features but its ease of running over multiple systems connected over a server as compared to other offline code review tool is very high. The employees of Microsoft or better called as Microsofties, have the freedom to choose and use whatever automated code review tool they like. The aim is simple and short, to make code bug free and ready before peer review. We look at the processes on how code review is done at Microsoft below.
Code Review at Microsoft
Preparing Code:
Consider two situations. If a developer writes a new feature, they document everything in this code. If a developer is writing a part of a feature, they document the change. It’s done by using the code review tool that tracks the changes done. It shows exactly those lines to the developer to review. Once the changes are reviewed, the developer then prepares a document for a reviewer. It explains the reason and meaning behind the changes done. Writing this document helps the reviewer to understand changes better without wasting time figuring out what has been done. Now the code is ready to be sent for a review!
Selecting Reviewer:
The developer is now ready to get its code reviewed but who are the reviewers that will do the job. If the developer is someone who has spent a few years in Microsoft then they must already have quite a view or a group of experts who can be contacted directly for the review. But if there is a new joining, selection becomes somewhat elusive. The first point of contact or even the choice is the team leader.
A team leader can either become a reviewer or can help with policies and recommendations. Some code review tools also have a feature that allows you to view reviewers according to their expertise. Every senior member in Microsoft has their own focus areas and developers select reviewers on the basis of the contributions they can make. Reviewer is senior developers who have expertise in different fields. Reviewers also include managers to notify them about change.
Getting Feedback:
After selecting reviewers, the code is sent to all. Reviewers check the code when they get time. They add comments to code and instructions to document. This change is propagated to all the reviewers through notifications. Tone matters a lot at Microsoft, developers and reviewers are needed to be objective.
To avoid confusion they follow an Emoji Code that is:
This helps them identify requests easily and is simple to understand. Along with this, reviewers reply with factual comments and changes that they have observed like “We applied a similar pattern and failed before…” or “Check out this article that shows a better way to perform this…”
Improving code:
After the first review is over, the developer amends the code following the comments left by the reviewers. The aim of this step is to only satisfy the changes asked and not to add anything more. Once the developer feels that the changes are sufficient, they send the new code for reviewing which is also called revision. Either the revision will get approved by getting enough +1s and it then can be committed or the reviewer will send more changes repeating steps three and four.
Depending on team the final step may change. Sometime it requires all reviewers to approve the code and sometimes the product manager approval is enough. Sometimes the code is checked in main base before review if changes are small and trivial.And this is how Microsoft does it’s code review. Or atleast how they used to until recently. After the acquisition of Github, the paradigm as shifted to using automated code checkers. The rules to edit code have become more strict and follow a very sepecific design rule.
Want to get accurate code review results? Sign up now and get instant code review reports for Free!
Conclusion
Microsoft use many tools which are properitary and hence become impossible to use them. But if you want to follow the same practice to develop quality code, we invite you to try CodeGrip. It is an automated code review tool that connects directly to your Github and BitBucket. CodeGrip analyzes the code finding defects, bugs, smells and vulnerability. It makes sure you spend the least time in code reviews and always write perfect code.
Liked what you read? Subscribe and get fresh updates.
P.S. Don’t forget to share this post.
