• 赵智慧
    2021-02-01
    老师,您说的太对了。因为一个敏捷教练,小波带领我们做了很多。 例如:工程实践、每天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更上一个台阶,做的更好、更有效率呢?
    展开

    作者回复: 你们如果能够坚持做得很好,那真的要恭喜你们了! Code Review 这种事是为了发现问题,如果没有发现问题,一种可能是代码写得真好,另一可能是你们遇到了团队的瓶颈,发现不了问题。实话说,后一种可能性更大。 Code Review 不是一个结束,而是一个开始,发现了问题要去修改。我的团队发现问题后修改的工作量还不小,即便我们的频率已经算很高了,还是能发现不少的问题。所以,如果你们自己发现不了太多问题,可以引入别人的视角,帮你们发现问题。

    共 2 条评论
    10
  • 点
    2021-02-06
    做几年码农了,一直没人给我review. 当第一次有人给我review时,被说像刚毕业的,羞愧难当。 如果在没有review氛围的公司,怎么提高自己的代码质量?

    作者回复: 这就是缺乏反馈的结果,自己不知道自己的代码究竟写得怎么样。 你从开始学习这个专栏,其实,就已经进入到一个提高自己代码质量的过程里了,至少,现在看到有坏味道的代码,你应该能够发现一些了。 接下来,你可以去读读书,比如像《代码整洁之道》、《重构》之类的书,还是要看一下的。接下来,就是在实践中,不断地去打磨手艺了。 当然,如果你身边有人能够通过代码评审的方式给你反馈,你的提高会更快。

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

    作者回复: 自己重视,比团队重视提高得更快。

    
    4
  • 明
    2021-01-31
    我从来没经经历过代码评审😂😂 所以我感觉从老师这里真的学到了好多好多

    作者回复: 在一个正规的团队中工作,能学到很多基本的东西。

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

    作者回复: 运气不错。

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

    作者回复: 刻意练习最重要的是适当的反馈。

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

    作者回复: 嗯,代码评审有经验的人会多问一句,就能发现不少问题。

    共 3 条评论
    2
  • 桃子-夏勇杰
    2021-01-30
    郑老师,有没有用系统思考的方式评估过代码评审在软件开发中的位置或者作用?

    作者回复: 如果你需要的是代码评审的价值,可以搜搜“why code review matter”。

    
    2
  • Dawson
    2022-01-20
    有种相见恨晚的感觉,CodeReview我也在做团队内部断断续续的做,之前都是凭感觉,现在有了郑老师总结的方法论指引,让我如虎添翼。

    作者回复: 用套路替换感觉,就是职业的进步

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