江苏龙网

  1. 首页 > 资讯 > 科技 > >

有意思：Code Review是一场苦涩但有意思的修行( 二 )


四、我们比拼的不是代码行数
在 Code Review 过程中 ， 发现有些方法 ， 重复用到一段逻辑 ， 这段逻辑如果不抽取出来成为一个方法 ， 未来的修改就成了一个必须多点全部修改的大坑 ， 稍有不慎 ， 容易遗漏 。
重复代码在提交行数上 ， 似乎挺壮观的 。如果在同样的效果上 ，3 行代码能够实现功能的价值 ， 就不应该用 4 行来实现 。我们经常说晒出代码行数 ， 并非是单纯地鼓励代码行数多 ， 而是提倡大家去写代码 ， 写优质的代码 ， 优质的代码一定是少即是多的原则 。代码的实现 ， 不要像鲁迅先生说的一样：懒婆娘的裹脚布又臭又长 。
五、用户视角的成功与失败
在交付时 ， 调用服务失败 ， 然后返回前台一个空列表 ， 那么前端业务的展示是后台数据正常 ， 这个人不拥有数据列表 ， 这明明是对数据的一种曲解 。所以 ， 后台调用服务失败 ， 就应该明确告诉前台 ， 服务出错了 ， 这个用户有没有数据 。系统出错的信息给用户看 ， 合适吗？不合适 。前后端的用户交界面上 ， 往往飞着两类信息：错误码、错误信息 。
这样够了吗？用户提示需要额外地再给出来 ， 往往根据不同的错误码 ， 有不同的用户提示 ， 可能是一个多对多的关系 。多个错误码 ， 提示给用户的信息：请输入必填项 。多个用户信息 ， 可能也对应一个错误码 。一般来说后台承包这三者的联动关系 ，json 串推送给前端时 ， 前端拿来主义即可 。
六、有重复使用的量一定要找个地方集中隔离
不管是变量 ， 还是常量 ， 工具类 ， 如果是多个地方同时用到 ， 那么如果硬编码在代码或者沉淀在包里 ， 未来一定是一个灾难 。
比如 ， 一个组装 SQL 语句的代码 ， 到处都是 "from" "where" "limit"， 都是这类语句直接写死在代码中 ， 注意问题来了 ， 这些单词前后都需要加空格 。有时候在复制粘粘时 ， 发现少了一个空格 ， 出现的问题 ， 往往是致命的 。再比如 ， 一个互相约定的分隔符 “###”， 定义在本类中 private String， 这明显是两个共同遵守的常量 ， 单独定义的结果就是容易造成不匹配 。隔离的目的是复用它 ， 保护程序地正常运行 ， 易于维护 。
七、单测没必要代码Code Review
单测有时候感觉像是阑尾 ， 有或没有感觉都是无关紧急 ， 这是错误的观点 。单测感觉就是一个任务 。你写单测了吗？写了 。单测是否需要 MOCK， 是否进行边界值测试 ， 是否用例覆盖到业务场景 ， 这都也是 CR 的一部分 。单测写得好 ，BUG 肯定少 。
需要调试来查找错误时 ， 往往是一种对异常处理机制的侮辱 。
良好的日志和异常机制 ， 是不应该出现调试的 。打日志和抛异常 ， 一定要把上下文给出来 ， 否则 ， 等于在毁灭命案现场 ， 把后边处理问题的人 ， 往歪路上带 。别人传一个参数进来 ， 发现是， 立马抛出来一个参数异常提示 ， 然后也不返回哪一个参数是， 这在调用参数很多的情况下 ， 简直就是字谜游戏一样 。
到底是抛异常 ， 还是抛错误码？我不管抛什么 ， 反正错了什么东西 ， 都应该透明出来 。到底是抛受检异常 ， 还是非受检异常 ， 我只想说 ， 没有充足的理由 ， 不要乱抛受检异常 。异常抛出时 ， 一定要自己消化干净 ， 告诉别人说我的方法签名抛的是 AbcException， 实际运行中 ， 代码某个地方直接抛出 EfgException， 这也是不负责任的 。
八、多个return的语句 ， 概率高的一定先进行判定
if(condition1) return; if(condition2) return; if(condition3) return ; 那么需要评估一下 condition1/2/3 出现概率的大小 ， 概念大的在最前边 ， 尽可能快地进行 return， 不需要进行后续无谓的匹配 。
不要总觉得计算机跑得快 ， 不差这点蝇头小利的 ， 这种思维 ， 和《南辕北辙》里的寓义一样的吗？
九、吝啬空行
感觉空行是廉价的 ， 到处乱扔是一种；另一种是感觉空行是昂贵的 ， 舍不得用 ， 这种情况更多见 。50 行代码没有一个空行 ， 就像英语 50 句话 ， 没有任何标点符号一样 。既然标点符号起到隔断和语义区分作用 ， 我们的空行不是同一个道理吗？在以下情形:


推荐阅读


上一篇：「高价」从2199降至1599，华为“低配高价”中端机，网友：真香

下一篇：「广告」理想ONE“断轴”又“着火”品控令人忧；LG广告被广大网友怒怼