從前端工程師到前端架構師, 我們經歷了什麼?

方天發表於2018-04-10

前言


前端架構師, 聽起來就是個很高大上的 Title, 每個初入行的前端工程師在面試時, 被問到你未來的方向是什麼? 我們或許都會很順口的回答, "嗯, 朝著架構方向走吧...", 那這個像是順口溜的答案背後, 從身體到思維, 我們究竟經歷了什麼樣的轉變呢? 嗯.., 讓我努力回憶下, 從頭開始, 向各位分享這種奇妙的轉變過程.

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

這次的面試時間很長, 長到我已經忘記了, 我是怎麼回答, 什麼是架構這個問題, 但是從我說出架構這個詞開始, 對架構的思索的種子, 就在我腦海中種下了, 每當坐地鐵, 閒下來, 蹲坑的時候, 我都會想起這個問題. 雖然我經常思考, 但這個問題在我腦海中依然是一堆問號. 如果要給整個轉變劃分個階段的話, 我想這個階段可以稱為 [ 架構思維的萌芽 ]

架構思維的萌芽


每一種思維模式都會有一個思維的起點, 如果把架構看成是一種思維模式運作的結果, 那我們在思考架構的時候, 其實是啟動了一種思維模式, 通過在這種思維模式下不斷的思考, 我們的大腦會不斷建立起各種聯絡, 這種聯絡會將你所有的知識, 經驗串聯起來, 最終得到一種快速的思維通路, 你越思考, 理解得就越深刻, 架構就逐漸在你腦海裡清晰起來, 這一切自然有一個起點, 那就是架構思維的萌芽

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

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

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

架構思維的混沌


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

架構思維的成型


這裡本沒有路, 走的人多了就成了路, 軟體工程從建築領域搬來諸多概念, 例如架構, 回顧歷史, 從四人幫整理出設計模式開始, 軟體開發經歷了巨大的變革, 即便是 UML 都在持續發展, 但其實在這個領域內一直有一塊沒有被覆蓋到的角落, 那就是前端, JavaScript 從一種玩具語言發展到如今的 Web 開發中的"組合語言", 變化巨大, 但在架構上的思考其實並不多, 從 Facebook 提出的 Flux 架構, 前端開始脫離歷史的影響, 我們發現, 不是前端沒有架構, 而是還沒我們被創造出來.

大廠技術上的束縛, 迫使我離開尋找新的平臺, 這個世界在快速變革, 但不是所有平臺都能適應這種變革, 也不是所有平臺能發揮出每個人的能力, 作為工程師, 我們不光為錢, 也為一點點情懷, 改變世界, 即使一點點.

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

就如本文開頭提到的, 我所看到的這個程式碼的世界, 開始有了層次, 有了架構, 開始有方法去解決混沌和無序, 而我想這其實也僅僅是架構師生涯的開始, 後面的階段應該叫 [ 架構師思維的發展 ]了吧.

把簡書上的冷飯放到掘金上來炒一炒, 看看能熱乎不 :<>

相關文章