Here, Chaotic Moon Studios senior iOS architect Jason Job takes the Chaos Theory helm and steers developers towards a world of cleaner code and improved education through peer-review…
A pull request in BitBucket or GitHub is a way for a developer to request that another developer review and merge a source git repository into a destination git repository. Sometimes, as with open-source projects, this will be a request from a developer who has forked the project to merge in some new fix or feature they have added. The particular case we’re interested in discussing here, however, is one in which a developer is working on a feature branch of a project and wants to merge their work into the main branch, often named “master” or “develop.” We have found that—instead of having developers merge their feature branches directly—there are huge benefits to having them issue a pull request for the other members of their team to review and then complete the merge.
Adding this review step creates an opportunity to catch potential bugs before the project goes to QA. If a problem is discovered, the developer who issued the pull request can be informed, make any necessary changes, and the code can then be resubmitted for review before finally being merged. This does more than just catch bugs. It also encourages consistency and allows the developers on the project to hold each other accountable. This could apply to things like code formatting, method and variable naming, and design patterns.
When we started issuing pull requests to merge our work, the first thing that I noticed personally was that, as I was coding, the awareness that my teammates would be looking at my code motivated me to make good decisions. “Feature X works but would be more readable, extensible and future proof if I refactored it. Should I do it?” When your peers will be reviewing your code, you’re more likely to say yes and do the right thing immediately in the moment.
Reviewing your project teammates’ work also gives you insight into the bigger picture and allows you to see the project as a whole, making it easier for developers to move around between the different sections of the code base. This is useful in situations where they need to jump into a piece of code that they didn’t work to help out or if they need to integrate something of their own into that project.
Possibly the greatest benefit from working this way, though, is that both the developer doing the review and the developer being reviewed can learn from each other. The reviewer looking at their fellow developer’s code could potentially learn new API methods or discover an improved design pattern that they perhaps wouldn’t have otherwise used themselves. This may also inspire the reviewer to ask questions about the code, creating a learning opportunity. As long as feedback is created in a constructive manner, it’s a good chance for you to (politely) school your fellow developer when you notice them doing something in a way that’s less than optimal.
While adding the pull request and review process to the workflow may add a small amount of time, it’s an additional step that’s well worth the while. Not only will time typically be saved due to cleaner code, but you will also be creating an environment conducive to spreading and increasing developer knowledge, leading to high-quality work that—in the end—is more efficient and effective than ever before.