Code review故意找一个容易过的人看？

匿名用户 发表于 2022-04-20 10:01:11
我就是review代码很严格，会提很多结构上的问题，比如把改动一小部分的class整个重构，也不是一定要求，就是提出建议

现在很少有人找我review代码。。。

啊，原来如此……😅但是比如明明已经有一个folder 做某件事情了，新人不知道，写在另一个地方，这种还是应该指出来的吧😂

Pizi-G 发表于 2022-04-20 10:20:13
1. 从 process 上, 可以看你们的 code review 系统能不能设置 team 为 reviewer, 至少自动 CC, 这样发出去的代码所有人 (至少你) 可以都在 review 阶

谢谢，非常详细的回复！

匿名用户 发表于 2022-04-20 10:21:16
团队合作就是这样子。根本问题出在你跟你现在公司的环境不匹配。你对service对code有高标准，但是其他人达不到，一旦你休假或者因为什么原因放手，代码质量就你的标准而言会直线下降。根据你的描述，虽然

我觉得第一条和第三条都挺难……第二条比较容易😂

donnice 发表于 2022-04-20 12:30:46
以前我们组的Senior维护代码质量的方式我觉得值得参考。

他在项目里引入JaCoco来保持一定的test coverage，这样每次测试不达标的代码就无法check in。如果是比较紧急的改动

值得学习，谢谢。

REPO改成service owner approve才能merge

匿名者 发表于 2022-4-20 15:55
我觉得第一条和第三条都挺难……第二条比较容易😂

对不同的人容忍眼睛里沙子的程度是不一样对，lz第二条也不容易

责任要和权利相当。如果除了outage谁来修？形成了TechDebt是谁来refactoring？出了问题谁负责，那code review就听谁的。

两个比较特殊的情况：
- 如果service不是很重要，小bug可以补休，TechDebt不会怎么样：code review该放就放。
- 如果service经常有很多人（尤其是组外的人）需要改：owner需要在一开始就把架构设计好，interface定义清楚，然后保证大家都可以独立地写自己的implementation，一个outage了不会影响到别人。然后把implementation的code review放给别人，你做好framework的code reivew

最好不要，应该要最懂这块业务的Eng review

楼主作为service owner要确保service code quality也是正常的，有些时候就算别人code review没加你，你也是可以jump onto，把自己设成watching或者必要时给comments。

不过也需要抓大放小，很多时候大方向，正确性或者长期维护性没问题的话，一些nits或者two way doors也未必那么重要。

还有可以从tests的角度来考虑这个问题，COE大部分不会去说为什么这个人写了这个bug，而是为什么tests没有抓到这个bug。unit tests和integration tests是不是有足够的coverage然后能不能给你足够的confidence去不必每个CR都亲自看

tq5124 发表于 2022-04-20 20:17:52
责任要和权利相当。如果除了outage谁来修？形成了TechDebt是谁来refactoring？出了问题谁负责，那code review就听谁的。

两个比较特殊的情况：

我就是第二种情况，这是一个通用的service ，很多别的团队会用的，所以我最开始有一些自己的设计在里面，但是别人过来随便改流程啥的，有些改的就不对，还不叫我review ，出了问题别人解决不了的最后还是我来解决……