好的程式設計師做不出好的軟體設計
本文由“外刊IT評論”網(http://www.aqee.net/)榮譽出品
你不能看到一個程式設計師還不錯，就把他推到系統分析師、軟體設計師或軟體架構師的位置上。
如果你在團隊或公司裡尋找一個能勝任軟體架構師或設計師這樣重要位置的人時，首先出現在腦子裡的想法通常是在程式設計師中選一個最好的。別這麼幹。這樣的位置不是隨意的找個不錯的程式設計師就能勝任的。把你最資深的程式設計師晉升到這個位置也未必就合適。
乍一聽你可能感覺荒誕。為什麼我不能讓一個程式設計師去做系統設計呢？畢竟，他們是設計程式的，不是嗎？的確是的，沒錯。但你要明白的事情是，設計軟體相對於編寫程式，它需要的是一套完全不同的技能。
讓我們來看看為什麼一個好的程式設計師就未必可以做一個好的軟體設計師。但首先，讓我們來問問自己一個問題，是什麼讓一個程式設計師變的優秀，甚至傑出？要想成為一個好的程式設計師，你需要有能力實現真實世界裡重要的軟體。只能夠寫出一個簡單的文字編輯器是遠遠不夠的。
為了能做到可以解決重大的、複雜的程式設計問題，一個程式設計師需要在某個特點的程式語言上進行數年的經驗積累。也就是說，為了能熟練的使用這種語言、熟悉這種語言的各種特色，他必須專注於這種語言。問題就在這兒。
對於只有錘子的人，他能解決的問題就是釘釘子
如果你專注於一種語言，並能做到精通掌握，那你遇到的問題模式很可能就限制於跟這種語言相關的領域。簡言之，如果你懂PHP，那所有的問題都基本上是跟 Web開發相關。相同的道理，如果你全部的知識都集中的Java上，那你對所有問題的解決思路都會沿著物件導向的方向，即使是使用程式式程式設計對於解決你的問題會更優的情況下，你也會如此。
一個程式設計師，只懂得一、兩種程式語言，這會嚴重的限制他的解決問題的能力。例如，如果你的程式語言是C語言，對於手頭出現的問題，你絕對不可能想出一種物件導向的解決思路，因為你的程式語言不提供這樣的語言特徵。跟Haskell程式設計師不一樣，C++程式設計師不可能想出函式式解決方案。你的程式語言裡提供了結構體和列舉型別與否，會嚴重的影響你剖析一個問題的方式。如果你使用的語言的能力很弱，或你只知道少數幾種語言，你解決問題的能力相應的會被削弱。
語言塑造了我們的思維方式
有人說，我們的語言塑造了我們的思考和認知這個世界的方式。我基本上認同這個觀點。當一個人的母語裡的名詞都有性別之分時，他一定不會同說其它種母語的人那樣一提起“警察”這個詞就基本上認為是男的。當一個人的母語裡對藍色和綠色不區分時，他對世界的感知會和那些有區分的人的感知大不一樣。
如果我們回首中世紀學校的三學科，它們被描述為：語法解決概念和物件如何在書寫和話語中被表現，用邏輯對它們進行分析，最終以修辭為目的同他人交流。對於我們來說，程式語言也有語法。如果我們的程式語言不夠強，我們對事物和概念的認識以及對如何表達它們都不會有完整的視野。
語言，我們用來跟人們、跟計算機交流的功能，明顯的影響著我們的思考方式。我們對語言知道的越豐富、越多，越能幫助我們提高解決問題的能力。
那麼，什麼樣的人更合適？
那麼，一個在某一兩種程式語言裡具有專長的程式設計師，在當他解決一個問題時，會存在一定的侷限。他會侷限於他使用的語言允許他做的事。因此，他不會成為一個好的軟體設計師或分析師。
如果我們不用這些優秀的程式設計師，誰又能擔當軟體設計的任務呢？當然不會是那些完全不懂程式設計的人了。我們需要的是一種通才。一個優秀的軟體設計者必須通曉過程式，物件導向式，函式式，以及邏輯式程式語言—還包括各種優秀的軟體開發方法論。他不能只熟悉一種方法模式、像一個專業領域人員那樣。當然，他自己並不能寫出複雜的程式，因為他的知識太寬泛。儘管如此，他卻能正確的判斷出怎麼樣的設計才是一個正確的解決方案。如果問題是處理一個釘子，他會找來一個熟練使用錘子的人；如果問題是處理一個巨石，他會叫來爆破部隊，而不是讓你徒勞的用錘子白費力氣。
聯想到一本書裡面提到(子柳寫的《淘寶技術這10年》)，我把大致意思歸納如下：
在系統的發展過程中，架構師的眼光非常重要，作為程式設計師，只要把功能實現即可，但作為架構師，要考慮系統的擴充套件性，重用性，對於這種敏銳的感覺，有人說是一種"程式碼潔癖"。淘寶早期幾個架構師具備了這種感覺。
雖然個別架構師具備了"程式碼潔癖"，但淘寶前臺系統的業務量和程式碼量還是呈現爆炸式的增長，業務方總是在後面催，開發人員不夠就繼續招人，招來的人根本看不懂原來的業務，只有摸索著在"合適的地方"加一些"合適的程式碼"，看看執行起來像那麼回事後，就釋出上線。這樣惡性的迴圈中，系統越來越臃腫，業務的耦合性越來越高。開發的效率越來越低。借用當時流行的一句話"你寫一段程式碼，編譯一下能通過，半個小時就過去了;編譯一下沒通過，半天就過去了。“
在這種情況下，系統出錯的概率也逐步增長，常常你是修改了商品相關的某些程式碼，發現交易出現問題了，甚至你改了論壇的某些程式碼，旺旺又出問題了。這讓開發人員苦不堪言，而業務方還認為這些開發人員辦事不力。
由於當時從矽谷空降了一位技術高管，他告訴我們一切要以系統穩定執行為中心，所有影響系統穩定的因素要解決掉。每做一個日常修改，必須對整個系統做迴歸測試一遍。多個日常修改如果放在一個版本中，只要一個功能沒有測試通過，整個系統都不能釋出。我們把這叫做火車模型：任何一個乘客沒有上車都不能發車。這樣做的後果是，新功能上線速度慢了，所以當時明顯感覺到業務方的不滿。壓力很大。
由於把每天晚上都需要做一次整個系統的迴歸測試，在這種要求下，整個系統很龐大，我們不得不對這個超級複雜的系統開始肢解和重構。比如把使用者資訊模組拆分出來，叫做uic,它只處理最基礎的使用者資訊操作：getUserById，
getUserByName等。
系統進行拆解後，相互之間互補影響，不會因為一個使用者中心程式出錯，交易無法使用。
新做的淘寶旅行，淘寶彩票，只是在交易流程資料需求上不同。但是使用者資訊是跟淘寶主站類似的，如果當時能夠做系統拆解，就不用重新做一遍,呼叫uic中的資訊即可(現在的淘寶旅行，淘寶機票是分開展示的就是這個原因，當時為了不給淘寶主站添亂，單獨重新寫了兩套系統用於旅行和機票)