跳到正文
Hacker News· bucket2015·· 10 天前AI 评分38

把大型 PR 拆成小 commit 的实用技巧:用 AI 重新切片代码变更

Neat trick to make big PRs readable: reslicing them into small commits

AI 导读

面对 AI 生成的 +4k/-1k、涉及 72 个文件的大型 PR,作者尝试用 AI 将其重新拆分成约 20 个聚焦单一改动的 commit,使审查变得轻松许多。每个 commit 无需独立编译或通过测试,只需讲清整体变更故事的一个章节。作者已将这一做法固化为一项技能,并计划今后每次审查大型 PR 时都使用。

正文 · 原文

It’s pretty hard to review a PR with a +4k/-1k changeset that touches 72 files. PRs like that used to be rare, maybe if there was a large refactor or an upgrade that had to go in all at once. But now I run into them regularly.

Last week, when AI wrote two of those for me and I had to review them, I decided to try a new trick.

Well, the trick is actually old; I first saw it about seven years ago when I started working as a Tech Lead at Vena Solutions. Back then, our VP of Architecture really liked refactoring and cleanup, which often produced large PRs. To make those PRs palatable to us, he organized them into neat, very focused individual commits with one specific change in each commit, something like this:

Some commits had a lot of lines changed, but it was the same change on each line (e.g. rename SomeThing to OtherThing). Other commits had a specific narrow focus, like a tweak to a complex algorithm. Each individual commit didn’t have to be compilable or pass tests by itself; it just had to tell the next chapter in the overall story of what the PR was doing.

That’s the new trick I tried: getting the AI to do that to a pre-existing PR.

I would have never done this by hand myself. But AI has infinite patience (well, as long as the tokens last), and it had no problem tearing apart all 4k lines of code and carefully piecing them together into 20-ish commits. It wasn’t perfect, but it was good enough that reviewing was a lot easier.

So then I turned it into a skill (below); after using it on several more PRs, I think from now on I’ll be doing it every time just so that I can read the PRs myself.

If you aren’t familiar with stacked PRs, this GitHub page gives a decent overview.

They’re certainly an option, but I find that before starting the implementation, it’s not always clear which PR should be the base PR, and sometimes after a lot of fixes and follow-up tweaks, the stack needs to get reorganized a lot, which is annoying to do when you’re dealing with PRs instead of commits.

And it’s a lot more practical to reslice a 4k LOC PR into 20 commits rather than 20 stacked PRs.

来源:Hacker News · i-kh.net