關於技術架構師的一些看法

很多人談架構師，其實有兩種架構師，一種是業務架構，一種是技術架構。我的經驗和教訓局限於技術架構，所以本文特指技術架構師。

畢業前一年，畢業後7年，大約8年的技術領域經驗和教訓，參加過大小項目若干，有被人傳頌的成功經驗，也有慘痛的失敗教訓。在以前一直作為技術尖子，在不同的領域逐步填充各方面的知識，最近一年開始做架構設計。以下是我的一些看法。

技術架構師要有責任心

比如說，過去經曆過的一個大項目（數百開發人員，基礎引擎數十人），這個大項目有一個基礎模組，早期設計不良，有比較嚴重的效能問題，結構混亂，職責不清，很多人早期就發現了這個問題，眾所周知。但是一直沒改，說法是，改動的成本太大了，其他的部分要跟著改。但是,越晚改定,付出的成本就會越多。這個基礎組件的在隨後導致了多個嚴重問題，包括效能問題（佔用記憶體多），開發效率問題（結構混亂，使用麻煩），等等。多年後，還問起這個組件時候，相關的同事都說，某某組件太爛了，沒辦法改啦。經常會想起這件事，想這究竟為什麼會這樣，怎麼解決他。責任心是其中最重要的問題，當時的技術架構師沒有負責任把這件事情解決了，讓他拖下去。

談到技術架構師的素質，當然要技術功底深厚，但這是基本素質，不是關鍵素質。我認為技術架構師的關鍵素質是責任心。作為架構師，你來設計這個架構，它是你的心血，你要“愛”它，為它的長久發展打好基礎，甚至犧牲一些短期利益。

我們都是在成長的，經常遇到機會，做超出自己能力範圍的事情，架構師在設計第一個架構時，甚至第N個架構師時，都有可能是超出自己能力了，然後在實際的工作中，把能力逐步提高。早期的設計可能是不夠好的設計，同時已經應用在實現中了，但是你的能力隨後提升了，認識到其中的問題了，你需要改正它，改正是需要成本的，作為架構師，要有責任心，敢於承擔責任，對過錯負責，把他改過來。

很多項目的頑症都是沒有人敢於承擔責任留下來的！而作為架構師，就一定要負責任，為萬世開太平！

技術架構師要有堅持

有一次，我做了技術架構方面的一個方案，要執行它，大家（包括一些經理）都持反對態度，但是我最終一意孤行，堅決推行，最終取得非常好的效果，成為這個技術架構中最關鍵的技術之一。

作為技術架構師，可能你在團隊中技術把握能力最好，比其他人思考的更多。如果你相信你的技術決定一定正確，那你就堅決推行它，不顧政治，不顧諸神！

遇到不擅長的問題怎麼辦？

作為架構師，面臨的問題多方面，總會又遇到不擅長的領域，這時候，找其他同事，徵求他們的決定，一起制定方案，或者乾脆完全把決定權交給擅長這方面的同事。一定不要不懂裝懂，外行管內行。

做錯了，怎麼辦？

總會有做錯的事情，怎麼辦呢？不要太顧面子，少找借口，接受批評，迅速改進。挨打要立正！別人也不會因為你一個錯誤而否定你全部的。根據經驗，做錯了事情然後改進的人，通常更受重用。原因是，錯誤發生了，領導們知道這個問題的難度，你解決了，就說明你解決了一個有難度的問題。

要深入瞭解實際情況

Ivar Jacobson最近講到技術架構師，說執行代碼比宏觀架構更重要。古今中外，有一個共同的道理，就是細節決定成敗。也有說法是“魔鬼總是在細節中”。架構的一些問題總是反映在實現細節中，或者使用細節中。作為技術架構師，你最好能夠經常閱讀使用架構的開發人員的實際使用方式，開啟工程，閱讀代碼，然後把程式跑起來，觀察執行情況。在最近作的一個技術架構中，其中多項重要的技術方案，都是觀察了開發人員的代碼之後總結然後做的改進方案。

技術架構師要面臨的技術細節很多，例如分層細節，資料庫命名規範，代碼規範，spring設定檔管理，ibatis設定檔管理，日誌輸出規範，findbugs定期檢查，作Eclipse外掛程式把一些技術方案固化下來，經常維護wiki知識庫，作code review，整理項目依賴，日構建製品輸出管理，等等。每個具體項目的細節都不一樣，細節處理不好，就會產生“魔鬼”。