软件的腐化之路
软件腐化之路
本文并不是吐槽,而是总结开发过程中软件腐化的各种原因,希望基于此思考如何解决软件腐化的问题.
需求不明确
项目已有第n个版本,现开发第n+1个版本,但是需求不明确,导致可能无法将新需求融入到现有的设计,可能要调整现有设计,可能不要改.如果需求不明确,又要开始干活,那么可能到需求明确的时候,已经没有资源去做相应的调整了,这个时候通常会用各种hack方式实现功能,为后期版本埋坑.
定义不明确、概念不一致
软件中最大的bug,就是概念不一致–人月神话.
概念不一致,一会儿它是这个意思,我们用这种方式处理,一会儿它又是那个意思,我们又用另一种方式处理.等到两个概念在某个功能点上发生冲突的时候,bug就产生了.于是通过各种hack手段去解决,然后后面的人加新功能的时候,不一定了解这一段历史,于是就掉坑里面去了.
目标扩大
项目第一个版本,定义了项目的功能边界.
但是后续版本迭代往往会扩大项目的功能边界.
如果扩大的太大,可能需要重新定义整个软件,从设计到实现,从交互到接口到表设计,都需要重构.如果只接受目标扩大这种变化,不欣然接受项目因此需要重构这种事实,就容易使软件腐化.
重构阻力
好的代码不是写出来的,是重构出来的.
一些功能,可能由于各种原因,用了各种hack方式实现.
然后当你想优化它们的时候,往往就有一些声音:“改出问题了怎么办?”,“能提升多少性能还是能提高多少并发?”
(其实程序有很多属性,性能和并发只是其中两种,可读性易拓展易测试等也是程序的重要属性)
当一个程序,发展到几乎没有机会重构的时候,它就已经腐化了.
并不是说每一个版本,一定要重构,但是涉及到概念一致性问题的时候,是一定要重构的.
人员水平参差不齐
工期紧张
频繁更换模块负责人和开发者
管理者往往为了降低人员流动风险,会让不同的人在不同版本开发同一个模块.
但是频繁变更模块的开发人员,会让软件更快的腐化.
新的开发人员并不是该模块最熟悉的人,并不清楚所有的业务细节,哪些地方待优化,哪些地方有特殊处理,哪些地方有技术问题,哪些地方有遗留问题需要解决.所以不能充分有效的利用之前已经积累的知识来解决现有的问题,也无法应用后续的研究成果来优化.这样就没有用最高的效率更好的设计来实现功能,也没有足够的勇气去改动现有的代码.
不好的设计
不好的实现
未清理废弃之物
由于版本迭代,一些无用判断,无用类,无用方法存在于项目中,干扰开发人员对程序逻辑的阅读,影响判断,有些地方由于无法读懂,就不敢去改,于是就失去了优化的可能性.
追求业务代码复用导致巨大的畸形怪物
滥用DRY原则,认为只要是重复代码就不应该存在,将一些和具体业务场景关联紧密的逻辑封装成公共逻辑,然后新需求来了,又在这些公共方法里面加一些对特定场景的if-else判断,实际上这段逻辑已经不通用了.别人调用这个方法的时候,如果不熟悉里面的逻辑,只看方法签名以为功能实现了,实际上对应场景并没有被处理,于是bug产生了.一旦这样的代码多了,开发者就需要耗费相当多的经历来深入到各个方法内部,了解细节,才有信心认为功能已经实现.
工具框架选择
选择更好的工具,可以更高效的开发,预留更多的时间进行程序的优化,避免将不好的代码遗留到以后.特别是追求稳定性的项目,往往代码不能轻易修改,一旦上线,后期很少有优化的机会.所以需要在第一次上线之前,尽可能的做好.而现实中往往工期紧张,没有好的工具支持,优化这样的事情就很难.