軟件開發的哪個階段最容易招人噴？如果你嚴格按照什么瀑布模式、敏捷模式開發的話，你會發現永遠是概要設計的評審階段。

這個時候，雖然還沒有成為既定的事實。多位理想主義達人，就會搬出各種規則、規范，來給你的方案下套子。

他們是為了你的方案更好么？大多數情況未必。有的人，多說幾句是為了凸顯自己的價值；有的人是剛看了幾本書，感覺不吐不快;還有的人，本身就是完美主義者，看不得你的方案有任何瑕疵。總結下來，完美主義者還是有點作用的。

但當你把開發任務扔給這些指揮和挑刺的人，你會發現他們大多數不僅僅實現不了自己給套上的套子，連最基本的功能實現都是問題。

每當這時候，我內心都會大喊：讓這些假洋鬼子去死吧！

組件替換問題

如果我們的技術棧，選用的是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

一刀切，在公司技術部門懶政的環境中，普遍存在。

在制定規范和標準的時候，大家都習慣兼容并包，照顧所有的業務線，做上一份。但在實踐中，這種標準的問題通常問題多多，為業務方造成許多的困擾。

人要因材施教，規范也應該區分環境。制定規范的人活兒多一些，執行的人，生活就快樂一些!