程序員與架構師的區別

好的程序員作不出好的軟件設計

本文由「外刊IT評論」網(http://www.aqee.net/)榮譽出品

你不能看到一個程序員還不錯，就把他推到系統分析師、軟件設計師或軟件架構師的位置上。

若是你在團隊或公司裏尋找一個能勝任軟件架構師或設計師這樣重要位置的人時，首先出如今腦子裏的想法一般是在程序員中選一個最好的。別這麼幹。這樣的位置不是隨意的找個不錯的程序員就能勝任的。把你最資深的程序員晉升到這個位置也未必就合適。

乍一聽你可能感受荒誕。爲何我不能讓一個程序員去作系統設計呢？畢竟，他們是設計程序的，不是嗎？的確是的，沒錯。但你要明白的事情是，設計軟件相對於編寫程序，它須要的是一套徹底不一樣的技能。

讓咱們來看看爲何一個好的程序員就未必能夠作一個好的軟件設計師。但首先，讓咱們來問問本身一個問題，是什麼讓一個程序員變的優秀，甚至傑出？要想成爲一個好的程序員，你須要有能力實現真實世界裏重要的軟件。只可以寫出一個簡單的文本編輯器是遠遠不夠的。

爲了能作到能夠解決重大的、複雜的編程問題，一個程序員須要在某個特色的編程語言上進行數年的經驗積累。也就是說，爲了能熟練的使用這種語言、熟悉這種語言的各類特點，他必須專一於這種語言。問題就在這兒。

對於只有錘子的人，他能解決的問題就是釘釘子

若是你專一於一種語言，並能作到精通掌握，那你遇到的問題模式極可能就限制於跟這種語言相關的領域。簡言之，若是你懂PHP，那全部的問題都基本上是跟 Web開發相關。相同的道理，若是你所有的知識都集中的Java上，那你對全部問題的解決思路都會沿着面向對象的方向，即便是使用過程式編程對於解決你的問題會更優的狀況下，你也會如此。

一個程序員，只懂得1、兩種編程語言，這會嚴重的限制他的解決問題的能力。例如，若是你的編程語言是C語言，對於手頭出現的問題，你絕對不可能想出一種面向對象的解決思路，由於你的編程語言不提供這樣的語言特徵。跟Haskell程序員不同，C++程序員不可能想出函數式解決方案。你的編程語言裏提供告終構體和枚舉類型與否，會嚴重的影響你剖析一個問題的方式。若是你使用的語言的能力很弱，或你只知道少數幾種語言，你解決問題的能力相應的會被削弱。

語言塑造了咱們的思惟方式

有人說，咱們的語言塑造了咱們的思考和認知這個世界的方式。我基本上認同這個觀點。當一我的的母語裏的名詞都有性別之分時，他必定不會同說其它種母語的人那樣一提起「警察」這個詞就基本上認爲是男的。當一我的的母語裏對藍色和綠色不區分時，他對世界的感知會和那些有區分的人的感知大不同。

若是咱們回首中世紀學校的三學科，它們被描述爲：語法解決概念和對象如何在書寫和話語中被表現，用邏輯對它們進行分析，最終以修辭爲目的同他人交流。對於咱們來講，編程語言也有語法。若是咱們的編程語言不夠強，咱們對事物和概念的認識以及對如何表達它們都不會有完整的視野。

語言，咱們用來跟人們、跟計算機交流的功能，明顯的影響着咱們的思考方式。咱們對語言知道的越豐富、越多，越能幫助咱們提升解決問題的能力。

那麼，什麼樣的人更合適？

那麼，一個在某一兩種編程語言裏具備專長的程序員，在當他解決一個問題時，會存在必定的侷限。他會侷限於他使用的語言容許他作的事。所以，他不會成爲一個好的軟件設計師或分析師。

若是咱們不用這些優秀的程序員，誰又能擔當軟件設計的任務呢？固然不會是那些徹底不懂編程的人了。咱們須要的是一種通才。一個優秀的軟件設計者必須通曉過程式，面向對象式，函數式，以及邏輯式編程語言—還包括各類優秀的軟件開發方法論。他不能只熟悉一種方法模式、像一個專業領域人員那樣。固然，他本身並不能寫出複雜的程序，由於他的知識太寬泛。儘管如此，他卻能正確的判斷出怎麼樣的設計纔是一個正確的解決方案。若是問題是處理一個釘子，他會找來一個熟練使用錘子的人；若是問題是處理一個巨石，他會叫來爆破部隊，而不是讓你徒勞的用錘子白費力氣。

 

 

聯想到一本書裏面提到(子柳寫的《淘寶技術這10年》)，我把大體意思概括以下：

 

在系統的發展過程當中，架構師的眼光很是重要，做爲程序員，只要把功能實現便可，但做爲架構師，要考慮系統的擴展性，重用性，對於這種敏銳的感受，有人說是一種"代碼潔癖"。淘寶早期幾個架構師具有了這種感受。雖然個別架構師具有了"代碼潔癖"，但淘寶前臺系統的業務量和代碼量仍是呈現爆炸式的增加，業務方老是在後面催，開發人員不夠就繼續招人，招來的人根本看不懂原來的業務，只有摸索着在"合適的地方"加一些"合適的代碼"，看看運行起來像那麼回過後，就發佈上線。這樣惡性的循環中，系統愈來愈臃腫，業務的耦合性愈來愈高。開發的效率愈來愈低。借用當時流行的一句話"你寫一段代碼，編譯一下能經過，半個小時就過去了;編譯一下沒經過，半天就過去了。「在這種狀況下，系統出錯的機率也逐步增加，經常你是修改了商品相關的某些代碼，發現交易出現問題了，甚至你改了論壇的某些代碼，旺旺又出問題了。這讓開發人員苦不堪言，而業務方還認爲這些開發人員辦事不力。因爲當時從硅谷空降了一位技術高管，他告訴咱們一切要以系統穩定運行爲中心，全部影響系統穩定的因素要解決掉。每作一個平常修改，必須對整個系統作迴歸測試一遍。多個平常修改若是放在一個版本中，只要一個功能沒有測試經過，整個系統都不能發佈。咱們把這叫作火車模型：任何一個乘客沒有上車都不能發車。這樣作的後果是，新功能上線速度慢了，因此當時明顯感受到業務方的不滿。壓力很大。因爲把天天晚上都須要作一次整個系統的迴歸測試，在這種要求下，整個系統很龐大，咱們不得不對這個超級複雜的系統開始肢解和重構。好比把用戶信息模塊拆分出來，叫作uic,它只處理最基礎的用戶信息操做：getUserById，getUserByName等。系統進行拆解後，相互之間互補影響，不會由於一個用戶中心程序出錯，交易沒法使用。新作的淘寶旅行，淘寶彩票，只是在交易流程數據需求上不一樣。可是用戶信息是跟淘寶主站相似的，若是當時可以作系統拆解，就不用從新作一遍,調用uic中的信息便可(如今的淘寶旅行，淘寶機票是分開展現的就是這個緣由，當時爲了避免給淘寶主站添亂，單獨從新寫了兩套系統用於旅行和機票)