解耦和复用，软件开发的两大命门

软件已经成为信息社会的核心的产品，我们的生活和生产，处处离不开软件，随着智能社会的到来，软件更是无处不在。

但是软件的生产（开发）过程一直一来都存在效率低下，管理混乱，变更麻烦，质量不稳定等问题。这是因为，软件永远是一个在路上的产品，因为人们对智能化的需求没有止境，因此对软件的要求就没有止境。另一方面，软件不是一个有形的东西，它和电脑、手机等这些有形的东西不一样。有形的东西，人们比较倾向于买到什么样子就是什么样子，不会说改来改去。而软件就是因为太“软”了，客户就希望揉面团一样揉来揉去。因此人们在使用的过程中，当有新的要求的时候，就希望这种新的要求能即时的体现在软件的功能里面，因此，软件面对的唯一不变的就是变化。因此，适应变化的能力，就成为衡量软件生产过程是否高效智能的指标。同时，软件开发本身的技术是一个非常重要的基础性的领域，直接决定了一个国家的信息化的技术水平，因此，将软件开发技术的革新作为企业使命，也意味着对国家的一份责任。

我们通过长期的实践发现，解耦和复用是软件开发的两大命门，谁能在这两大命门上提出革新，谁就会掀起软件开发领域的一场革命。

要理解解耦，就需要理解软件的耦合。事实上，只要一个物体是由很多部分组成，都存在耦合，不仅仅是软件。例如房子，由砖啊、钢筋、水泥什么的组织在一起，这些不同物品就需要粘接在一起，动其中一个，就可能会影响到其他的部分，这就是耦合。什么是解耦呢？还是拿房子来看，例如门和墙，是连接在一起的，假如我要换一个门，我不需要对墙有什么变动，只需要把门卸下来，重新装上另外一个门就是了，这就是解耦。但是，这里有一个前提条件，就是门和墙的连接是活页，这个活页即适合这个门，又适合另外一个门，否则要是换一个门，连接器就要换，那就可能对墙造成破坏；第二，门的大小一定要正合适，如果第二个门比第一个门大，或者比第一个门小，那么都需要对墙体重新调整，这也会造成对墙体的破坏。因此，我们发现，要实现解耦，必须要有标准的接口，这个接口包括连接接口和装配接口。

软件其实也是一样，软件是由各种各样的模块组合在一起的，这些模块之间有着千丝万缕的联系。而且，我们发现，软件各个部分之间的数据关系更复杂，同时，这种数据关系还会不断的发生变化，因此要实现彻底解耦难度更大。还是拿房屋来举例，一般来说，为了美观，一个房子的电线一般走暗线，这些线往往是埋在墙里面。假如，某一天某个电线出问题了，或者是这个房子需要扩展，需要改变电线线路，那么问题就麻烦了，我们不得不把墙体打开，然后把线路重新调整，这就把墙体给破坏了。软件之间的数据关系，逻辑关系，更像房屋部署的电线，是藏在各个模块里面的，有时候变更一个模块，不得不把相关得模块都进行改进，这就导致了软件变更的麻烦。更麻烦的就是底层数据结构的改变，对于软件来说，底层数据结构就好比地基，我们知道，房屋的地基一变，整个房子就可能推倒重来，软件也一样，底层数据结构的变动就可能导致整个软件从上到下的变更，甚至推倒重来。所以，我们发现，对于软件来说，操作层面的解耦比较容易，中间业务逻辑层解耦相对麻烦，而底层数据库的解耦最为困难。如果有一种技术能够把操作层，业务层，数据结构层都能实现彻底解耦，那么，这个解耦就是一场革命性的技术。

我们再来看复用。所谓复用，就是可以重复利用。对于软件来说，复用的价值是非常大的，复用可以大大的节省开发时间。复用也不是说简单的复制粘贴，也不是一成不变的引用，而是可以在调整的基础上再次利用，这个也算是复用。

复用和解耦是密切关联的，如果耦合度过高，你必须把耦合在一起的都复用过来，这样的复用，其实效率很低。例如，对于很早以前的软件，面向过程开发，模块和模块之间都是硬耦合在一起，这个时候，你发现，需要把软件整个复用过来，然后再二次修改，因为，你发现单单复用个别的模块不行，都是纠缠在一起，只能都拿过来。

再后来，面向对象开发，人们把很多通用的标准的模块提取出来，开发成通用类，这些类有标准的接口，供其他类调用，这个时候，这些通用类就能很好的单个复用。另外就是很多开发人员总结出了整体框架，把一些环境和工具类、通用类做成一种开发结构，开发人员可以把整个框架复用过来，也是很标准的，也会省区很多开发工作。目前，主流的复用就是这种模式，即通用类和通用框架复用。但是，一旦涉及到和业务相关，就会有具体的业务逻辑，以及具体的数据结构，这个时候，业务逻辑耦合，数据结构耦合度太大，在这个层面上的复用就很糟糕了。现在比较热门的微服务架构，或者是中台战略，其实是在业务层面上解耦，例如，原来是10个业务放在一个软件里，现在将10个业务分离出来，每个业务成为一个独立的服务或者独立的软件。但是这种模式并没有彻底解决，首先，每个业务内部的业务逻辑还是耦合在一起，无非是原来10种耦合，换成了1种耦合，量上有变化，质上无改善。二、每个业务的所涉及的数据结构仍然制约着上下左右，数据结构的变化同样会导致一系列的变更。三、这种复用还是单层复用，无法实现无限嵌套。也就是说，假如我需要一个类似的服务，我就去把同样的服务拷贝一份，然后再调整。但是，能不能实现服务里面嵌套服务，嵌套的服务再嵌套，以至于层层无穷迭代嵌套。这是目前无法实现的。四、服务分离出来，需要增加额外的开销管理这些服务，这些额外的开销也需要开发。总之，微服务架构或者所谓的中台，虽然很热，但是都没有彻底解决问题。

我们的构件技术，无论是从操作层面还是业务逻辑层面，甚至是数据结构层，都实现了彻底解耦。以数据结构来说，数据结构的变化，只需要更改配置文件，而不需要进行代码上的变更，甚至数据访问服务也无需任何变更，就能实现软件的更新。这套技术极大的提升了开发效率，开发者不必为每次数据结构的变化而痛苦，而在以前，每当数据结构变化，就会从数据访问层，到业务逻辑，然后是UI层，层层变化，改完了，还需要重新部署服务，真的很痛苦，现在是彻底解脱了。

因为在解耦上的彻底，因此，构件的复用也做到了极致，可以层层嵌套复用，极大的提升了复用的空间。