1、软件长期运营存在什么问题
一个大规模的客户端软件的生命周期中，我们可以把它分为两个比较粗的时期。一个是前期的搭建软件的时期，即从无到有的时期；第二个是搭建完成之后，进入的一个稳定的运营时期。第二个时期才是最关键的，在这个时期我们会持续的迭加需求，持续的优化功能，而且第二个时期也是代码在慢慢变质的时期。
在这个时期，你可能会发现：我们的软件慢慢出现模块耦合严重，牵一发而动全身；每个版本都会涌现出老功能的BUG，你没动过的模块也会出BUG；或者改了一个小问题了，带出来很多其他问题；缺乏扩展性，往老模块加新功能非常痛苦；程序的崩溃率越来越高；新员工接手老模块经常不能理解原来的设计思想而改坏；移植一个DLL到另一个软件时，发现必须连带也移植十几个DLL。本文将分享对于这些问题的思考与方法。
2.软件的积木模型
一个运营型的客户端软件，做出来就是为了长期运营，需要不断的迭加功能。而不是做出来，两三年就重写一次。那么这样一个软件就像堆积木一样。一个软件刚开始写了两千行代码，感觉设计得非常好，模块化扩展性都非常好，性能也非常快，都能很好的面向运营。写了两三年之后，就会出现像这种积木一样的结构，很容易崩塌。所谓重构，形象的说，可以看做是某个积木不稳定，要往里塞一塞。那么整个开发过程，就是一个不断迭代、不断优化、不断重构的过程。对于我们这个积木模形，有什么办法不让一些木条跑出来，这也是我们需要想的思路。我们是不是可以先围四面墙，然后在墙里面再去塔积木？
3.导致代码变质的两大因素
团队中总是会存在这样那样的问题，这些问题最终总是影响到我们的代码朝着不良的方向发展。对于这些因素，我可以将它们抽象为两大类。一类是人的因素：比如架构设计不合理，，需求没考虑清楚，项目进度压力，沟通问题，缺少文档、培训，等等。另一类是时间的因素：比如人员的变动，需求的长期迭加和变更，等等。人的因素是由于人本身的素质或疏忽导致，时间因素是由于时间的长期推进导致，即使人的素质很高也必然会出现时间因素的问题。
4.代码变乱的微观原因
在上述两大类因素的长期作用下，最终会导致代码越来越乱。如果从微观的角度来剖析，这跟依赖有着很大的关系。代码的变乱，根本原因就是由于太多不良依赖或者模块失去单一性所致。我们来看一下依赖是如何产生的。
1). 依赖的方式
如下图所示，如果组件A依赖于B，B依赖于C，A也是隐含的依赖于C的。组件A不能单独使用，必须同B和C一起使用。在现实的代码中，可能存在着非常长的依赖链。
依赖的方式也可能是多种多样的，单向依赖、双向依赖、环状依赖或者一个依赖于多个。下图也是一些示例，现实的代码中可能是由各种依赖方式组成的非常复杂的网状结构。
2). 依赖的变化
在两大类因素的作用下，依赖会发生变化。最常见的变化应该是依赖的箭头越来越多，网状结构变得越来越复杂。如果没有增加新的组件，下图中左边的图往往会变成右边的图。起初设计好的很好的代码，可能是左边的样子，模块具有很好的独立性和可移植性。随着时间、需求、人的变化，很可能由开发人员很随意的一行代码，就变成了右边的图，一条红线就出来了。两个模块变成相互依赖，上面那个模块就不再有独立性和可移值性。
我们的代码从设计之初到现在，中间经过了几年的时间，代码变得越来越乱很大的原因是因为这种红线的持续出现。本来有很多独立性很好的模块，变成了错综复杂的网状结构。
前面是没有引入新组件的情况，如果引入了新组件，必然会引入新的引赖，那么就要好好的去界定，引入的新组件是属于哪个层面的。像下面第一个图，新引入的组件依赖于原来两个组件是在最上层，第二个图新引入的组件是在中间层，第三个图新引入的组件被另外两个组件依赖在最底层。
引入新组件，其实应该做好充份的考虑，而不是让开发人员随意的引入。需要充份思考引入的新组件应该放在哪一层面才是最合理的，才有利于以后的扩展和移植。
可能读者会遇到这种情况，一个功能编译没有问题，测试也没有问题，发布后一两年也没有问题。当我们要把这个功能移植出来的时候，才发现问题大了。你想移植一个组件到另一个软件时，必须连带也移植十几个组件。
5.如何解决依赖
1). 组件网图
要解决依赖，首先要发现哪些是不正确的依赖。下图就是一个具有良好层次的依赖关系图，我们称之为“组件网图”。对于我们现实的软件中，我们非常需求这样一张图将整个软件所有组件的依赖关系绘制出来，以便于我们发现其中的错误依赖进行解决。
如果组件网图中存在错误的依赖关系，或者如果有需求要求图中的组件h依赖于g，应该怎么办？可以通过下面的“分解适配”和“升级降级”的方法进行解决。
2). 分解适配（单一职责）
分解适配是指将一个功能复杂的模块分解为多个具有单一职责的模块，那么模块间的依赖关系也会变得单纯。读者可以结合下面的案例理解这个方法。
3).升级降级
人生就是要感受美丽的善良的，丑恶的病态的。
