2019-09-221. 你们团队使用了代码审查吗？具体使用了哪几种审查方式呢？
我们一般有设计审查和代码审查。设计审查需要全部人员参加，主要是统一大家的认识。代码审查采用离线代码审查的方式，每个team的team lead需要负责审查组员提交的所有代码，组员之间的互相审查比较少，因为组员的技术栈不太一样，有时不太容易给出比较专业的审查结果。这种方式的不好的地方1. 要求team lead有全栈经验，即使有些方面精通，但是要熟悉通用的原则，2. 比较占用team lead的精力，容易成为瓶颈。
2. 设计时检查除了可以避免后期对代码的大规模调整外，对顺利引入代码审查还有一些其他作用。
设计时审查很重要，它可以确保整个team对于设计的理解是一致的，而且设计审查不应该只包含技术人员，业务人员也鼓励参加，因为设计部分不会涉及太多技术系列，业务人员可以从业务角度给出一些评审意见。展开作者回复: 你们的审查做得挺好，点赞！
一个可以提高的是尽量多做相互审查，避免把审查任务集中在几个人身上。试一试多把权力和责任往下面分一分。 3
2019-09-18思考题2：设计时审查可以帮助审查者熟悉代码架构，提高审查者的审查效率。作者回复: 👍👍👍
2
2019-09-18代码审查，很全面！非常赞同设计时审查！架构对了，细节容易调整！作者回复: 是的是的，门禁是一方面作用，早期讨论是另一方面作用。后者常被忽视
2
2019-10-02老师好！我怎么才能写出复合规范的代码呢，挺希望被review，又有点怕被review。核心代码，leader会进行设计时一对一review，提交前增量review。作者回复: 这要看你们团队的代码规范是什么样。
我推荐你跟leader了解清楚团队的规范，以及哪些方面需要特别注意。然后在代码审核的过程中不断进步。这样的话相信leader能够看到你学习的意愿，你的进步也会比较快。 1
2019-09-18linkin 的由作者发起的 code review 方式也很有特色，要求作者组织材料和会议，从而激励期责任感，提升审查效率作者回复: 有具体的链接参考吗？我只找到类似这样的：https://thenewstack.io/linkedin-code-review/，对过程的描述不多。
1 1
2019-11-06拆分为多次原子性提交，可能会导致TL需要抽出很多次空余时间来审查代码，会影响TL的工作效率吧？这个如何平衡呢？作者回复: 首先，代码审查最好是交叉审查，也就是团队成员互相审查，这样TL不会成为瓶颈。
第二，这样做实际上是会提高代码审查效率的。因为每一个提交都更加清晰。如果一大团代码审查，要么审查不清楚。如果要深查清楚，花的时间肯定比这一团代码被原子化后的多。
2019-10-29Phabricator配置和使用都有些复杂，像upsource这种，必须要推送到远程仓库的review感觉怎么做都有些别扭呢。比如我每一个feature可能有10个commit，我希望每次commit都审查后提交，用merge request审查比较麻烦呢作者回复: > 用merge request审查比较麻烦呢
这个能详细解释一下吗？ 1
2019-10-12刚好最近跟公司提到了引入代码审查，随后就看到了这篇文章，真想把文章发给领导看看！作者回复: 那就发啊，还在犹豫什么！哈哈 ：）
2019-09-30之前代码审查开成了批斗大会，有不符合规范的还有处罚措施作者回复: 后来效果怎么样？有继续推行吗？
2019-09-19还是一个很好的交流和学习设计模式及方法的机会😊作者回复: 👍👍👍