走出架構誤區，架構師並不是想象的那麼容易
幾年前還記得我發表的軟體設計的幾大誤區嗎?
隨著時代的發展，orm被更多人接受，九十年代出來的設計模式也被動地融入到主流框架，以至於設計模式到現在發展成了架構模式和業務模式，而儲存過程也被開發者更少地使用。
之前提到的誤區到現在已經沒有什麼爭議了。
但隨著年代的變遷，從前的小程式設計師也成了有多年工作經驗的大咖了，更多人的頭銜從程式設計師貼上了架構師標籤。
而在網際網路如此火的今天，在這樣一個年代裡，我又要出來指出幾個誤區。
誤區一：
一套開發框架代替架構師
首先我們來看下，架構師全稱為“軟體系統架構設計師”。
名字很長，但拆分開來是xxxxxx設計師，前面加上“架構”這一詞突出了是一個從更高層次的考慮問題的設計師，最終還是個“設計師”。
更高層次是相對而言，相對ui設計、區域性的功能設計，更高層次是總體的設計，並不是說架構設計要比ui設計厲害或重要。
“軟體系統”則限定了在軟體系統範圍內的設計師，而不是弱電、土木工程等設計師。
一套開發框架只是程式碼架構，沒錯是架構，但實際開發中會對程式碼架構剪裁，這取決於需求的理解和系統的設計，類似嵌入式工程師對架構剪裁。
這其中最重要的因素還是在於人為的設計，而不是架構，所以這種思想是錯誤的，而且錯得可怕。
從ejb、ssh、ssm，框架從來都沒有解決過問題。
離開了優秀的設計師，專案不提早完蛋，成本也會很高。
誤區二：
高併發、大資料是難點
主要是軟體行業裡偽程式設計師太多了，以至於這麼基礎的問題會成為一個難點。
其實問題很簡單，屬於大學教科書裡的課後練習題。
大量培訓學校，網路培訓課程，以及混日子的大學生，和一波非專業對口人士轉程式設計師，可能沒有接觸過。
然而隨著時代發展，這一波偽程式設計師已經有了相當長的工作經驗，在長達5年以上的業餘時間裡，並未系統地學習過，精力只夠瞭解新框架，新技術，但為生活所迫留在這行業成為資深，甚至成為帶團隊的負責人。
然後團隊開發模式非常落後，在這樣的軟體行業環境下，以至於程式有可能併發的情況下，程式執行出詭異的結果。