作架構也得講武德

這裏是Z哥的我的公衆號程序員

每週五11：45 按時送達編程

固然了，也會時不時加個餐～架構

個人第「169」篇原創敬上分佈式

你們好，我是Z哥。今天分享一篇對「架構」這件事的隨想。單元測試

我想，作「架構」是每一個熱愛技術的技術人在不斷追求想進入的領域。可是不少人可能工做了不少年也沒能真正參與到作架構這件事上。測試

因此，不少人對作架構這件事的感知停留在網上不少大牛分享的文章裏。大數據

可是，若是你只是看網上的文章其實對架構的理解會很是容易跑偏的，主要緣由有兩點。設計

第一點，世界是在不斷髮展和迭代的。技術也是人類文明的一部分，因此天然也會隨着時間的推移不斷進化。資源

而不少講架構的文章喜歡和新技術掛上鉤，一個沒用到新技術的「架構」，會讓不少人以爲有點out，缺少吸引力。開發

可是新技術的推出，要麼是用來解決過去沒法解決的問題，要麼是能夠提升當前解決問題的效率。正如當前的你在20年前作程序員，基於當時的編程環境，開發效率確定不如如今，這是毋庸置疑的。

也正由於如此，每一項新技術的出現，背後必然對應着一個典型的問題場景。能最大化發揮這項新技術價值的地方也應該是這個場景。

若是咱們僅僅停留在這項新技術自己去考慮它有什麼用，那麼就很容易就會陷入到「拿着錘子找釘子」的狀況裏。特別是出於對「架構」的崇拜，「我怎麼才能用上這個技術」會成爲腦海中第一重要的目標。

第二點，不論是創造新技術的人仍是分享新技術使用經驗的人，對他們來講確定得對外展現新技術好的一面。若是寫很差的一面，這不是拆本身臺麼，或者擔憂表現出本身不會用、丟臉麼。

若是你有心的話，當你在網上搜某個技術的相關資料的時候其實很容易觀察到這個現象，講優勢的文章比講缺點、講遇到什麼坑的文章多得多。

這會形成的影響就是過分拉高「旁觀者」對新技術的預期，認爲它是很牛逼的，能解決不少問題。

那麼正確對待「架構」的態度應該是什麼呢？

我根據我本身作架構5年踩坑的經驗總結了如下3點。但願能幫助你少踩甚至是避開我踩過的坑。

/01 回到現實的問題中/

任何技術應該都只是解決問題的可選項之一，並無所謂的惟一選擇。只有你回到的現實中，從實際的問題出發去考慮，你才能規避掉你對某項技術所帶的偏見。（固然，提早是你還得對每項技術有基本的瞭解）

好比，以前我團隊裏有個小夥伴以爲Saga模式很是酷，他認爲用它來實現數據的寫操做又快又準，還能大大下降資源競爭問題，是全部項目應該考慮的第一選擇。因而，他在一個新項目中用上了。

可是，最終系統上線後，頁面操做的響應的確挺快，可是因爲數據的滯後產生了一系列問題，讓系統使用者苦不堪言。

/02 大多數時候，「減」都比「加」好/

我問你兩個詞語，你知道「簡單」和「容易」的區別嗎？

在我看來它們有很大的區別，個人理解是，「簡單」是形容事物的，「容易」是描述作一件事的過程。因此，咱們作架構這件事，要追求的是「簡單」而不是「容易」。雖然不少時候「容易」會讓你用的時候以爲很「簡單」，但那不是真的簡單，最多算得上是局部的「簡單」。（這段話有點繞，細品一下應該仍是很容易理解的）

因此，想要架構變得「簡單」，天然是作減法比作加法好。可是現實中，每每相反，更多人樂忠於增長什麼新技術，引入什麼新技術。畢竟作加法有可能不用考慮「歷史問題」，而要作減法不得不考慮「歷史問題」，很明顯前者更「容易」。

/03 時刻保持風險意識/

大多數狀況下，後續暴露出風險的地方大多數是一些非功能性的點。好比，數據常常出錯，訪問量一大數據同步就延遲的厲害，甚至宕機。

這些點提及來簡單，可是須要考慮的細節很是多。相似於「木桶原理」，只要你的總體架構中有一塊短板拖了後腿，大大小小的問題就會接踵而來。

更加麻煩的是，這些問題還不容易解決，甚至須要作大量的推倒從新設計才能解決。

雖說，無論怎麼樣依舊沒法100%規避風險，可是時刻帶着風險意識問本身：「這裏這樣設計可能會有什麼問題？」必然會大大下降風險係數。

另外，對待已經察覺到的潛在風險絕對不能草率，認爲將來不必定會發生，先將就着。規模越大的系統，越符合墨菲定律所提到規律——「凡是可能出錯的事有很大概率會出錯」，並且時間會大大提早。

暫時就想到這麼多，這個話題其實很大，後續有新的思考再分享給你們一塊兒討論。

好了，總結一下。

這篇呢，Z哥和你分享了我對架構這件事的隨想。

首先，對待一個陌生的技術，預期不能過於樂觀。由於如下兩點會潛移默化地讓你產生偏見。

對待架構這件事我給出的3個建議是：

但願對你有所啓發。

架構是「平衡」的藝術，祝你早日找到你的「平衡感」。