標籤:

什麼是架構,什麼是架構師?

原文鏈接:什麼是架構,什麼是架構師?

作者|王曉波

編輯|韓婷

什麼是架構,什麼是架構師?這似乎是聊架構話題時永恆的問題。

從內心講我真的不想回答架構具體需要做什麼,架構師應該具體負責什麼。因為從實際情況看,在不同的系統層級,不同的需求下架構師的職責也會不同;從不同的技術角度看,架構師又是個變色龍——一時是技術的大拿,一時是技術的規劃者,一時是技術團隊的指揮者。

那麼,該如何回答「什麼是架構,什麼是架構師」這個問題呢?這或許需要先搞清楚另外一個問題——一名程序員是如何走上架構師之路的?我從許多朋友那裡了解到了很多實際案例,程序員走上架構師之路,總結起來最多的原因是因為他早前代碼寫的好。

那麼,代碼寫的好就是架構嗎?顯然不是。代碼寫的好只是表象,做所有事情都需要規劃,尤其是一個複雜的軟體系統,這更需要規劃,否則可能連一行代碼都寫不出。複雜的軟體系統一定會需要做很多抽象設計、對象規劃、介面規劃等準備動作。也就是「上一輩程序員」口中所說的:詳細設計。做架構主要的事情也依舊如此,需要對整個系統進行系統的規劃:模塊、通訊、邊界、擴展、技術下沉等工作。這樣的規劃完成之後項目方能正常跑起來。

當然,架構也不僅僅是規劃,還要做的另一件大事就是技術識別。識別出系統中技術的難易區域,並分解複雜技術,使之成為一個個技術的黑盒子,在此之上再進行新的技術規劃,使整個系統從技術角度來看是分層次的,從難到易,從大到小,但各層之間又是互相的黑盒。這也常說的讓系統模塊間達到「雞犬相聞老死不相往來「的狀態。

系統技術的識別完成之後還要對另一種技術進行識別,即人的技術。什麼樣的工程師適合寫哪一層的代碼,那一層的技術對程序員技術的深入程度要求到哪個點上。在做完這些事情整個架構表面上看是平穩進行了。

但實際上,架構的問題一定會再次前來打擾:首先是測試工程師來詢問「對於整體系統架構而言這個應用該如何更好的被測試?」「我們需要用什麼樣的技術來更好地保證軟體的質量?」然後是運維工程師來詢問「該系統將跑在什麼樣的環境之上?」「我們應該提供什麼樣的伺服器?」「伺服器上我們會做哪些配置和安裝哪些基礎軟體?」「我們需要提供一個什麼樣的網路環境?」「有什麼樣特殊的網路配置?」「我們需要做哪些安全策略?」……此時,架構師不時會像是一個掉入冰洞的獵人無比無助,頭頂成群的蒼蠅飛著,這些問題,有的懂點,有的不專業,還有的聽說過沒幹過,有些僅限知道原理。其實這些辣手的事情是考驗架構師的一種能力:技術的寬度。

一個架構師需要足夠的技術的寬度。從軟體到硬體,從開發到測試,從運維到安全等都需要面面俱到的了解。當然你可能不是這單方面領域裡面最深入的人,但是你需要知道它們是怎麼做的(不僅僅是皮毛,要深入原理),並且要知道它們組合起來是個什麼樣的東西。技術面也足夠寬了之後,是不是就會成為完美架構師呢?

答案是不會,因為還有新的問題要過來。這次的問題諸如「系統在未來的運行過程中運維需要做什麼?」「系統在未來的功能迭代中如何更方便的擴展?」「系統應該怎麼修改?」「系統應該被怎麼樣升級?」這時的你是不時很困惑?是不是感覺這個架構的世界好長啊,怎麼像保姆一樣什麼都要管。但仔細想想這是應該的,因為一個系統初次開發並交付只是它生命周期中的一小部分而已。後面的維護、改造、升級才佔了整個軟體生命周期的絕大部分時間。你是它的架構設計者,是它靈魂之所在,你當然應該設計好它的未來。這也是架構師做好的最後一件事情:系統未來的設計。

仔細想想,上文提到的這些案例全是架構的糗事,但糗事其實是架構師成長路上的必經之路。因為一個沒有經歷失敗的架構師一定不是個好的架構師。只有經歷各種苦難,越過各種坑和各種痛苦之後才能成為一個優秀的架構師。架構師也是一個很獨特職業,不像現代教育里已經很成熟的人文和物理教育體系,勤奮的人大都能經過系統的閱讀和教育能走向成功。架構更像一種藝術、一門哲學,架構師們也彷彿經過多年積累後忽然間就像打通了任督二脈。那麼走向架構師的路是不是無跡可尋呢?——這個問題留個大家來思考。

閱讀原文

推薦閱讀:

15年編程生涯,資深架構師總結的7條經驗
如何成長為一個專業的基礎架構平台架構師?
求意見,軟體研發轉行測試研發,職業目標:測試架構師?
架構師和產品經理工作職責與內容有哪些異同?
中年程序員都在想什麼?

TAG:架构 | 架构师 |