走出架構誤區，架構師並非想象的那麼容易

幾年前還記得我發表的軟件設計的幾大誤區嗎?

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

　　以前提到的誤區到如今已經沒有什麼爭議了。

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

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

誤區一：

　　一套開發框架代替架構師

　　首先咱們來看下，架構師全稱爲「軟件系統架構設計師」。

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

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

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

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

　　這其中最重要的因素仍是在於人爲的設計，而不是架構，因此這種思想是錯誤的，並且錯得可怕。

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

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

　誤區二：

　　高併發、大數據是難點

　　主要是軟件行業裏僞程序員太多了，以致於這麼基礎的問題會成爲一個難點。

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

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

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

　　而後團隊開發模式很是落後，在這樣的軟件行業環境下，以致於程序有可能併發的狀況下，程序運行出詭異的結果。

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

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