14 | 多久进行一次代码评审最合适？

老师，您说的太对了。因为一个敏捷教练，小波带领我们做了很多。 例如：工程实践、每天code review、结对编程。团队也已经这样运作了奖金一年。 好处多多，老师您都说了。 但是最近碰到一些问题：因为我们技术们，尽管没有的Leader，但大家都执行的不错。结对编程、code review、暴徒式编程。但是最近code review上大家的分享越来越少了。 我猜测几种可能： 1、是不是随着大家技术的水涨船高，问题越来约少呢？ 2、因为我最近分享老师的代码之丑，大家觉得code review变了一个调调，换成分享坏味道了？（其实分享代码之丑的时候，我分享初衷是想让大家都可以学习到，但是我本身自己做的就不太好，代码里面还有好多坏味道，直接去讲 担心大家会不会觉得太空呢？有句话说：道理都懂，可就是过不好这一生！实践真的太难了） 3、会不会我们的code review没有回顾会？没有去总结如何把code review做的更好？ 4、是不是我们没有明确code review都需要做哪些事儿？列出来 1 2 3 5、会不会是每天都code review，频率太高了呢？每天工作量毕竟也是有限的？ 6、会不会是太经常了，心态上已经没有最开始那么重视？我们每天5点code review，我有的时候心里面会想，到5点就算这一天的工作做完了，开个会就下班了！ 我期望老师给个意见，如何能让我们的code review更上一个台阶，做的更好、更有效率呢？

做几年码农了，一直没人给我review. 当第一次有人给我review时，被说像刚毕业的，羞愧难当。 如果在没有review氛围的公司，怎么提高自己的代码质量？

代码评审本身就是对团队成员代码质量提升的有效方法，之前我每次commit都会要求我自己先检查一下有没有更好的方式，然后老大再去看一下，每次找出问题来自己也会很难受，然后慢慢自己也都会注意起来。

我从来没经经历过代码评审😂😂 所以我感觉从老师这里真的学到了好多好多

还是菜鸟的时候，所在的团队有 Code Review，Leader 对每个人提交的代码都会亲自 Review 并指出问题, Leader 做评审的时候都会带上小本本记下问题，那段时间自己成长的特别快。后来因为某些原因团队解散，经历过的其他的一些团队再也没有那么好的 Review 氛围了。

自己团队其实也一直在做代码review，老大也比较重视。读完作者这篇文章感觉自己的收获就是review的方向有了：实现方案的正确性，算法的正确性和代码的坏味道。这点我觉得的可以在review的时候刻意注意的地方。 特别认同作者说的刻意练习，不好的习惯，只能通过刻意的练习将其纠正过来。这个也是我最近自我感觉提高的一点，刻意的去做正确的事，慢慢的自己提高是很明显的。

来个新鲜的案例，昨天代码评审时发现的问题： ```java List<String> a = new ArrayList<>(); //筛选数据，符合条件的添加到a中 List<String> b = new ArrayList<>(); a.addAll(b); //筛选数据，符合条件的添加到b中 //结束返回a return a; ``` 对引用的认识不清楚，集合的addAll方法是把参数集合中的每一个Element添加到自己这个集合中，不是把集合做为一个Elements添加到集合中，形成多维关系。 事后追问了一个问题，同一个对象添加到两个不同的集合中，然后再从其中一个集合中取出对象对其进行修改，问此时另一个集合中的那个对象的受影响吗？

郑老师，有没有用系统思考的方式评估过代码评审在软件开发中的位置或者作用？

有种相见恨晚的感觉，CodeReview我也在做团队内部断断续续的做，之前都是凭感觉，现在有了郑老师总结的方法论指引，让我如虎添翼。

原文： 把循环里对于一个元素的处理拆了出去。还没等我来赞美这段代码写得好，我就看到了单个元素处理的代码，每次都要查询一次数据库，找出相应的元素，做修改之后再存回去。 结论，我认为这个每次查一次数据库没问题。 决策依据: 1.这样的单行操作更易理解。 2.批查询可能伴随大事物(毕竟你是更新动作，可能要锁（悲观或乐观）所有数据行) 3.如果更新操作不需要锁数据行，也就是数据行的变更对更新操作的正确性无影响。那么通过加缓存会是更好的解决方案。 综上所述，保证业务逻辑简单是第一原则。