前端架構：從入門到微前端

架構做什麼？很多人第一次看到這個詞都會有疑問，甚至做過幾年開發之後，仍然會問“需要架構師麼？” 某種程度上，架構師的界限是模糊的，它需要先是開發者，然後是架構師，它必須懂，且要比普通開發者懂得更多。 架構是“粗、細”兼備的事情，粗的層面，整個團隊的人員構成、技術棧分佈、成員間的合作機制、開發及發佈節奏等，細的層面，代碼編寫規範、管理規範、組件庫、工具選擇、文檔的整理和維護、性能監測和優化等。總的來說，是需要具備豐富且完整經驗的人才能夠勝任。 那麼“微前端”又是什麼概念？簡單說，技術編程從來都是在經歷“分分合合”，要麼分拆，要麼聚合，都是爲了更好地管理和維護代碼，過去常說的模塊化和組件化多是代碼層面，而微前端是一種類似於微服務的架構，它將微服務的理念應用於瀏覽器端，即將單頁面前端應用由單體應用轉變爲把多個小型前端應用聚合爲一的應用。各個前端應用可以獨立開發、獨立部署。 它可能帶來三個方面的收益：應用自治、單一職責、技術棧無關。 你可能覺得這些並沒有給你的項目造成困擾，那麼其實採用微前端架構的另一個重要理由是“遺留系統遷移”，比如過去編寫的單頁面應用，已經在線上穩定運行了，也沒有新的功能。對於這樣的應用來說，沒有理由浪費時間和精力去重寫，而這些應用是使用舊的、不再使用的技術棧編寫的，框架本身已經不更新，既然應用可以使用，就不用花太多的力氣重寫，而是直接整合到新的應用中去。 最後，回到架構這件事上，架構跟項目密切相關，而項目又跟業務密切相關，所以從來都無定論，需要開發者根據自己的情況去選擇實施。

二零一九年讀完的第八十二本書，斷斷續續讀了差不多半個月，終於在從廣州去深圳的高鐵上完結了。這本書是從比較宏觀的角度來看待前端這個東西，對於有一定前端工作經驗的人比較有用，如果沒有一定的工作經驗去看反而會覺得虛。總得來說還是值得一看的。

在我們的職業生涯裏，維護應用的時間遠遠長於啓動一個新的應用。當我們覺得啓動應用更有挑戰的時候，是因爲維護應用的時間太長。在經歷多個項目之後，筆者才明白維護一個系統有多難，如何讓一個我們覺得“爛”的系統慢慢變好？舊的系統給我們帶來一系列深入的思考，我們會思考平時哪裏做得不好，應該怎麼做才能讓系統變得更好？如果能不斷地在新舊系統之間切換，那麼我們就能理解好的架構的意義，好的設計的初衷。並且，只有經歷過遺留系統，才能讓自己真正地成長。

之前買的實體書，十一花了幾天讀了一下。總體來看內容還是比較散並且比較 theoretical，理論名詞太多。前半部分大部分內容其實也可稱爲前端工程化實踐，只有第九、十章的微前端實現想法還是比較有意思的。不過所有的微服務化理論，無論是前端還是後端都只有借鑑意義而已，所謂的 trade-off 衡量要小心過猶不及。BTW，“如果能不斷地在新舊系統之間切換，那麼我們就能理解好架構的意義”這句話十分贊同。

這本書講了前端的整體開發流程，結合作者的開發經歷，着重講了微前端的應用，頗有啓發。

花了50多幣，不到3個小時開完。 我覺得這本書適合工作3-5年，經歷過多個項目或前端leader看看；對於經歷多項目，多框架，多語言開發的人員說，這本書會帶你總結一下，跳出細節和具體技術，從宏觀角度重新審視一下經歷遇到的問題和解決方法。對於管理人員，書裏提到的一些方法和工具可以參考，特別是經驗的提煉、模式的應用。這本書到時帶我回顧了一下前端的發展歷史，記得最初的html、Css，js、servlet輸出 以及ajax的異步通訊請求；jquery等等到如今各種組件、模塊、框架；開發形式方式都在改變，同時要求也在改變，大前端、自適應；甚至是0代碼。這樣以來以怎樣的粒度、耦合度解決相關行業的問題，就尤其重要了。

不能歸爲教程，也不大適合作爲傳授知識的書，可定性爲一本關於作者經驗總結與分享的書。 讀完感受就是看得太細反而並未有許多獲益。總的來說作者對前端的架構涉及到的總結介紹的很全面，適合作爲參考，更像是把前端所有菜式都擺弄了出來，如何選擇取捨則丟給了讀者去思考。可以從思維上獲取不少認同和指南。這點上也不得不佩服作者知識面的廣泛。

看完了第二遍。並且想推薦給我的前端朋友們都看看。重塑了我架構概念的一本書。寫代碼的本應該就能從全局去看業務，到細節裏寫代碼。所以還是認爲解耦業務的能力最重要了。能扒開頂層業務做好基礎架構後面的程序員會感激很多年。

遠程辦公這兩週的下班時間斷斷續續看完的，書的後半部分還是值得一讀的，最近剛好遇到了一個新的架構上的問題，目前還沒有想出聰明的解決方案，能從中得到一些啓發，也對自己工作這兩年多以來做的很多事情有了更深刻的感悟體會和總結。

前面7章能看懂，後面幾章就比較喫力了。前端小白，還還不太適合������這類架構書，以後有機會，再重新理解一遍。