过度设计是罪恶的!

语言: CN / TW / HK

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留此信息。

软件开发的哪个阶段最容易招人喷?如果你严格按照什么瀑布模式、敏捷模式开发的话,你会发现永远是概要设计的评审阶段。

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

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

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

每当这时候,我内心都会大喊:让这些假洋鬼子去死吧!

组件替换问题

如果我们的技术栈,选用的是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

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

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

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

作者简介: 小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

推荐阅读: