走出架構誤區，架構師並不是想像的那麼容易

【IT168 評論】幾年前還記得我發表的軟體設計的幾大誤區嗎?

隨著時代的發展，orm被更多人接受，九十年代出來的設計模式也被動地融入到主流框架，以至於設計模式到現在發展成了架構模式和業務模式，而存儲過程也被開發者更少地使用。

之前提到的誤區到現在已經沒有什麼爭議了。

但隨著年代的變遷，從前的小程序員也成了有多年工作經驗的大咖了，更多人的頭銜從程序員貼上了架構師標籤。

而在互聯網如此火的今天，在這樣一個年代裡，我又要出來指出幾個誤區。

誤區一：

一套開發框架代替架構師

首先我們來看下，架構師全稱為「軟體系統架構設計師」。

名字很長，但拆分開來是xxxxxx設計師，前面加上「架構」這一詞突出了是一個從更高層次的考慮問題的設計師，最終還是個「設計師」。

更高層次是相對而言，相對ui設計、局部的功能設計，更高層次是總體的設計，並不是說架構設計要比ui設計厲害或重要。

「軟體系統」則限定了在軟體系統範圍內的設計師，而不是弱電、土木工程等設計師。

一套開發框架只是代碼架構，沒錯是架構，但實際開發中會對代碼架構剪裁，這取決於需求的理解和系統的設計，類似嵌入式工程師對架構剪裁。

這其中最重要的因素還是在於人為的設計，而不是架構，所以這種思想是錯誤的，而且錯得可怕。

從ejb、ssh、ssm，框架從來都沒有解決過問題。

離開了優秀的設計師，項目不提早完蛋，成本也會很高。

誤區二：

高並發、大數據是難點

主要是軟體行業里偽程序員太多了，以至於這麼基礎的問題會成為一個難點。

其實問題很簡單，屬於大學教科書里的課後練習題。

大量培訓學校，網路培訓課程，以及混日子的大學生，和一波非專業對口人士轉程序員，可能沒有接觸過。

然而隨著時代發展，這一波偽程序員已經有了相當長的工作經驗，在長達5年以上的業餘時間裡，並未系統地學習過，精力只夠了解新框架，新技術，但為生活所迫留在這行業成為資深，甚至成為帶團隊的負責人。

然後團隊開發模式非常落後，在這樣的軟體行業環境下，以至於程序有可能並發的情況下，程序運行出詭異的結果。

等到出現詭異的結果時，往往應用程序已經離當初開發完成到交付有了個把月的時間。

跑了一段時間後，互聯網應用則會出現用戶數量急劇上升所帶來的問題，企業(zf)應用則需要導入歷史數據或隨著年代增長核心程序的業務數據堆積如山，導致海量數據性能問題需要解決。

因為這些非功能性需求導致的問題，會在開發交付半年後才慢慢體現，這些公司事前最多也只是在文檔中或討論中提到這些非功能性需求，但沒有有效的測試辦法去保證萬無一失。

這也是我之前的一個誤區，總以為我設計的軟體是比別人高質量的，如何證明?請等半年或幾年後看看我還維護得了，別人就得加班或跑路。

為什麼不能通過測試，提前暴露這些問題，在交付部署以前?而不是憑藉個人經驗或個人能力。

交付部署以前，開發未完成時，除了對非功能性需求的考慮以外，還需要可量化的測試，用模擬的測試(mock)對服務對接點進行壓力測試。

誤區三：

流行微服務架構

如果說上幾年是xxx+xxx+xxx的開發框架比較火，

那麼這幾年是微服務比較火，這也和並發要求高的大環境下有關，微服務通常提供了分散式服務的解決方案。

其實這貨就是以前得soa基於服務的架構分散式升級版，並非是必選項，然後水平不夠該躺的地方還是得躺。

通常誤引入微服務的原因只是為了解決誤區二里的高並發，高可用。

但是又跌進了另一個更大的坑：

1、比以前更吃資源，花費更多購買伺服器的費用;

2、分散式事務一致性難以保證，由網路導致的調用失敗更多;

3、設計師經驗不足強行拆分帶來的更多服務的交叉引用;

4、發布和部署到生產環境和運維工作量更多，帶來更大成本;

如果誤區二里分散式的問題不能在以前就解決，傻傻地引入微服務架構，最終結果還是一樣的，還會付出更多代價。

要說微服務這東西還真不是什麼突然冒出來的概念，多年以前我就開發了一個webservice作為類似註冊中心的匯流排，所有獨立的dll丟到目錄下就當是註冊了，然後通過網關或是反向代理工具去訪問多個點部署的它，實現負載均衡。

只是它並不是真正的微服務，當然也不像微服務那樣吃系統資源，但它卻解決了高並發、高可用的問題。

可將它看作微服務的過渡版，正因為接觸這種類型的soa，才知道分散式服務設計的難點所在，絕不是單單引入微服務就萬事大吉了。

關鍵點還是在於人，在於設計師，在於團隊開發模式。

沒有實現不了功能的程序員，只有設計不出可靠軟體的程序員。

沒有帶不了團隊的程序員，因為每個程序員都能實現功能，並且總有更弱得新手可以帶，難的是帶出一個好的設計師，難的是帶出一個能帶人的設計師，從而帶起整個公司甚至是行業。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！