Makers Academy Day 39

Over the last week we started working on our first group projects. It’s been a really positive experience so far, and one that has pushed my git knowledge to a new level. Working with other people has dramatically changed the work flow of how tasks are completed, with a formal review process being part of that flow. In today’s blog post I’ll focus specifically on pull requests and what I’ve learnt from reviewing pull requests.

Firstly, what is a pull request? Unsurprisingly, Github provides a good definition:

Pull requests let you tell others about changes you’ve pushed to a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before the changes are merged into the repository. -Github Help, About pull requests

In case you’ve not done one before, I really like this very practical post from Linh Nguyen My, My first pull request on the steps needed to created your first pull request.

So what did I find interesting about reviewing pull requests for our MakersBnB project? Well first off, as an ex researcher working in the humanities the process of reviewing a pull request felt comfortingly similar to the peer review process. In a similar way to a pull request, the whole point of the peer review is to evaluate a piece of work and ensure that only thoroughly reviewed code is merged in to the master branch:

Peer review is the evaluation of work by one or more people of similar competence to the producers of the work (peers).It constitutes a form of self-regulation by qualified members of a profession within the relevant field. — Peer review, Wikipedia
Some Pull Request comments for our group project

For our project were very strict to ensure that the pair that reviewed the code had not written the code. This allowed for greater objectivity in review process; it was easier to have more constructive criticism and question code if you hadn’t written it.

Something I really enjoyed about reviewing pull requests was how well integrated the process is on Github. Reviewing code reminded me of word track changes- I could leave comments on whichever line I wanted and then approve or ask for further changes.

Overall though, one of the main benefits I experienced was that in reviewing code I better understood what the code was doing. Focusing in on small discrete segments of code gave me greater clarity on how each line interacted with the other. It also forced me to pay attention to details, for example to ensure that our code adhered to the ruby style guide.

Going ahead I would like to review as many pull requests as possible to gain greater exposure to other peoples code, and through the review process learn how I in turn can write better code.