軟件架構師 — 作很差士兵的將軍不是好將軍

上週，一位同事來到個人座位想和我聊天，當他看到我正在看程序代碼，因而問了我一句，「你在寫仍是看程序？」。我當時正在看程序，因而個人回答是，「我正在看程序，但我本身也寫程序」。因而，他又問道，「你以爲軟件架構師須要本身寫代碼嗎？」。我說，「實際上是須要的」。他又回了一句，「是否是作很差士兵的將軍就不是好將軍？」。我說，「你這提法到是頗有新意的，我很贊同！」。

還有一次在上MBA課程時，個人一位同窗看到我在教室裏寫程序（實際上是在寫書），他問我「你如今還要本身寫程序？」，我當時回答「是的」，但內心在想，是否是人家以爲我如今（都在讀MBA了）怎麼還要本身親自寫程序呢？（或許是多想了）

今天我想就軟件架構師應不該當本身寫程序談一談本身的見解。做爲開始，咱們多方面要區分兩類架構師。一類是應用層軟件架構師。這類人對於應用（及相關規範）很是的熟悉，其工做重點在於編寫需求相關的文檔，而不關心軟件的具體實現。一般這類人是屬於系統工程（system engineering）部門的，後面稱其爲系統架構師。另外一類人則徹底不一樣，他們除了對於應用有至關的瞭解（但可能不如系統架構師），還對於軟件的結構和設計有很好的認識，這類人一般來自於開發工程（development engineering）部門，後面稱其爲開發架構師。

對於開發架構師，我認爲他應當懂什麼是軟件設計。至因而不是他本身最後完成代碼的編寫工做，或是指導他人完成代碼編寫工做，那就不重要了。最近在與一位MBA同窗聊天時，咱們在談到軟件設計問題時，他忽然問我，「什麼是軟件設計？我以爲軟件設計太虛了！」。對這一突如其來的問題我當時愣了一下，由於在個人頭腦裏設計就是設計（看來有必要寫文章表達我所理解的設計?）。但我馬上意識到，這位同窗道出了軟件行業的一個難題，即在軟件行業中，並無度量軟件設計質量的方法。可能有人會說，從軟件的bug數量不就能夠看出軟件設計是否好壞嗎？這一說法乍一聽有道理。但問題是，有誰會先用了軟件獲得bug數量後反過來看軟件質量以決定是否購買呢？一般，在購買一款軟件（或相關產品時），以前應當是先了解軟件的（設計）質量，而後再決定購買。另外，bug數量並不能真正的反映軟件的設計質量，bug少多是由於產品的複雜度小，但可能設計質量仍是不好，表面的上的高質量實際上是後面用大量的痛苦換來的。還有人會說，如今不是有CMMI嗎？或是其它的質量認證體系，難道這些都不足於證實軟件的設計質量？是的，我認爲如今的認證不少是着重於軟件開發流程的，可是並無提供對設計質量的認證。要知道好的軟件設計流程並不意味着能得到好的設計質量，能夠說流程與設計質量在某種程度上是正交的。因而可知，不管是XP或SCRUM等敏捷開發方法，都不能讓咱們直接得到高設計質量的軟件。那爲何業內就沒有推出設計質量認證體系呢？這不得不提到軟件行業中著名的一個故事 —— 人狼的故事，這個故事告訴咱們「軟件行業沒有銀彈」。其本質是說軟件開發（設計也包括在內）是高度地依賴於人腦的，所以，很難找到生產高質量軟件的通用方法。從設計的角度來講，要獲得一個評估軟件設計質量的體系幾乎是不可能的，由於對設計的好壞很難達成一個普遍的共識和抽取出可操做的準則。

開發架構師若是明白設計的重要性，那他每每須要本身動手去寫一些代碼，去展示本身的設計思想，或者驗證本身的設計想法。作開發架構師不可能只經過畫UML圖就徹底表達本身的思想。另外，一個不能站在工程師的角度去思考問題的開發架構師，很難說他是一個好的架構師。開發架構師除了承擔技術方面的工做，我認爲他在必定的程度上還應當承擔管理方面的工做。好比，激勵團隊採用好的設計方法、重構等等。全部這些都代表，開發架構師應當身體力行地帶領工程師去工做，而不是「高高在上，只懂應用」，更不能成爲一個Super Editor（一味地從開發人員那裏瞭解要怎麼寫，而後將其寫入需求文檔中）。

與開發架構師不一樣的是，系統架構師不寫代碼可能一點也不奇怪，相反他們也不該當關心代碼的具體實現。那是否是這類架構師在其成長過程當中就一直不用寫代碼呢？顯然不是。我相信，一名意識到軟件設計重要性的系統架構師其所編寫的需求文檔將更具指導性和開發性。

最後，我想着重強調開發架構師的重要性。在我看來，如今的軟件行業其實非常困難，其根本在於這個行業缺少高質量的開發架構師。我沒有看到哪個公司由於理解不了應用需求而開發不出軟件，相反不明白什麼是設計而使得你們倍受煎熬的情形卻較爲廣泛。

軟件質量源於設計！