分享是最有用的学习办法。
博客：blog.ktdaddy.com/
布景
小猫保护现有的体系也有一段时刻了，踩坑也不少，事端不少。感兴趣的小伙伴能够了解一下，往期的小猫踩坑记合集。
这天，小猫找到了商城体系的第一任开发老A开端聊天。
“你们这体系是真坑，我都吃过好多次亏了，太烂了…”小猫恶作剧地吐槽道。
“我们当时其实仍是花了很长的一段时刻去做规划以及评定的，每一步都是有严格把控的，当时体系总体骨架仍是适当明晰的，也没有那么多新的概念，你说现在体系不行了，可不能怪我们啊。一会我给你原始规划文档看看。后面通过了许多研制的手了，乃至运营和产品都换了好几拨了，每任运营或许对当前体系的要求都不相同吧,我们了解或许都不同……”老A侃侃而言着。
小猫抿了口刚倒的茶，意味深长地看着老A…
写在前面
信任有许多小伙伴都有小猫这样的体会，尤其是接手一个老的体系的时分，总是会吐槽当前的体系很烂，恨不得立刻将其完彻底全重构掉。
前段时刻老猫还遇到一个比较逗的小伙伴，他想表达的意思大概是“代码写的烂也就算了，他居然还在注释里说谎…”,结果他楼下哥们还在一个劲追问他的注释是怎样说谎的，老猫当时边吃午饭边在刷手机，老猫看到谈论后，笑到喷饭，当然在此也对这位小伙伴表示同情。
其实许多时分一个体系的腐朽和破败并不是在开端的时分就呈现了，而是在持续地迭代升级中逐步腐化继而沦为“屎山”。
接下来我们就来盘点一下到底是一些什么原因将一个原本架构明晰的体系糜烂沦丧为杂乱“屎山”的，然后我们作为后来人又该如何应对？
“屎山”特征
既然说到体系沦为“屎山”，那么什么样的体系会被界说成“屎山”呢？其实所谓的“屎山”即为十分杂乱的体系，难以保护。John OusterhOut在A Philosophy of Software Design这本书中就现已提及了“杂乱性便是使得软件难于了解和修正的要素”。
John OusterhOut将“屎山”（这里要阐明一下，这哥们并没有说杂乱体系叫“屎山”，哈哈，仅仅我们都习气这么叫了）归为三大类：
- Change Amplification(改变扩大)
- Cognitive Load(认知负荷)
- Unknown Unknowns(不知道的不知道)
上述几类特种总结有点笼统，我们来具体化阐述一下。
改变扩大
改变扩大其实便是阐分明一个适当简略的需求，却要动到许多当地的代码。
信任我们在日常开发中应该也会遇到这样的问题。老猫也常常遇到，例如分明从需求的了解来说，只需加一个固定的校验逻辑，这个作业就应该能够搞定了，结果发现，改一个当地的校验逻辑还不行，或许还要动到各个当地的校验逻辑。这种情况往往是由于开发在写代码过程中复用没有到位，或许自身流程问题导致的。软件可拓展性变得很差。
认知负荷
认知负荷说白了便是相关的开发人员在进行开发使命的时分，需求花费许多时刻去学习所需求的常识（当然这里大部分指的是技能常识）才干完结一系列开发使命，于此一起，假如某个常识点没有把握好，或许会导致不知道的Bug。
打个比如，大部分的开发仍是比较倾向于自己熟悉的编程语言或许是开发框架，以及中间件的。例如，前后端别离尽管好，DDD尽管好，但是关于简略的内部管理体系而言，分明一个mvc就能搞定的作业，非得搞成前后端别离，加上DDD规划分层。分明一个人天就能搞定的作业，非得搞成三人天，另外的保护者或许还得花时刻去研究相关技能，这种盲目追求最新技能添加体系自身完成杂乱度便是一种舍本求末的行为。
当然认知负荷有的时分或许也不一定是新技能带来的，也有或许是朴实的技能完成烂，例如不恰当的接口规划、混乱的命名，还有“爱说谎”的注释等等。
不知道的不知道
不知道的不知道是最要命的，例如，当我们从产品那儿得到一个需求的时分，我们乃至不晓得为了完结这个需求我们到底需求修正哪些代码才干完结，当前开发乃至还不清楚相关的事务常识。
这种许多时分表现在我们接手一个新项目的时分，尤其是项目比较杂乱的情况下，而且此时的项目没有任何的技能文档，这种情况下我们往往是抓瞎的，十分被迫，即便对代码调整结束之后心里也仍是会没底，涉及的一些事务场景乃至都没有理清楚。也不晓得调整结束之后会不会呈现新的问题。
“屎山”诱因
从技能侧聊聊，杂乱体系开展的诱因，UML之父Grady Booch在《面向对象分析和规划》的观念是，软件的杂乱性是一个固有特色，并不是偶尔特色，软件的开展必然会伴随杂乱性。
诱因有下面三个：
-
含糊性：含糊性发生了最直接的杂乱度。 老猫的了解，关于含糊性包括其实有两层，一个是需求含糊性，第二个技能含糊性。产品司理对实际的事务把控没有做到很精准，存在含糊性，导致体系自身的事务掩盖点常常发生改变，这种是导致体系杂乱的罪魁祸首之一。第二技能侧的含糊性，技能侧的含糊性当然就包括研制人员自身对事务把控不到位，另外的在界说API以及办法命名变量命名的时分存在含糊，无法通过命名直接了解想要表达的意思。
-
依靠性：含糊发生杂乱性，而依靠导致杂乱的传递，不断外移的杂乱性将导致终究体系无限腐化，质量失控，修正本钱指数级增长。打个比如一个不合理的完成办法被我们认为是一套标准的完成办法，然后后面的许多事务代码为了方便都会去复用这段逻辑。但是这种不合理的完成办法还在不停的迭代，所以之后体系会开展成什么样子，我们可想而知了。
-
递增性：一个软件体系不管多么杂乱，都是从第一行代码开端的。然后逐步“生长”。随着事务开展，需求不断发生，功用逐步丰厚，软件体系随之演进，一起抛弃而未被及时铲除的代码也是日益膨胀。终究构成一个杂乱的体系。 这点信任了解起来仍是比较简略的。
体系“腐朽”的真相
就像上面小猫和老A的对话那样，其实许多时分，体系的腐朽并并不是发生在最开端。
许多后端研制在接手新的体系之后，往往对其规划的了解其实是不行深化的，来了需求之后便是一顿“兵来将挡水来土掩”，能够说是一种战术性编程，或许说的难听些“应付式编程”。
这种编程的特色有下面这几种：
- 快。这类程序员为了快速处理产品需求，总是以腐化体系为代价去处理问题。通过他们之手保护的体系可拓展性差。
- 高产。这类程序员代码量极大，或许不择手段，彻底不会考虑复用，许多时分处理问题便是cv大法。
- 坑。他们往往仅仅专注于功用堆砌却忽略规划准则和规划标准，有时分命名标准乃至都懒得遵从，本钱放到未来，后人买单。我们常常说到的倒运的小猫便是常常买单的那位。
上述一起特色便是缺少规划，彻底聚焦于快速交付，注重短期价值不考虑未来开展。
那么为什么会这样的呢？或许会遭到以下三点的影响：
-
研制人员自身的水平以及认知还有责任心。研制人员自身认知不行，意识不到体系其实是需求考虑拓展性的，这种往往也是没有办法的，另外一种是研制人员抱有侥幸心理，尽管意识到拓展性的问题以及规划问题，但是比较懒，本着“多一事不如少一事，反正我仅仅过客”的心态去做体系。这类往往在外包体系中表现更为扩大。
-
互联网布景下，老板为了快速习惯市场，会进行大量事务试错，这就会要求程序员快速开发。许多程序员想要好好规划一下体系，但是无法退让于项目司理的一而再再而三的问你上线时刻。这种情况下，规划或许就成了一种奢华。
-
考评体系不合理。老猫有个朋友，之前一天他和我们吐槽，他们现在领导需求拉出他们每天写代码的量去看看他们每天干了多少活。这种真的是滑天下之大稽，在这样的考评体系下面，程序员还会好好写代码么。当然这种往往是发生在领导屁都不明白研制的公司。这类领导也是老猫最最轻视的。技能上分明屁都不明白，还要装x去指指点点。
“屎山”应对之道
上面聊了这么多，我们也大概知道了为什么我们的体系会逐步沦为“屎山”，或许是在软件开展过程中的必然，其间也掺杂着各种人为要素以及非人为要素。 当然作业仍是要去处理的。那么我们应当如何应对呢？
-
寻觅适宜的架构
当我们接到一个杂乱体系的时分，其实首先需求理清楚相关的架构，知道体系是如何进行模块拆分的，另外它们的协作关系和通讯办法。具体操作，我们能够访问老猫之前写的体系梳理大法
-
遵从规划准则 组件层面，我们的规划准则需求遵从复用/发布同等准则，一起闭包准则，一起复用准则，无依靠环准则，安稳依靠准则和安稳笼统准则。 代码层面，能够参阅老猫之前梳理的开发中需求遵从的规划准则。
-
防止破窗效应
这里的“破窗效应”其实是出自David Thomas Andrew Hunt的著作《程序员修炼之道》，一扇破窗，只需一段时刻不去修补，修建中的居民就会耳濡目染地发生一种被遗弃的感觉————当权者不关心这幢修建。然后其他窗户也开端损坏，居民开端乱丢废物，墙上开端乱涂鸦，修建开端呈现严重结构性的损坏。
聊到我们软件体系侧其实也是相同的，在体系开展的过程中，只有在我们修正历史遗留的问题时，才是真正对其进行了保护。假如我们运用一些极点的手段保持古老陈腐的代码持续作业的时分，这其实是一种苟且。例如为了临时处理问题写hotfix接口等等。
在我们开发的过程中，一旦体系有了规划缺陷，我们其实应该及时优化，否则会构成欠好的示范，更多的后来者会倾向于做出类似规划，然后加速体系腐化。
总结
上述便是老猫对体系沦为“屎山”的一些观点，另外的，希望我们比较再提“防御性编码”这类概念。这种思维就不应该是一个合格程序员提出的。老猫对这类仍是比较抵触的。“难不成螺丝钉认为自己螺纹视点共同就不会被替代了?”，我们把自己担任的东西尽量做到完美，是金子总能发光的，小伙伴们，你们觉得呢？
