一般的,在软件公司,一个项目或产品都会经历迭代开发的流程,来不断的适应市场和不断满足用户(客户)的需求。从需求到原型,再到产品落地。经历了无数需求的变动,修复了无数的bug,但仍然有新的bug产生。

为什么系统的bug总是解也解不完,以及我们为什么要重构?

  1. 我们离最初的目标越来越远了。这跟我们最初,也就是我们写第一行代码之前的软件设计有关,因此分为两种情况:

    第一种情况:我们当初就没做架构设计,没有考虑到组件化和良好的封装,可拓展性很差,导致后面代码不断往里面堆,以至于看起来乱糟糟一团,一个地方修改,其他功能也不好使了,简直不忍直视。

    第二种情况:刚开始我们已经做好了架构设计,但是监管不力,或后面维护的人员水平参差不齐,没有理解架构的本意,到时各种业务耦合,把本该在下层子类里面做的业务逻辑,为了修改方便,直接在上层框架中修改了,从而在本该松散独立的上层架构模块里面混合了具体的业务。

    这两种情况都需要我们重构现有的代码。

  2. 有时候bug很多或者代码凌乱跟IT行业频繁的流动性有关。写代码是一个逻辑性很强的工作,而且每个人的思维模式都不大一样。这就要求我们广大开发人员对业界比较认可的设计模式和编程规范进行学习总结,这些才是通用的。但,事实是并不是每个人都对设计模式和编程规范都了解,中级以下开发者忙着练习基本功,无暇或者暂时不能理解设计模式,没有自己的编程思想,还没形成系统的知识体系,无法融会贯通。所以,对于一份流经多人之手的代码,如何理解真是有一千个哈姆雷特。所以我们的代码才会越改越乱。这就是为是什么新入职的员工,对老旧的不好理解的代码急着要进行重构的原因。


     但是,重构真的一定能使软件质量提高吗?

答案是:不一定。在我的职业生涯中,我见过好多重构失败的例子。好多的重构工作都是在仓促之间进行的,因为重构做为不能立竿见影看得见的经济效益,开发者很难说服上级领导和产品经理挪出时间进行重构,况且重构之后的结果,好坏各有一般可能。

       在我曾经供职的一个部门中,技术经理带领我们进行技术革新,对既有代码进行重构,以为一大批老员工被他们的leader带出去创业去了,我们作为一帮新人,要么看懂代码,要么重构。我们重构了内存模块,重构了网络模块,重构了UI组件。但是,经过几轮测试,我们的bug比较多,质量管理部门反馈,质量下降。……,然后,leader出走,公司出出进进有一帮人。而后来的leader,则采取的是,把重构放在迭代过程中,每次都进行优化,而不对代码大刀阔斧的进行重构,我们深知,那里面有很多坑,没有注释,注释过时,或临时处理逻辑。事实证明,这种策略是很成功的,版本质量得到了质的提升。


      

所以,总结一条良好的重构实践——“不要过早,过多的优化代码或进行重构,稳定可靠才是王道”。



注意:本文归作者所有,未经作者允许,不得转载
2017,颜值新招数