今天上班修复一个bug的时候，发现自己原来写的一个函数已经被改的丑陋不堪。作为一个有原则的程序员，这样的事情最不能忍受，拯救代码之余，也有了下边的一些关于如何写好代码的想法。
在订单系统里有一个计算发货倒计时和确认收货倒计时的逻辑. 这个函数刚刚写出来时是这个样子, 看起来没什么大问题问题, 函数不太长, 逻辑也很直观. 当然如果较儿真的话这个函数有优化的空间, 但是现在动力不足, 不至于去重构.
如果没有新的需求驱动修改这个函数的话, 可能这个函数一辈子也就这样了.
突然有一天, 新的逻辑来了订单可以支持延迟发货和收货. 所以相应的这两个倒计时也要加上extend的天数. 接下来, 这个函数演变成这个样子.
现在这个函数看起来不爽了. 1. 重复的代码: (Instant.now().getEpochSecond() - order.getUpdatedAt().toInstant().getEpochSecond())出现了两次, getEpochSecond()出现了四次; 2. 对××DaysCount > 0 的判断也出现了两次; 3. 冗余的，嵌套的if结构, 这直接影响了代码的整洁和美观. 函数不大, 坏味道不少. 除了这些坏味道, 里边还隐藏着时间单位的错误(姑且命名这个错误为坏坏). 其实这个时候重构的时机已经成熟了.
如果当时代码修改者在写完这段逻辑之后, 驻足反思, 重构一下, 那么这段代码会以一个全新的面孔面对下一个代码修改者. 无疑一个逻辑清晰, 展现美观的函数, 是你留给队友最大的惊喜.
但是, 这样的惊喜最终还是没有留给队友. 终于有一天, 坏坏浮出水面, 导致页面显示错误, 出现了离谱的天数. 这个bug交给了蛋蛋解决. 蛋蛋眼明手快一眼定位到了坏坏. 把时间单位统一为SECOND, 一切working as expected.
高兴之余, 蛋蛋点着一根烟, 眉头紧锁, 若有所思... 其实他脑子里在演绎着重构心法:
- 首先我要把计算日期差值的重复逻辑去掉. Java8, 提供了方便的Duration类, 哪个Low B笨到自己去计算(殊不知, 这段代码就是蛋蛋自己写的);
- xxDaysCount > 0, 这个if判断, 我想通过加法结合律去掉. 经过缜密的调查确实是这样可以这样做, xxDaysCount在程序的上下文中是非负的, 用加法结合律改进没有问题;
- time这个命名也有问题, 词不达意.
"啪啪啪..." 半根烟之后, 尘埃落定. 代码被整容成下边这个样子. 蛋蛋拿起剩下的半根烟, "嗯, 代码少了六行, 明显的重复代码也没了, 讨厌的if也被我干了..." 看起来比较顺眼了.
心得:
- 代码不会变好, 只会逐渐变烂. 每一次修改代码都会让代码变烂, 多思考, 多重构可以代码变烂的速度减慢.
- 每次修改代码都是重构的最好契机.
- DRY & DRFY. 好代码最基本的两个原则: Don't Repeat Youself; Don't Repeat Fucking Yourself.
