代码之丑
郑晔
推文科技技术VP,前火币网首席架构师
新⼈⾸单¥19.9
1407 人已学习
课程目录
已完结 21 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (2讲)
开篇词 | 这一次,我们从“丑”代码出发
免费
课前热身 | 这些需求给到你,你会怎么写代码?
13类典型坏味道 (13讲)
01 | 缺乏业务含义的命名:如何精准命名?
02 | 乱用英语:站在中国人的视角来看英文命名
03 | 重复代码:简单需求到处修改,怎么办?
04 | 长函数:为什么你总是不可避免地写出长函数?
05 | 大类:如何避免写出难以理解的大类?
06 | 长参数列表:如何处理不同类型的长参数?
07 | 滥用控制语句:出现控制结构,多半是错误的提示
08 | 缺乏封装:如何应对火车代码和基本类型偏执问题?
09 | 可变的数据:不要让你的代码“失控”
10 | 变量声明与赋值分离:普通的变量声明,怎么也有坏味道?
11 | 依赖混乱:你可能还没发现问题,代码就已经无法挽救了
12 | 不一致的代码:为什么你的代码总被吐槽难懂?
13 | 落后的代码风格:使用“新”的语言特性和程序库升级你的代码
加餐 (4讲)
14 | 多久进行一次代码评审最合适?
15 | 新需求破坏了代码,怎么办?
16 | 熊节:什么代码应该被重构?
17 | 课前作业点评:发现“你”代码里的坏味道
结束语 (2讲)
结束语 | 写代码是一件可以一生精进的事
结课测试|这些代码坏味道的知识你都掌握了吗?
代码之丑
15
15
1.0x
00:00/00:00
登录|注册

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

郑晔 2021-01-30
你好,我是郑晔。
前面我们讲了很多代码的坏味道,我们的关注点都在代码本身上。知道了什么样的代码是坏味道,有了具体的评判标准。那么,该如何去运用坏味道这把“尺子”呢?
有一个发现坏味道的实践,就是代码评审,也就是很多人熟悉的 Code Review,Wikipedia 上定义是这样的:
代码评审,是指对计算机源代码系统化地审查,常用软件同行评审的方式进行,其目的是在找出及修正在软件开发初期未发现的错误,提升软件质量及开发者的技术。
大多数程序员都经历过代码评审,也都能够初步理解代码评审本身存在的价值,这也是差不多全行业都认为有价值的一个实践。只不过,每个团队在代码评审的实践差别还挺大的,有的团队是在一个完整的开发周期结束之后,做一次代码评审;有的是安排每周的代码评审;有的则是每天都要做代码评审。之所以会有这样的差异,主要就是团队对于代码评审本身的理解有差异。
所以,这一讲我们就来谈谈,到底应该如何理解代码评审。

代码评审是一个沟通反馈的过程

关于代码评审,第一个问题就是,为什么要做代码评审?
这个问题其实比较简单,没有人能够保证自己写出来的代码是没有问题的,而规避个体问题的主要方式就是使用集体智慧,也就是团队的力量。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《代码之丑》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥19.9
立即订阅
登录 后留言

精选留言(10)

  • Jxin
    原文: 把循环里对于一个元素的处理拆了出去。还没等我来赞美这段代码写得好,我就看到了单个元素处理的代码,每次都要查询一次数据库,找出相应的元素,做修改之后再存回去。

    结论,我认为这个每次查一次数据库没问题。

    决策依据:
    1.这样的单行操作更易理解。
    2.批查询可能伴随大事物(毕竟你是更新动作,可能要锁(悲观或乐观)所有数据行)
    3.如果更新操作不需要锁数据行,也就是数据行的变更对更新操作的正确性无影响。那么通过加缓存会是更好的解决方案。

    综上所述,保证业务逻辑简单是第一原则。
    2021-02-01
    4
  • 赵智慧
    老师,您说的太对了。因为一个敏捷教练,小波带领我们做了很多。
    例如:工程实践、每天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 不是一个结束,而是一个开始,发现了问题要去修改。我的团队发现问题后修改的工作量还不小,即便我们的频率已经算很高了,还是能发现不少的问题。所以,如果你们自己发现不了太多问题,可以引入别人的视角,帮你们发现问题。

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

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

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

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

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

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

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

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

    2021-01-30
    1
  • Geek2808
    自己团队其实也一直在做代码review,老大也比较重视。读完作者这篇文章感觉自己的收获就是review的方向有了:实现方案的正确性,算法的正确性和代码的坏味道。这点我觉得的可以在review的时候刻意注意的地方。
    特别认同作者说的刻意练习,不好的习惯,只能通过刻意的练习将其纠正过来。这个也是我最近自我感觉提高的一点,刻意的去做正确的事,慢慢的自己提高是很明显的。
    2021-01-30
    1
  • webmin
    来个新鲜的案例,昨天代码评审时发现的问题:
    ```java
    List<String> a = new ArrayList<>();
    //筛选数据,符合条件的添加到a中

    List<String> b = new ArrayList<>();
    a.addAll(b);

    //筛选数据,符合条件的添加到b中

    //结束返回a
    return a;
    ```
    对引用的认识不清楚,集合的addAll方法是把参数集合中的每一个Element添加到自己这个集合中,不是把集合做为一个Elements添加到集合中,形成多维关系。
    事后追问了一个问题,同一个对象添加到两个不同的集合中,然后再从其中一个集合中取出对象对其进行修改,问此时另一个集合中的那个对象的受影响吗?

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

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

    作者回复: 运气不错。

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

    作者回复: 这就是缺乏反馈的结果,自己不知道自己的代码究竟写得怎么样。

    你从开始学习这个专栏,其实,就已经进入到一个提高自己代码质量的过程里了,至少,现在看到有坏味道的代码,你应该能够发现一些了。

    接下来,你可以去读读书,比如像《代码整洁之道》、《重构》之类的书,还是要看一下的。接下来,就是在实践中,不断地去打磨手艺了。

    当然,如果你身边有人能够通过代码评审的方式给你反馈,你的提高会更快。

    2021-02-06
收起评论
10
返回
顶部