Hacker News new | ask | show | jobs
by othmanosx 30 days ago
I think you're missing the point of code review. By the time when the PR is ready to merge, discussions around the architecture and how the code should be structured should already be part of the tech design of a given feature. So the discussion around whether a A feature is built and planned in a maintainable way, should be way before a PR is filed. A PR review is making sure that you verify against the already agreed-upon structure, making sure everything matches the plan, and also find bugs and stuff that was missed, according to the plan.
1 comments
high_na_euv 30 days ago
Not every codebase project etc use such workflow

Also such approach doesnt work with bug fixes / regressions

link
othmanosx 30 days ago
Every team should follow a plan, fine on a side project, but if you work in a large codebase with a bunch of devs, you need to have some sort of workflow to avoid stepping on each other's toes.

bug fixes are supposed to be small, contained, if they're rearchitecting the codebase, then they're not _bugs_, but tech improvements, and need to be addressed differently and I agree that this should be flagged in the PR.

a PR review is the final defence line before a QA

link
high_na_euv 29 days ago
Definitely bug fix can be contained and stil need structure inprovements.

For bug fixes usually there are no fancy docs because until fix is found then it isnt known how to fix it (usually)

And after fix is found, there may be improvements applied to it

link