Developer Ramp-up with Pull Requests

I started as a developer at Viget a couple of months ago. Over that course of time, I have familiarized myself with Viget's development process and ramped up on some larger Rails applications. As with most large projects, there are certain code guidelines to follow to make a project easier to maintain. These guidelines may not be etched in stone, and a new hire will need some help getting started with larger applications. Github Pull Requests can ease a new developer into a project.

Background

If you are not familiar with Pull Requests, Github has a write-up on the current system. Pull Requests are normally thought of as a way to manage code across repositories. This is especially true in the open-source community. Pull Requests make it easy for developers to contribute to repositories without requiring write-access. At Viget, we have the advantage of giving every contributor write-access. So, how do we use Pull Requests?

While working on Puma, I create topic branches for each ticket. I push the topic branch to the remote server: Github. When I am confident that my topic branch is ready to be merged into master, I issue a Pull Request and notify the team. The other developers can review, comment, and decide whether my changes are ready or whether more work is required. As a new hire, this process has been a worthwhile experience.

Consistent Style

A code base with several different styles is a nightmare to read and maintain. Ideally, every new person on a project will continue using the established conventions. This allows for current (and future) maintainers to easily navigate and make changes. Pull Requests allow experienced developers to review the changes stylistically and comment on a line or block of code that does not fit. Style changes are considered minor in the grand scheme of things; but, they go a long way toward getting a new hire comfortable with what has been written.

Unknown Methods

During a code review via a Pull Request, the other developers point out an existing method that helps tidy up the code. Without the Pull Request, a new hire would not have known the method existed. Wouldn't documentation help in this matter? Not necessarily. Documentation is great, if the search criteria is known. The code review, however, brings the unknown method to light and gives the new hire better insight into the project.

Feedback

When joining a project, there are times when the scope of a requested feature is not fully understood. An experienced developer can help; but, a Pull Request can be issued to keep the conversation unobtrusive. This conversation is now documented with the code. It can be referenced in the future to better understand the context around the implementation of a feature.

Automated Tests

Adding tests to a change is very important at Viget. Making certain additional tests belong with existing ones is also very important. For instance, if context blocks are being used to organize unit testing class methods from instance methods, then new tests should continue to use this convention. This follows the same reasoning of keeping a consistent style within a project. Pull Requests allow the veteran developers to confirm the tests added conform to what has been established in the test suite.

Pull Requests also provide a channel to receive feedback on additions to the test suite. Developers can determine if tests are behaving as expected. They may find that a piece of the acceptance criteria is missing or that the method behaves correctly when nil is passed in as an argument. Without this feedback, the code is not tested properly and is not guaranteed to maintain behavior when a refactoring is done in the future.

Conclusion

Pull Requests have been beneficial to me as I ramp up with larger Rails projects at Viget. Code consistency, unknown methods, and feedback are just a few of the ways in which they helped me. In what ways have Pull Requests helped you? What else do you find beneficial when ramping up on a larger application?