2010-01-06 08:10:16 來源：CIO時代網(wǎng)
很多人談架構(gòu)師，其實有兩種架構(gòu)師，一種是業(yè)務(wù)架構(gòu)，一種是技術(shù)架構(gòu)。我的經(jīng)驗和教訓(xùn)局限于技術(shù)架構(gòu)，所以本文特指技術(shù)架構(gòu)師。
畢業(yè)前一年，畢業(yè)后7年，大約8年的技術(shù)領(lǐng)域經(jīng)驗和教訓(xùn)，參加過大小項目若干，有被人傳頌的成功經(jīng)驗，也有慘痛的失敗教訓(xùn)。在以前一直作為技術(shù)尖子，在不同的領(lǐng)域逐步填充各方面的知識，最近一年開始做架構(gòu)設(shè)計。以下是我的一些看法。
技術(shù)架構(gòu)師要有責(zé)任心
比如說，過去經(jīng)歷過的一個大項目（數(shù)百開發(fā)人員，基礎(chǔ)引擎數(shù)十人），這個大項目有一個基礎(chǔ)模塊，早期設(shè)計不良，有比較嚴重的性能問題，結(jié)構(gòu)混亂，職責(zé)不清，很多人早期就發(fā)現(xiàn)了這個問題，眾所周知。但是一直沒改，說法是，改動的成本太大了，其他的部分要跟著改。但是,越晚改定,付出的成本就會越多。這個基礎(chǔ)組件的在隨后導(dǎo)致了多個嚴重問題，包括性能問題（占用內(nèi)存多），開發(fā)效率問題（結(jié)構(gòu)混亂，使用麻煩），等等。多年后，還問起這個組件時候，相關(guān)的同事都說，某某組件太爛了，沒辦法改啦。經(jīng)常會想起這件事，想這究竟為什么會這樣，怎么解決他。責(zé)任心是其中最重要的問題，當時的技術(shù)架構(gòu)師沒有負責(zé)任把這件事情解決了，讓他拖下去。
談到技術(shù)架構(gòu)師的素質(zhì)，當然要技術(shù)功底深厚，但這是基本素質(zhì)，不是關(guān)鍵素質(zhì)。我認為技術(shù)架構(gòu)師的關(guān)鍵素質(zhì)是責(zé)任心。作為架構(gòu)師，你來設(shè)計這個架構(gòu)，它是你的心血，你要“愛”它，為它的長久發(fā)展打好基礎(chǔ)，甚至犧牲一些短期利益。
我們都是在成長的，經(jīng)常遇到機會，做超出自己能力范圍的事情，架構(gòu)師在設(shè)計第一個架構(gòu)時，甚至第N個架構(gòu)師時，都有可能是超出自己能力了，然后在實際的工作中，把能力逐步提高。早期的設(shè)計可能是不夠好的設(shè)計，同時已經(jīng)應(yīng)用在實現(xiàn)中了，但是你的能力隨后提升了，認識到其中的問題了，你需要改正它，改正是需要成本的，作為架構(gòu)師，要有責(zé)任心，敢于承擔責(zé)任，對過錯負責(zé)，把他改過來。
很多項目的頑癥都是沒有人敢于承擔責(zé)任留下來的！而作為架構(gòu)師，就一定要負責(zé)任，為萬世開太平！
技術(shù)架構(gòu)師要有堅持
有一次，我做了技術(shù)架構(gòu)方面的一個方案，要執(zhí)行它，大家（包括一些經(jīng)理）都持反對態(tài)度，但是我最終一意孤行，堅決推行，最終取得非常好的效果，成為這個技術(shù)架構(gòu)中最關(guān)鍵的技術(shù)之一。
作為技術(shù)架構(gòu)師，可能你在團隊中技術(shù)把握能力最好，比其他人思考的更多。如果你相信你的技術(shù)決定一定正確，那你就堅決推行它，不顧政治，不顧諸神！
遇到不擅長的問題怎么辦？
作為架構(gòu)師，面臨的問題多方面，總會又遇到不擅長的領(lǐng)域，這時候，找其他同事，征求他們的決定，一起制定方案，或者干脆完全把決定權(quán)交給擅長這方面的同事。一定不要不懂裝懂，外行管內(nèi)行。
做錯了，怎么辦？
總會有做錯的事情，怎么辦呢？不要太顧面子，少找借口，接受批評，迅速改進。挨打要立正！別人也不會因為你一個錯誤而否定你全部的。根據(jù)經(jīng)驗，做錯了事情然后改進的人，通常更受重用。原因是，錯誤發(fā)生了，領(lǐng)導(dǎo)們知道這個問題的難度，你解決了，就說明你解決了一個有難度的問題。
要深入了解實際情況
Ivar Jacobson最近講到技術(shù)架構(gòu)師，說執(zhí)行代碼比宏觀架構(gòu)更重要。古今中外，有一個共同的道理，就是細節(jié)決定成敗。也有說法是“魔鬼總是在細節(jié)中”。架構(gòu)的一些問題總是反映在實現(xiàn)細節(jié)中，或者使用細節(jié)中。作為技術(shù)架構(gòu)師，你最好能夠經(jīng)常閱讀使用架構(gòu)的開發(fā)人員的實際使用情況，打開工程，閱讀代碼，然后把程序跑起來，觀察執(zhí)行情況。在最近作的一個技術(shù)架構(gòu)中，其中多項重要的技術(shù)方案，都是觀察了開發(fā)人員的代碼之后總結(jié)然后做的改進方案。
技術(shù)架構(gòu)師要面臨的技術(shù)細節(jié)很多，例如分層細節(jié)，數(shù)據(jù)庫命名規(guī)范，代碼規(guī)范，spring配置文件管理，ibatis配置文件管理，日志輸出規(guī)范，findbugs定期檢查，作Eclipse插件把一些技術(shù)方案固化下來，經(jīng)常維護wiki知識庫，作code review，整理項目依賴，日構(gòu)建制品輸出管理，等等。每個具體項目的細節(jié)都不一樣，細節(jié)處理不好，就會產(chǎn)生“魔鬼”。
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個人認為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，請及時通知本站，予以刪除。
搶沙發(fā)
