What to Focus Reviews On
Est Reading Time: 6 min
May 25, 2020
A pull request (PR) is a change you’re requesting to be made against a particular body of work, tending to be a codebase in developer operations. This request includes the code modifications you are asking the team to accept into some version of the code base, possibly a feature branch or staging environment. When making the request, it’s courteous to include notes outlining:
If you have a ticket management system such as Atlassian’s JIRA or IBM’s Rational, you can maintain traceability from requirements to the code by including reference to the ticket number associated with the change.
Pull requests are the go-to process for change management in software development and were made popular by GitHub. They allow thousands of developers to contribute code to a single repository simultaneously. Once you have one opened, others can review the changes for a variety of criteria.
We review code to help coach teammates on community best practices, software design patterns, security, and possible language implementation optimizations. Reviews are there to help the team develop and promote solid habits that lead to maintainable, readable, and reusable code.
Don’t spend time on this, use static analyzers and formatters to solve the problem and align your code’s formatting with a style that others in the community use. Utilizing these practices helps to make onboarding easier, reduces wasted effort, and improves the readability of your code.
Here are a few examples that you can start using to automate these bikeshedding tasks:
Helping teammates develop solid habits, developing secure, maintainable, readable, and reusable code. Everyone is at a different level each time they open a pull request. Dealing with varying skill levels means that when doing a pull request review you’ll want to:
Also, be realistic, a lot of people say every commit must be a single atomic, coherent change. Atomic changes is a best practice; it’s not something to fall on your sword over. If a team member continues to exhibit a given behavior and it reduces performance, point it out, but if it happens a few times while someone is attempting to fix a bug or work through something, it may make sense to let it go.
Once you’re in this mindset, there are hundreds of lessons you can help team members learn. Here are a few examples to get started with:
Some degree of testing for new enhancements/breaking changes and regression tests for bugs.
Handling of security vulnerabilities
Like unit testing, security is largely about risk management and incident responsiveness. As your product matures, you should integrate some level of security design into your process, including:
Self documenting code where it is possible and comments where it’s not. Documented code helps to increase readability and can help in reducing redundant code when used instead of hardcoded values.
Size of functions / classes (mega classes / dumping ground)
Amount of changes in a PR (features, bug fixes, breaking changes, etc.); Pull requests do not need to be explicitly atomic but should try to be when possible.
Pull request outlines
Very few people are experts on all of these topics, so don’t feel bad if you struggle with one or all of these topics. Each pull request is an opportunity for us to improve our development skills and push each other to be better.
Sign up today with instant, no-hassle setup. No credit card required!Sign Up Now
© 2020 Next Release, LLC. All rights reserved. Made with ❤ in Michigan.