代码怎么获得approval

这个逻辑也算是跟design doc一样

感觉你没有trust，写代码，写doc，你不能按照自己的意思去写。你得要按照reviewer想要的去写，不然一个小小的细节别人都可以跟你吵半天

现在问题来了，怎么知道别人想要什么呢

分好多情况，正常人首先分忙与不忙，不忙的时候review相对认真，代码要求高，会给你各种notes，按要求改就好了，忙的时候基本不看，但这也基于你本身代码质量，比如你本身就是组里的中流砥柱，基本上不会为难你的。不正常的人，这种，如果他反复找茬，就找他唠嗑，可以的话再捞一个一起，想把事闹大，就在retro会议室，提出这个review code流程规范的topic，大家一起把这个定下来，总之有法可依。

找一个peer, 相互lgtm呀
前提是要有ownership
各自挖的坑，自己填
如果是小弟，按owner的意思改，毕竟人家是对未来维护负责的

这就是高管想要看到的，底层码农狗咬狗相互限制相互搞，这样可以提高代码质量

感觉现在都是AI写，人看得没那么多了

金丝头发的香菜 发表于 2026-08-30 20:37:44
很难有个笼统回答，很多情况都可能block你半天，公司文化也有关系有的公司就是rubberstamp

狠狠的赞，有的公司就是rubberstamp

找那個叫你打工的人項目領導engineer review。此人有interest 強烈動機推動項目前進

可以先把“reviewer 想要什么”变成可确认的标准，而不是猜口味。开写前拿一个很短的设计说明对齐：这次要保证的行为、接口/数据模型、兼容或回滚要求、以及怎么验证；有分歧的地方请负责维护这块代码的人先拍板。PR 尽量小，描述里写清取舍和测试。收到评论时可以问一句“这是 correctness/blocker，还是偏好建议？有没有团队现成的范例？” 如果同一类要求反复出现，就把结论记到团队约定里。这样下次有依据，也能减少来回改同一个细节。

第一次不知道很正常，被review几次就知道reviewer要啥了，你真急的话就开个meeting align一下，然后全都照着改