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

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

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

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

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

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

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

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！