This content originally appeared on DEV Community and was authored by Augusto Galego
An all too common occurrence that slows us down in the async world is
you make a PR, wait a day to get reviews
reviews come in, your code is good and works, but there are suggestions to make it better.
you refactor the code, re-write tests, etc, ask for reviews again, wait another day again.
This can go on for two or three iterations. My suggestion is simple, if it works decently well, you merge immediately, and create another WIP PR to make improvements (you have to create the PR and start working on it, otherwise it's just tech debt). Your new PR will include all good changes suggested by your team.
This will do two things.
1) It allows the code to reach the user and deliver benefits faster.
It may even validate/invalidate the entire feature. It may reveal a wrong approach, etc. Code on the IDE provides little information, code on prod reveals more information. The faster you receive information, the more feedback you have, the more agile you are. In the traditional sense of the word agile
2) Your next PR, the one fixing the tech debt, will be smaller, and different from the first one. It'll be easier to read and review. Sometimes you had good working code, and a well meaning suggestion could break your code or introduce hidden bugs. In that case, your original code is already on prod and working, and this single PR (the one adding the suggested changes) can be reverted.
Aim for fast feedback, increase surface area. Godspeed
This content originally appeared on DEV Community and was authored by Augusto Galego
Augusto Galego | Sciencx (2024-09-12T12:21:21+00:00) Merge first, suggest changes later. Retrieved from https://www.scien.cx/2024/09/12/merge-first-suggest-changes-later/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.