When working in a software development team, reviewing pull requests (PRs) is part of our everyday work. It is best practice to keep PRs small and concise, just so we can avoid missing potential issues and spending too much time understanding code changes – thus ensuring productivity.
At WooCommerce Mobile, we have several teams working on different features, and we break down tasks into bite-size ones – so large PRs are not really a problem. However, for folks working alone on a backlog story, or joining the team for a short rotation – it is common to face the issue of handling a big task and having to break them down into smaller parts. This post will sum up the tips that our team have come up with to handle this common situation.When working in a software development team, reviewing pull requests (PRs) is part of our everyday work. It is best practice to keep PRs small and concise, just so we can avoid missing potential issues and spending too much time understanding code changes – thus ensuring productivity.
At WooCommerce Mobile, we have several teams working on different features, and we break down tasks into bite-size ones – so large PRs are not really a problem. However, for folks working alone on a backlog story, or joining the team for a short rotation – it is common to face the issue of handling a big task and having to break them down into smaller parts. This post will sum up the tips that our team have come up with to handle this common situation.
Another solution is breaking down tasks and handling them in separate small PRs, which are merged into develop sequentially. Spoiler alert: this is preferred considering our team size and our strong emphasis on transparency. There are quite a few things to consider though:
- Careful planning is highly recommended. When starting with a big task, it is important to separate them into smaller bits. You can start by considering changes you’ll need to make to networking, storage, logic and UI layers. If your task focuses only on the UI layer, you can break it down into even smaller features. This will help with making sure PRs are focused and small, so that it’s easier for your teammate to review.
- Work on non-user-facing tasks first. These have fewer effects on the app when merged, and usually are essential to be merged early to avoid conflicts (take Core Data versioning for example).
- For user-facing changes, if your PR does not complete the feature, consider a feature flag to hide the feature from users. You can also tag your PR with
status: feature-flagto let the team know that your feature is not yet available for testing on release builds.