August 3, 2023 at 9:48 pm
I think that is a good point. Review what the developer has actually submitted, not other stuff. Obviously there are some "It depends" scenarios. Restricting the blast radius is a sensible strategy.
Sometimes I will raise JIRA tickets as a result of stuff I have seen while looking at code for a PR. Some things I spot in passing and if I don't write them down I will forget about it and why I thought it was important. This helps keep the current scope small while not losing sight of future risks/threats
I do review other parts of code looking for the proverbial low hanging fruit. That is, minor changes that can have a huge impact. There are times when it can be made part of the release and other times it would have to be a separate change to be prioritized accordingly. In the end, you still document problem area while you are there in the details.
----------------------------------------------------
Viewing post 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply