過度設(shè)計(jì)是罪惡的！

原創(chuàng)：小姐姐味道（微信公眾號ID：xjjdog）

軟件開發(fā)的哪個(gè)階段最容易招人噴？如果你嚴(yán)格按照什么瀑布模式、敏捷模式開發(fā)的話，你會發(fā)現(xiàn)永遠(yuǎn)是概要設(shè)計(jì)的評審階段。

這個(gè)時(shí)候，屎山還沒有成為既定的事實(shí)。多位理想主義達(dá)人，就會搬出各種規(guī)則、規(guī)范，來給你的方案下套子。

他們是為了你的方案更好么？大多數(shù)情況未必。有的人，多說幾句是為了凸顯自己的價(jià)值；有的人是剛看了幾本書，感覺不吐不快；還有的人，本身就是完美主義者，看不得你的方案有任何瑕疵?？偨Y(jié)下來，完美主義者還是有點(diǎn)作用的。

但當(dāng)你把開發(fā)任務(wù)扔給這些指揮和挑刺的人，你會發(fā)現(xiàn)他們大多數(shù)不僅僅實(shí)現(xiàn)不了自己給套上的套子，連最基本的功能實(shí)現(xiàn)都是問題。

每當(dāng)這時(shí)候，我內(nèi)心都會大喊：讓這些假洋鬼子去死吧！

組件替換問題

如果我們的技術(shù)棧，選用的是MySQL，我們會采用JDBC、MyBatis、JPA等一系列的基礎(chǔ)的編碼工具。但這種選擇，對追求接口和實(shí)現(xiàn)分離的同學(xué)來說，卻是不可忍受的。

這些人會搬出無數(shù)的理由，來說明，如果不加入一個(gè)中間層的話，代碼是無法復(fù)用的。他們追求的是，如果你將來把數(shù)據(jù)庫從MySQL切換到ElasticSearch，那么你幾乎不需要改動任何代碼。

“你有沒有想過？如果你ES也不用了，把數(shù)據(jù)存儲在Hbase中呢？”

這也是操蛋的DDD所追求和說明的，把一個(gè)簡單的數(shù)據(jù)庫操作給拆的七零八落。

如果把這種設(shè)計(jì)哲學(xué)推廣開來的話，你會發(fā)現(xiàn)幾乎每個(gè)地方都有問題。

項(xiàng)目中使用了Kafka，如果將來換成Pulsar呢？項(xiàng)目中使用了Http，如果將來要換成Socket呢？最讓人擔(dān)心的是，項(xiàng)目中使用了Java語言，如果后面使用Golang呢？是不是也要發(fā)明一個(gè)第三方語言來規(guī)避語言的差異？

值得注意的是，Spring家族在這些完美的目標(biāo)上，產(chǎn)出了不少優(yōu)秀的組件，比如Spring Data、Spring Cloud Stream等。

但這不代表你可以過度設(shè)計(jì)。因?yàn)橛脕砥帘螌?shí)現(xiàn)的這部分實(shí)現(xiàn)，本身就是風(fēng)險(xiǎn)的存在。

耦合有錯么？

只要需求落在代碼上，就一定會產(chǎn)生耦合，想要去除所有的耦合，那是根本不可能的。

在開發(fā)中，你為什么不想著為開發(fā)語言的耦合創(chuàng)造一個(gè)第三方語言呢？這個(gè)成本是大的，而且是非常沒有必要的，如果真的有這種需求，你可以把它放在重構(gòu)上。

同樣的話，我也可以送給糾結(jié)底層數(shù)據(jù)庫存儲的同學(xué)。一旦你做了某個(gè)決定，想要完整的抽象就變的非常的奢侈，它不會比更換開發(fā)語言有更少的工作量。

這是一種思維慣式，也是一個(gè)度的問題。

在評審會議上噴一下非常的爽，但沒有人會多想一想背后的工期、需求和必要性。

但如果放任耦合無限制的產(chǎn)生，顯然也不是我們想要的，這個(gè)度的度量需要一定的學(xué)問。

內(nèi)部技術(shù)和外部協(xié)作

我覺得沖突產(chǎn)生的根本原因，是評審者甚至開發(fā)者，沒有弄清項(xiàng)目的邊界是什么。

拿SpringCloud來說，只要定義好Feign接口的協(xié)作方式和規(guī)范，把文檔寫好命名做好，另外一個(gè)團(tuán)隊(duì)并不是很關(guān)心你后面到底是Java寫的，還是掛了個(gè)sidecar的Golong程序。

再拿消息隊(duì)列來說，全公司定下了Kafa作為數(shù)據(jù)交換的通道，雖然它沒有JMS這樣的協(xié)議兼容，你也不會蛋疼的去封裝一層去兼容。大家默認(rèn)Kafka的Topic/Partition機(jī)制，并基于這樣的特性調(diào)整代碼。

至于我的后端數(shù)據(jù)庫，是用MyBatis去處理，還是用JPA去處理。是MVC三層模型，還是直接把SQL寫在Controller里。只要這些是我的私有數(shù)據(jù)，外部團(tuán)隊(duì)永遠(yuǎn)不會用到的話，任何人都沒必要對其指手畫腳。

只要邊界問題處理好，就不會產(chǎn)生大的亂子。

End

一刀切，在公司技術(shù)部門懶政的環(huán)境中，普遍存在。

在制定規(guī)范和標(biāo)準(zhǔn)的時(shí)候，大家都習(xí)慣兼容并包，照顧所有的業(yè)務(wù)線，做上一份。但在實(shí)踐中，這種標(biāo)準(zhǔn)的問題通常問題多多，為業(yè)務(wù)方造成許多的困擾。