过度封装如何毁掉项目

过度封装如何毁掉项目

大家在平时开发过程中是否见过在现有spring boot或者asp.netcore官方web开发框架基础上二次创作产生的新框架，例如C#的ABP或者java的javaboot都是基于各自官方基础框架基础上产生的，他们都内置了大量web开发需要的各类组件，例如ORM，对象映射，Redis组件，Rabbitmq组件，Kafka组件，Mongodb，Swagger，Grpc，甚至微服务治理的各类组件，例如Consul,SpringCloud Gateway，Eureka,Ribbon等等，号称为了开发效率内置全家桶就是为了二次封装优化使用方式简化开发人员使用成本和升级成本，那这样真的提高了效率吗，真的达到了降低升级的成本吗？

大杂烩

第一类封装目的就是为了一次性把所有用到用不到的组件都放到一个jar包或者nuget包中，只要封装者能想到的一定会一股脑封装进去，他觉得这样这样会免去使用者手动安装jar包或者nuget，免去初始化代码，免去所谓原生不友好的使用方式，（几年前我也一直这样搞。。。）现在产生了几个致命问题。

• 1、隐藏了原生使用方式，无法利用现有互联网资源解决问题。
• 2、新框架造成新的学习成本，往往这对开发人员没有任何价值，甚至新的学习成本远远大于原生方式，最后只能产生没有意义的新框架学习之旅！
• 3、隐藏了处理细节，给问题排查造成新的困难。
• 4、组件之间的耦合关系导致新框架愈发臃肿和混乱，复杂度不断提高。
• 5、组件的依赖关系使组件替换难度增大。
• 6、大杂烩的封装使组件在整体框架中看起来更加复杂。
• 7、整体组件过大，运行期间会加载所有组件导致内存浪费
• 8、以上问题导致导致项目维护成本居高不下甚至烂尾。

往往我们只看见了问题的一方面，大家可以在日常开发中观察一下开发最大的成本在哪里，不是组件使用不便利导致的开发周期长，也不是因为多了初始化代码，更不是无法统一升级组件导致的成本，而是维护代码时产生的代码阅读成本，理解成本！

隐藏原生组件

还有一类封装就是在其他组件基础上再加一层壳，这层壳可能就是做两三行代码的事，但就是为了这两三行代码产生新的层级关系，导致使用者无法感知底层组件，所有的方法都被重命名，重新分配在新的类名中。现在依旧产生了几个致命问题。

• 1、隐藏了原生使用方式，无法利用现有互联网资源解决问题。
• 2、新框架造成新的学习成本，往往这对开发人员没有任何价值，甚至新的学习成本远远大于原生方式，最后只能产生没有意义的新框架学习之旅！

这里有个例外就是此处封装是不得已为之，只有这种方式才能进行统一处理，不过想想目前使用的组件是真的没有更好的方法吗。

过度封装

还有一类封装就是过度封装，例如为了应对各类场景，将所有场景代码都进行了封装，产生互相不兼容，为了应对这种不兼容又产生新的代码来绕过不兼容，使原本封装的组件成为了“拦路虎”。

好的封装

好的封装应该具备简单几项

• 暴露原生方式
• 可插拔，可替换，不绑死在单一组件上
• 组件之间依赖低

在这些基础上，如果达到免初始化，只需安装相关jar包或者nuget包，而无需再进行初始化代码，对于实际业务使用又都是暴露原生方法，做到这些那更加nice，即把组件当作插件的方式进行封装开发。

最后

在当今微服务当道的今天，如果严格遵守微服务模式，以每个服务尽量简单高效的目标开发，asp.netcore或者spring boot即可开发出稳定高效可维护有保障的应用。不要掉入框架封装的怪圈。微服务的出现，service mesh的出现，甚至dapr的出现，让开发框架和全家桶都会不断扫进历史垃圾堆。

真正有意义的应该是低代码，一键脚手架，插件系统，是系统而不是框架，共勉。