戰略、架構、設計、編碼
不得不說，這是乙個很大的話題，即使是任何其中乙個放出來講，都是tb級的儲量量。我在這裡講的，是以我多年經驗來做的一些零碎的總結，試圖從乙個開發者的角度去理解這四者之間的關係。本文沒有任何讚揚某一點的意思，也不存在貶低某一職位的想法，如果讀者能從中讀出些少不爽，也只是現實中存在的問題，跟我的思維沒有任何關係。
首先我不得不說，儘管已經在it界摸爬滾打七八年，也努力過也奮鬥過，但到現在為止至少我認為還是個徹頭徹腦的失敗者。不為別的，只因為到目前為止我還是一名開發者，是處於編碼的位置。很多人把軟體工程用建高樓來作比喻，我也不例外，因為現在也只有樓價才能讓人興奮覺得有意義了。軟體設計就是要建一幢樓，根據樓的定位用途，是作商用還是民居還是商住兩用，架構師架構了這樣乙個模型，先把樓的形狀、大小、面積、高度、基礎設施、每一層的用途確定下來，設計師拿到這樣乙個模型，開始進行樓層的裝修設計，而編碼者，在這些設計的基礎上蓋樓，進行地板、牆面的裝修。
架構就是要定義這樣的乙個軟體模型，定義這個軟體分幾層，每一層用什麼技術實現，可以怎樣擴充套件部署，怎樣為業務的實現提供基礎設施服務，這種服務包括程式設計元素（元資料）如何定義，事務管理，業務物件管理，還可能包括磁碟檔案讀寫、異常捕捉、日誌記錄、安全性管理、配置管理、快取管理、執行緒服務、伺服器和客戶端通訊管理、國際化服務，如何提供框架來限制開發人員的行為，讓他們按統一規範、統一方向進行編碼實現。架構師要架構好整幢大廈，如果架構出了問題，那就是裡面的單元設計得再好，裝修得再豪華，就算裡裡外外都用金子貼成的，只要它的指標達不到要求，那整幢大廈就不能用了。軟體也是這樣，如果基本指標達不到要求，比如系統效能、容量、安全、擴充套件、穩定、維護方面達不到要求，那是完全不能用的。好的架構還有乙個特點，那就是不能讓開發者隨心所欲，為所欲為，例如不能在jsp中直接呼叫dao進行資料操縱，也不能在dao層寫業務邏輯**。這些都體現在細節方面，對乙個企業級的軟體來講尤為重要。比如我寫乙個基於hibernate的dao層框架，我就沒有提供直接的jdbc呼叫，有不少開發人員因為比較熟悉sql語句吧，遇到困難就說要開放jdbc呼叫，其實sql語句能做的，hql也99%能實現，實現不了的，說明我們的思維太超前，超前到出問題了。很多時候並不是說hql語句做不到，而是由於我們的惰性影響了我們的行為，不想花時間跟精力去找相關的解決方法。如果放開jdbc呼叫，必然會影響快取跟後面的資料庫無關性設計，軟體架構就起不到限制的作用了。有點軟體可以發現ui層直接寫sql的現象，也發現了sql寫在邏輯層裡的東西，更扯的是 dao層裡面出現ui的東西，比如拼前端標籤，這些都是沒有架構好的直接體現。
以下抄錄了架構師的分類，出處太多原著不得而知，請原著原諒。
架構師細分為以下幾種：平台架構師：這裡的平台其實包括兩個平台，乙個是系統平台，也就是負責搭建多個系統整合的系統應用平台；另外乙個其實是基礎平台，是專門負責搭建基礎技術平台；兩者其實區別蠻大，也經常容易被從業人員混亂。舉個簡單例子，金蝶有平台架構師一職，但是金蝶boss應用和金蝶中介軟體兩者招聘的物件和技術要求是截然不同的。應用架構師：其實應用架構也就是我們絕大多數人理解系統架構師，它主要是負責系統的開發框架及基本結構層次的建設。但是，對於這樣乙個職責，千萬不要以為就是struts + spring + hibernate這樣的組合，如果是那樣，這架構師也未免太容易當了吧。乙個好的系統架構是必須充分理解和融合相關業務應用的行業以及運營背景的。這個話題我們可以另外細談。業務架構師：業務架構其實已經開始脫離技術層面了，但是它要求架構師有跨越多系統的大局觀，去整合和組織不同系統的技術平台與互動模式。其實這個職位的未來也就是cio了。網路架構師好的設計要在乙個好的架構上進行，如果軟體架構本身都有問題，你就是設計得再好也是白搭。就像一幢大廈，裡面就算裝修得再漂亮再好，只要大廈存在倒塌的危險，那就不能使用了。設計就是在架構的基礎上針對某一業務功能進行細分，進行相關實體的建模，相關業務流程的梳理，相關資料庫模型的整理。比如一幢大廈，**要做超市，就要設計成超市的樣子；**要做成購物商場，那就設計成商場；**要做辦公樓，就要設計成辦公樓的樣子；**要做成民用住房。。。。。。對於高效的軟體工程，良好的設計是關鍵，乙個設計得好的軟體系統應該是可直接實現和易於維護、易懂和可靠的。設計得不好的系統，儘管可以工作，但很可能維護起來費用昂貴、測試困難和不可靠。
編碼是處於最低層的工作，但是也經常容易被自己高估。當然，任何軟體系統都是由一行一行的**構建而成的，乙個合格的程式設計師就是要寫出高效簡潔的**來實現某一項功能。編碼是設計和架構的基礎，想要成為乙個好的設計師或架構師，首先要成為一名優秀的程式設計師。開發人員有個很大的通病就是追求完美，追求極致，而在追求的過程中往往耗費掉自己大量的時間和精力而無暇去顧及其它。其實，開發系統要適可而止、見好就收，程式沒有最好只有更好，不可能搞到完美為止，特別是對於業務方面的程式設計開發就更是如此，對於系統、核心級別的**又另當別論。程式設計師需要擠出點時間來學習，學習設計、架構，學習新技術新知識新領域，並嘗試與不同的人進行交流溝通，擴充套件自己的關係圈。
小公尺創始人雷軍說過，「離開金山對我是一次重創，心理上的創傷超過了大家的想象。我這個人很努力，很勤奮，帶著一幫和我一樣的人，打了這麼多年江山，整成這個樣子，我肯定不服氣。要是我沒努力也認了，但是我非常努力。二十多年，這麼多的機會，乙個都沒撈著，我問自己為什麼，問題肯定出在我身上了，那我的問題是什麼呢？就是不服輸。」逆勢而為，雖百倍努力後會略有成功，但也只是小成；順勢而為，看起來不夠有情懷，但這是成功的真諦。這裡的勢，其實指的就是戰略。戰略是個很玄的東西，是非常高層次的產物。像地產界的老大，他不需要知道怎麼砌磚，怎麼設計高樓，怎麼一層一層地往上蓋；他只需要拿個地圖畫個圈，或者站在高處指著一塊土地，他選擇的地方，就是以後bcd商業中心。位置選擇不好，哪怕你請多好的設計師，建築得再巨集偉，也成就不了商業中心。戰略決定了一切，搞軟體亦是如此。如果戰略不對，就算你開發出再美輪美奐的軟體，也沒有人會去使用。程式設計師的人生戰略很重要，比如你是進入傳統行業做erp，還是進入網際網路做電子商務，當然，行行出狀元，只是成功率和付出的汗水，肯定不一樣的。很多時候，到了一定的年紀就會發覺，選擇，確實比努力更重要。，就因為他曾經追求過成功。
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...
mysql架構設計 初識mysql架構設計
一 應用系統如何與mysql進行一次互動？最開始接觸jdbc的時候，我們系統如何完成一次sql操作呢？第一步，建立資料庫連線 第二步，操作sql 第三步，釋放連線。但是每次建立與資料庫的連線非常耗時和資源，所以我們加入了連線池的概念。第一步的獲取連線是從連線池中獲取乙個可用的連線，第三步的釋放連線不...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...