软件开发的哪个阶段最容易吸引人？如果你严格按照瀑布模式或者敏捷模式开发，你会发现永远都是大纲设计的review阶段。此时，虽然还没有成为既定的事实。许多理想主义的人会想出各种规则和规范来覆盖你的计划。它们更适合您的解决方案吗？在大多数情况下不一定。有的人多说几句，凸显自己的价值；有的人只看了几本书，就觉得不自在；有些人本身就是完美主义者，看不出你的计划有任何瑕疵。总之，完美主义者仍然可以发挥作用。但是当你把开发的任务丢给这些指挥批评的人时，你会发现，他们中的大部分人不仅不能实现自己套上的罩子，连最基本的功能实现都成问题。每当遇到这种情况，我都会在心里呐喊：让这些假洋鬼子去死吧！组件替换问题如果我们的技术栈使用了MySQL，那么我们会使用到JDBC、MyBatis、JPA等一系列基础编码工具。但是这种选择对于追求界面和分离的同学来说是难以忍受的。这些人会想出无数的理由来解释，如果不加中间层，代码就不能复用。他们追求的是，??如果你以后把数据库从MySQL切换到ElasticSearch，那么你几乎不需要更改任何代码。“有没有想过，如果不需要ES，数据存储在Hbase中如何？”这就是操蛋的DDD追求和解释的东西，把一个简单的数据库操作拆成碎片。如果你概括这种设计理念，你会发现几乎处处存在问题。项目中使用的是Kafka，如果以后换成Pulsar呢？项目中使用了http，如果以后需要换成Socket怎么办？最担心的是项目中用的是Java语言，万一后面用到Golang怎么办？是否有必要发明一种第三方语言来避免语言差异？值得注意的是，Spring家族基于这些完美的目标产生了很多优秀的组件，比如SpringData、SpringCloudStream等。但这并不意味着你可以过度工程化。因为这部分实现用来屏蔽实现本身就是一种风险。耦合错误？只要需求落在代码上，就会有耦合，不可能把耦合全部去掉。在开发中，为什么不考虑创建一个第三方语言来耦合开发语言呢？这个成本很大，而且非常没有必要。如果有这样的需求，你可以把它放在重构上。同理，我也可以送给在数据库存储底层苦苦挣扎的同学。一旦你做出了决定，想要完全抽象就成了一种奢侈，这不亚于切换语言。这是一种思维习惯，也是一个程度的问题。在评审会上喷一喷很酷，但没人会去想背后的日程、要求和必要性。但是如果让耦合无限制地产生，显然不是我们想要的。这个度数的测量需要一定的知识。在内部技术和外部协作方面，我认为冲突的根本原因是审稿人甚至开发人员没有了解项目的边界。以SpringCloud为例，只要你定义好Feign接口的协作方式和规范，写好文档，起个好名字，其他团队才不管你是用Java写的，还是挂个sidecarGolong程序。以消息队列为例，整个公司都确定了Kafa作为数据交换的通道。虽然它不兼容JMS等协议，但你不会痛苦地封装一层使其兼容。大家默认Kafka的Topic/Partition机制，根据这样的特点调整代码。至于我的后端数据库，应该用MyBatis还是JPA来处理。是MVC的三层模型，还是直接在Controller中写SQL。只要是我的私人数据永远不会被外部团队使用，就不需要任何人告诉我如何处理它。只要妥善处理边界问题，就不会出现大的风波。End是一刀切，在公司技术部门偷懒的环境中很常见。在制定规范和标准时，大家习惯于包容，兼顾各行各业，各尽所能。但在实践中，这个标准通常会出现很多问题，给业务方造成很大的困扰。人要因材施教，规范也要区别环境。制定规范的人工作更多，执行规范的人生活更幸福！
