过度设计是罪恶的！

这个时候，屎山还没有成为既定的事实。多位理想主义达人，就会搬出各种规则、规范，来给你的方案下套子。

他们是为了你的方案更好么？大多数情况未必。有的人，多说几句是为了凸显自己的价值；有的人是刚看了几本书，感觉不吐不快；还有的人，本身就是完美主义者，看不得你的方案有任何瑕疵。总结下来，完美主义者还是有点作用的。

但当你把开发任务扔给这些指挥和挑刺的人，你会发现他们大多数不仅仅实现不了自己给套上的套子，连最基本的功能实现都是问题。

每当这时候，我内心都会大喊：让这些假洋鬼子去死吧！

组件替换问题

如果我们的技术栈，选用的是MySQL，我们会采用JDBC、MyBatis、JPA等一系列的基础的编码工具。但这种选择，对追求接口和实现分离的同学来说，却是不可忍受的。

这些人会搬出无数的理由，来说明，如果不加入一个中间层的话，代码是无法复用的。他们追求的是，如果你将来把数据库从MySQL切换到ElasticSearch，那么你几乎不需要改动任何代码。

“你有没有想过？如果你ES也不用了，把数据存储在Hbase中呢？”

这也是操蛋的DDD所追求和说明的，把一个简单的数据库操作给拆的七零八落。

如果把这种设计哲学推广开来的话，你会发现几乎每个地方都有问题。

项目中使用了Kafka，如果将来换成Pulsar呢？项目中使用了Http，如果将来要换成Socket呢？最让人担心的是，项目中使用了Java语言，如果后面使用Golang呢？是不是也要发明一个第三方语言来规避语言的差异？

值得注意的是，Spring家族在这些完美的目标上，产出了不少优秀的组件，比如Spring Data、Spring Cloud Stream等。

但这不代表你可以过度设计。因为用来屏蔽实现的这部分实现，本身就是风险的存在。

耦合有错么？

只要需求落在代码上，就一定会产生耦合，想要去除所有的耦合，那是根本不可能的。

在开发中，你为什么不想着为开发语言的耦合创造一个第三方语言呢？这个成本是大的，而且是非常没有必要的，如果真的有这种需求，你可以把它放在重构上。

同样的话，我也可以送给纠结底层数据库存储的同学。一旦你做了某个决定，想要完整的抽象就变的非常的奢侈，它不会比更换开发语言有更少的工作量。

这是一种思维惯式，也是一个度的问题。

在评审会议上喷一下非常的爽，但没有人会多想一想背后的工期、需求和必要性。

但如果放任耦合无限制的产生，显然也不是我们想要的，这个度的度量需要一定的学问。

内部技术和外部协作

我觉得冲突产生的根本原因，是评审者甚至开发者，没有弄清项目的边界是什么。

拿SpringCloud来说，只要定义好Feign接口的协作方式和规范，把文档写好命名做好，另外一个团队并不是很关心你后面到底是Java写的，还是挂了个sidecar的Golong程序。

再拿消息队列来说，全公司定下了Kafa作为数据交换的通道，虽然它没有JMS这样的协议兼容，你也不会蛋疼的去封装一层去兼容。大家默认Kafka的Topic/Partition机制，并基于这样的特性调整代码。

至于我的后端数据库，是用MyBatis去处理，还是用JPA去处理。是MVC三层模型，还是直接把SQL写在Controller里。只要这些是我的私有数据，外部团队永远不会用到的话，任何人都没必要对其指手画脚。

只要边界问题处理好，就不会产生大的乱子。

End

一刀切，在公司技术部门懒政的环境中，普遍存在。

在制定规范和标准的时候，大家都习惯兼容并包，照顾所有的业务线，做上一份。但在实践中，这种标准的问题通常问题多多，为业务方造成许多的困扰。

人要因材施教，规范也应该区分环境。制定规范的人活儿多一些，执行的人，生活就快乐一些！