it is very important that we document how to manually test user-facing features that require complex setup, or how to manually test changes that aren't user-facing at all. It is the engineer's responsible for ensuring quality in all of their features. Include testing & verification stepsīefore the bug or feature goes for further testing to the product or testing team. Don't assume that the engineer reading your merge request will be as familiar with the problem as you are. Remember that anyone in your organization (or outside of it, if your repository is public) could be reading your merge request. Occasionally the solution to a hard problem is a change of a few lines, but giving additional context and background to explain to your reviewer and to future engineers how and why the one line change fixes the problem will go a long way in saving everyone's time. Sometimes, the changes in a merge request don’t convey the amount of investigation and effort that went into debugging an issue. You can also setup various other kinds of templates inside GitLab. Gitlab allows its users to setup description templates inside their repository, read the steps to make a merge-request template below. It promotes consistency and encourages engineers to share their current understanding with teammates and future contributors. Use a Standard Templateįollow a standard template, ask your lead to provide one so your team can ensure that you’re all on the same page when it comes to what should be documented in a merge/request. Here are a few ways you can create pull/merge requests that your reviewer(s) are going to love: 1. It gives the author (you) a chance to explain the context of the problem and the background of their solution to the reviewer, and allows them to call out what they’re looking for in a review. Additionally, a merge request acts as a guide to your code for the reviewer. When another engineer (or even you yourself in the future) stumbles upon your code in months or years, they should be able to trace back to the merge request to find more information about a given change. A merge request is an opportunity to convey What, Why, and How a set of changes were made. They’re a history for your repository and demands as much time and attention as the code they contain. Merge requests are much more than a display of code changes. Hence, EMPATHY should be part of your Merge/Pull Requests. Maybe they’re not having their best day or are stuck on a problem. A reviewer might receive 5-6 merge requests in a single day, while doing their own work at the same time. In case of a reviewer managing different projects/products, their day might include meetings with various stakeholders while fixing hard problems or even production issues. "Do unto others as you wish others do unto you.”īefore submitting your code (or pretty much anything for review), try to see things from the other side. Although some context can be taken from the name (AH_college_signup) however it is not clear why these changes were made, any assumptions the engineer made during implementation, and if any refactoring was required (in separate modules) to accomplish those changes.īefore we dig-in deeper, the best advice for an author is to refer to Confucius' quote. The above merge request is without any comments, gives no context and doesn't empathize with the reviewer.Īfter seeing the above MR, any reviewer would definitely feel overwhelmed at where to start, and will be unsure of what the author is expecting from the reviewer.
0 Comments
Leave a Reply. |