从技术债务的角度, 谈谈重构

首先, 何谓重构(Refactoring)?

它的名词定义是：对软件内部结构的一种调整, 目的是在不改变软件可观察行为的前提下, 提高其可靠性, 降低其修改成本.

关于技术债务(Technical Debt):

开发团队在设计或架构选型时, 从短期效应的角度选择了一个易于实现的方案. 但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务。

简单的说就是为了快速地解决问题, 而采取的不规范的方案, 从而糟了报应, 哈哈.

举个例子

对于房贷, 大家肯定每个月都记着去还.

但是, 对于技术债务，大家似乎都不那么关心.

比如某小白同学在一个class中欠下了技术债务，例如不责任的写了一个15个参数300行的大方法, 之后的几个星期他对这个类进行扩展、修改，老板催的急, 错上加错, 最终: 一个20个参数, 600行的超级变态method产生了。

然而，这个东西不一定谁借谁还，可能是一个人的事情,也可能是一个团队的事情,

我们再来假设一下: 这个小白同学离职了.....

那么，这笔债务就压在了工作接替者的身上，古人语：父债子偿，那么这个应该就叫: 爱TM谁谁吧.........

用不了多久，整个开发团队就会发现我们已经无力偿还这份技术债务啦，只能重构啦, 而且这个重构还是属于最难, 代价最大的一种重构方式, 计划性重构(Planed Refactoring), 也就是不得不将重构计划加入到产品的backlog里面.

刚才讲了什么是计划性重构(Planed Refactoring), 我们接着来说下一种: 理解性重构(Comprehension Refactoring)

直接上图

这段代码的注释是多余的, 导致了我们理解不够直观, 所以我们应该删掉注释, 用变量名来直接和变量意义关联, 简单直接 !

上面的都了解了吧

接着来!

预先重构(preparatory refactoring)

大家还记得这张图吧, 最后走曲线的小球先到达了重点, 所以当我们着手新的feature时, 我们不妨进下心来, 审视下代码, 是否在coding之前, 先优化一下, 重构一下现有的代码, 然后再心情舒畅的, 高效率的实现新功能呢?

最后一个

计划性重构(Planed Refactoring) 它爸爸

长期重构(Long Term Refactoring)

技术债务已经积累到极其严重, 重构需要分配一个开发团队, 占用整个一次或多次敏捷迭代才能完成, 这种情况和计划性重构(Planed Refactoring) 都要尽量避免

长期重构(Long Term Refactoring)不多说你懂得!

码字不易, 谢谢大家!