論架構師的職責

好久之前（4,5年前）當核心碼農，只需保質保量完成既定任務。技術選型開會的時候隨便yy，反正最後拍板背書的人不是我。完成特定的任務，想算法，作優化，實實在在的產出，頗有成就感。 

而最近這幾年，開始漸漸提高本身，從架構師，技術經理，到技術負責人。如今開會不敢亂說，技術也不敢亂選。由於要給設計作最終拍板，肯定最終的技術架構體系。因此會常常焦慮本身作的設計是否是有坑，是否是太low等等。 

同時在公司有限的資源內，還得決定哪些先作哪些緩一緩。之前我只須要把待作的1234拋出去，具體作啥上頭說了算，你說作1我就作1，不用過腦子。如今常常1234都要作，手頭的資源只夠作2個，優先級還得本身協調，光想這個優先級就頭大。

所以在此開貼，拋磚引玉，談談本身對架構師職責的理解。

首先，咱們應該明確，不一樣公司對架構師的定位不盡相同，並且也和架構師在一個項目中切入的時間點有很大關係。經歷過幾家公司的架構師職位，有的是以技術選型，設計階段給技術團隊提供諮詢爲主；有的則是系統調優，代碼重構，性能優化爲重；而還有些公司，CTO的設想是，產品經理提產品需求，架構師提重構和優化需求，而且做爲顧問參與到全部項目的設計階段。

在我看來，架構師對公司核心業務，組件化，耦合，解耦的理解程度如何，對新技術保持濃厚興趣和探索，決定了一個公司在技術演進發展道路上是否會一路坦途。同時，架構師應該深入理解，架構是被業務推進而發展的。

優秀的架構師在做業時，由於長期經驗使然，會天然不天然的留下平滑升級的餘地。而不會在這個時間點就引入過多架構問題；在構架以前都須要用採起相似僞代碼的形式把問題勾畫一遍，這樣能讓各類關鍵細節問題浮現出來,而後再去討論, 不然就是空談。

架構師不會關注細節，可是架構師須要知道有bug或者性能問題（有人告知或者線上表現觀察出來），而後別人用的時候給出建議。具體爲何有bug，如何作算法優化，架構師能夠不用太深究。架構師關心的是更high level的大模塊之間的關係。固然也有公司要求架構師切實可行的鑽研進去，作好各類優化和調優工做，很有點救火隊員的角色扮演。這種狀況的出現，顯然是前期項目協調和產出產生了較嚴重的問題所致。 

固然本身作實現也有個抽象和分層的問題，我以爲這個問題在不一樣層次上是同構的。網站級別的架構和模塊內部的架構，道理和方法是同樣的。 

不過我想說的重點就是，要抵制那些過分微觀的工程傾向，歷來不作API評審，可是code review 抓的很緊，這就屬於本末倒置，code review原本就是一個微觀的東西，你寫的東西leader評價再好，格式再優美，higher level上是一坨就不行。 

我認爲在各個層面上，能控制界面層就很好了，內部實現是實現的問題，這個在上一層能夠系統的解決，比方引入穩定性和性能反饋，你作個變動我看下好了仍是壞了，到變動這個層次，結論就很強了。

大致上，宏觀指標好的，也更多是fixable的，反過來，不fixable，可是宏觀指標好，你也不必去深究，最多這塊重寫。

最後，一個現實問題，架構師應不該該參與編碼呢？架構師若是徹底不作編碼，時間長了之後本身的知識如何持續更新，與時俱進纔是最大的問題，並且我以爲這基本上是無解的。更壞的狀況是，有些架構師本身的知識懶得更新，全部新的事物，一概要別人往他知道的東西上套。這時候誰還服你，只能是you can you up。

因此，我不認爲脫離編碼去搞架構是一件好事。也不認爲脫離業務去搞技術框架是一件好事，最好仍是一邊幹，一邊搞這些東西。建議適當編碼，目前我每週仍抽出時間看看代碼偶爾也編碼，實際工做中，能夠進行業務和非業務核心層的編寫。