小猫维护现有的系统也有一段时间了,踩坑也不少,事故不少。感兴趣的小伙伴可以了解一下,往期的小猫踩坑记合集。
这天,小猫找到了商城系统的第一任开发老A开始聊天。
“你们这系统是真坑,我都吃过好多次亏了,太烂了...”小猫开玩笑地吐槽道。
“我们当时其实还是花了很长的一段时间去做设计以及评审的,每一步都是有严格把控的,当时系统总体骨架还是相当清晰的,也没有那么多新的概念,你说现在系统不行了,可不能怪我们啊。一会我给你原始设计文档看看。后面经过了太多研发维护了,甚至运营和产品都换了好几拨了,每任运营可能对当前系统的要求都不一样吧,大家理解可能都不同......”老A侃侃而言着。
小猫抿了口刚倒的茶,意味深长地看着老A...
相信有很多小伙伴都有小猫这样的体会,尤其是接手一个老的系统的时候,总是会吐槽当前的系统很烂,恨不得马上将其完完全全重构掉。
前段时间老猫还遇到一个比较逗的小伙伴,他想表达的意思大概是“代码写的烂也就算了,他居然还在注释里撒谎...”,结果他楼下哥们还在一个劲追问他的注释是怎么撒谎的,老猫当时边吃午饭边在刷手机,老猫看到评论后,笑到喷饭,当然在此也对这位小伙伴表示同情。
comment
其实很多时候一个系统的腐烂和破败并不是在开始的时候就出现了,而是在持续地迭代升级中渐渐腐化继而沦为“屎山”。
接下来咱们就来盘点一下到底是一些什么原因将一个原本架构清晰的系统腐败沦丧为复杂“屎山”的,然后咱们作为后来人又该如何应对?
概览
既然说到系统沦为“屎山”,那么什么样的系统会被定义成“屎山”呢?其实所谓的“屎山”即为非常复杂的系统,难以维护。John OusterhOut在A Philosophy of Software Design这本书中就已经提及了“复杂性就是使得软件难于理解和修改的因素”。
John OusterhOut将“屎山”(这里要说明一下,这哥们并没有说复杂系统叫“屎山”,哈哈,只是咱们都习惯这么叫了)归为三大类:
上述几类特种总结有点抽象,咱们来具体阐述一下。
变更放大其实就是说明明一个相当简单的需求,却要动到很多地方的代码。
相信大家在日常开发中应该也会遇到这样的问题。老猫也经常遇到,例如明明从需求的理解来说,只要加一个固定的校验逻辑,这个事情就应该可以搞定了,结果发现,改一个地方的校验逻辑还不行,可能还要动到各个地方的校验逻辑。这种情况往往是由于开发在写代码过程中复用没有到位,或者本身流程问题导致的。软件可拓展性变得很差。
认知负荷说白了就是相关的开发人员在进行开发任务的时候,需要花费很多时间去学习所需要的知识(当然这里大部分指的是技术知识)才能完成一系列开发任务,于此同时,如果某个知识点没有掌握好,可能会导致未知的Bug。
打个比方,大部分的开发还是比较倾向于自己熟悉的编程语言或者是开发框架,以及中间件的。例如,前后端分离虽然好,DDD虽然好,但是对于简单的内部管理系统而言,明明一个mvc就能搞定的事情,非得搞成前后端分离,加上DDD设计分层。明明一个人天就能搞定的事情,非得搞成三人天,另外的维护者可能还得花时间去研究相关技术,这种盲目追求最新技术增加系统本身实现复杂度就是一种本末倒置的行为。
当然认知负荷有的时候可能也不一定是新技术带来的,也有可能是纯粹的技术实现烂,例如不恰当的接口设计、混乱的命名,还有“爱撒谎”的注释等等。
未知的未知是最要命的,例如,当我们从产品那边得到一个需求的时候,我们甚至不晓得为了完成这个需求我们到底需要修改哪些代码才能完成,当前开发甚至还不清楚相关的业务知识。
这种很多时候体现在咱们接手一个新项目的时候,尤其是项目比较复杂的情况下,并且此时的项目没有任何的技术文档,这种情况下我们往往是抓瞎的,非常被动,即使对代码调整完毕之后心里也还是会没底,涉及的一些业务场景甚至都没有理清楚。也不晓得调整完毕之后会不会出现新的问题。
从技术侧聊聊,复杂系统发展的诱因,UML之父Grady Booch在《面向对象分析和设计》的观点是,软件的复杂性是一个固有属性,并不是偶然属性,软件的发展必然会伴随复杂性。
诱因有下面三个:
就像上面小猫和老A的对话那样,其实很多时候,系统的腐烂并并不是发生在最开始。
很多后端研发在接手新的系统之后,往往对其设计的理解其实是不够深入的,来了需求之后就是一顿“兵来将挡水来土掩”,可以说是一种战术性编程,或者说是“应付式编程”。
这种编程的特点有下面这几种:
上述共同特点就是缺乏设计,完全聚焦于快速交付,注重短期价值不考虑未来发展。
那么为什么会这样的呢?可能会受到以下三点的影响:
上面聊了这么多,我们也大概知道了为什么我们的系统会逐渐沦为“屎山”,可能是在软件发展过程中的必然,其中也掺杂着各种人为因素以及非人为因素。当然事情还是要去解决的。那么我们应当如何应对呢?
上述就是老猫对系统沦为“屎山”的一些看法,另外的,希望大家比较再提“防御性编码”这类概念。这种思想就不应该是一个合格程序员提出的。老猫对这类还是比较抵触的。“难不成螺丝钉以为自己螺纹角度独特就不会被取代了?”,咱们把自己负责的东西尽量做到完美,是金子总能发光的,小伙伴们,你们觉得呢?