成爲一名前端架構師須要付出怎樣的努力？

提及前端架構師，給人感受上是一個高大上的名稱， 每一個初入行的前端工程師在面試時, 被問到你將來的方向是什麼? 咱們或許都會很順口的回答, "嗯, 朝着架構方向走吧...", 那這個像是順口溜的答案背後, 從身體到思惟, 咱們究竟經歷了怎樣的轉變呢？其實轉變不是一朝一夕的事，而是一種知識與能力的積累。

當我第一次看到架構這個詞, 是在舊的翻了毛邊的編程書上, 而此時對於我來講, 架構僅僅是一個詞, 兩個漢字和一堆概念. 而第一次我本身說出這個詞, 是在14年, 那時轉行寫代碼剛滿1年, 對一個碼農來講, 1年經驗很淺, 不管是從思考仍是手感, 都談不上有太多積累, 可是當對面的面試官, 問道: " 你將來有什麼發展方向? ", 我仍是不假思索的說出了 : "朝架構發展吧... ", "你以爲什麼是架構? ", " ... "

各類碎片時間下不斷對架構的思考, 鞏固了架構思惟在我大腦中的地位, 促使我開始從架構的角度去看待問題, 需求和代碼, 代碼的世界是一種依靠邏輯維護的奇妙世界, 隨着世界的膨脹, 各類邏輯變得難以維護, 最終整個世界崩塌, 但當我加入一點架構以後, 世界的結構開始清晰起來, 慢慢的我開始看到邏輯背後的聯繫, 代碼背後的那些隱藏的輪廓. 尚學堂•百戰程序員陳老師指出在這個世界裏, 沒有完美的架構, 天然也沒有銀彈, 無論如何調整, 維護, 設計和變動, 咱們最終都會迎來這個世界的消亡, 可是一個有架構的世界, 即使是消亡也是有序的。

第一次嘗試加入架構, 是在那次面試失敗以後, 我手上有一個 SPA 的項目, 那時候 angular1.0 尚未發佈, backbone 還在大行其道, 我依靠對架構的一點理解, 嘗試本身去構建一個有序的代碼世界, 結果顯而易見的失敗了, 由於個人知識和經驗儲備不足作出一個有效的架構, 可是這一次嘗試讓我明白了架構的重要性, 相對於 jQuery 時代的麪條代碼, 將代碼合理分層顯然能讓這個世界顯得更有序些. 不管是 MVC, MVW, MVVM, MVP, 都是對開發 GUI 應用如何更好的設計代碼的一種嘗試。

事實上, 在這個階段, 我對架構的理解比起最初的時候更混亂了, 設計模式, 框架, 架構, 這些詞在某一時刻互相混淆在一塊兒, 傻傻分不清, 而有時候, 我會陷入究竟如何區分他們的困境中, 爲了解決這個問題, 我閱讀了一些書籍, 進行了更深刻的思考, 我發現光靠這三個概念, 是不夠的, 爲了走出這個困境, 我發現必須引入新的工具, 這個工具叫上下文, 也叫語境。

隨着工做的不斷深刻，也要接觸各類新的概念, 我對架構的思考開始引入上下文, 我發現有了上下文, 模式, 框架, 架構就開始變得不那麼格格不入了, 在某一個上下文中, 它能夠是模式, 在某一個上下文中, 它能夠是框架, 模式, 框架, 架構在上下文的組合下, 開始可以被靈活使用了, 它們成了我設計和思考架構的工具箱中經常使用的工具. 同時期, 我開始接觸 UML , 另外還包括DDD, TDD 等一些概念, 還有經常使用的架構模式, 像六邊形架構等等, 以及多了一種新工具"邊界", 可是很快我發現我陷入了另外一種困境, 一些新的工具很難被應用在以 JS 爲基礎的前端領域, 而光依靠模式, 框架, 邊界, 上下文設計出來的架構很難進一步細化, 前端架構成了空中樓閣, 沒法落地. 我嘗試生硬的懟, 但最終是徒勞的, 看起來這一階段變得更痛苦了, 沒錯, 就像一個埋頭走了三千里, 本來覺得是終點, 但擡頭髮現依然是無邊無際的痛苦. 或許前端不存在"架構"? 

在工做幾年以後，我加入一家準上市公司負責前端架構的工做, 翻了翻拉勾, 前端架構師開始進入咱們的視野, 雖然比起傳統意義上的架構師, 崗位還不多, 可是欣慰的已經不是那麼百裏挑一, 前端規模化的增加, 對架構師的需求開始反推企業改善現有的團隊架構, 引入架構師更好的解決問題. 這個階段, 思考架構開始變得不這麼磕磕碰碰, 充足的知識和經驗儲備, 讓我開始創建起本身的架構思惟, 得益於對 Flux 架構的應用, 我發現不少前端領域的問題能夠用一個環來解決, 我稱之爲"環形架構", 或者"流水線架構",把同一緯度的數據放在一個環中去處理, 前端複雜的數據流能夠被很好的隔離和管理。