讀《前端架構設計》-前端架構概況

前言

還記得這個活動嗎？【活動】徵集《前端架構設計》書評。這篇讀後感來自北京 @徐進的分享。

正文從這開始～

這斷時間在讀《前端架構設計》這本書，雖未讀完，但是已有不少收穫。

這本書的作者結合自己在Red Hat公司的項目實戰經歷，探討了前端架構原則和前端架構的核心內容，包括工作流程、測試流程和文檔記錄，以及作為前端架構師所要承擔的具體開發工作，包括HTML、JavaScript和CSS等。這本書並不是在將某個技術細節，而是從宏觀的角度分析了當下最高效的前端開發的工作流，以及代碼，測試，文檔的規範。反之，這應該也是這本書的一個小缺點，內容會給人一種蜻蜓點水的感覺。

但作為前端新人的我，很喜歡這本書，它能在前端領域為我指明正確的、高效的、規範的發展道路。如果任按照老舊的開發流程，儘管小的系統尚可應付，但是隨著項目複雜性的增長，老舊的流程絕不是長久之計，但如果能夠把前端開發當成一個值得做出戰略規劃和有投資價值的關鍵元素，那麼我們一定會用另一種態度與謹慎來對待了吧。

什麼是前端架構？

前端架構是一系列工具和流程的集合，旨在提高前端代碼的質量，並實現高效、可持續的工作流。

書中是這樣給出前端架構的定義的。最近幾年，前端才開始蓬勃的發展，這個職業開始逐漸的被人認可，再早幾年，人們對web前端似乎沒有什麼要求，只要能用就行，對於性能，人性化的交互也沒有要求，前端似乎成為了低端的代名詞，更少有人在前端領域深入鑽研，建立一套完善的體系。

在當前蓬勃發展的前端領域，作為一個新晉的一線開發人員，在做項目中也確實會遇到一些問題，比如：該選用那一個前端框架，Vue、Angular亦或是React？如何更高效的和後端的開發人員整合，而不是等他們開發完了在整合，且整合中更會遇到很多問題？如何更方便的對頁面進行調試，既能熱更新，也能很便捷的調試移動端的界面？如果團隊中沒有人擅長於前端的架構，恐怕很可能又會淪為老舊的開發流程，生產出大片無用代碼且效率極為低下。而在團隊中承擔此職責的人，被稱為前端架構師。

架構更像是一種管理，一種對於代碼、流程和規範的管理，對於大型Web項目，前端架構師和軟體架構師同樣不可或缺。軟體架構師的職責是要保證項目中每一步都在總體架構的指導下進行，而不會隨機決定；對於前端架構師也是一樣，他們是項目的決策者，相比於具體編寫的代碼，他們更關注於開發工具和優化流程。

前端架構師職責：

體系設計——清晰描繪產品和代碼的最終形態

工作規劃——制定完整開發工作流

監督跟進——保證項目高效率完成

前端架構的核心？

前端架構師的成長之路不是一蹴而就的，而是需要保持不間斷的學習狀態。這種狀態決定了我們的水平和價值。對於前端開發領域的廣泛涉獵使我們能夠很快上手新技術和方法論。

不能再同意作者文中所說的這句話了，我認為不僅是前端架構師，作為一名學生，工程師，等任何職業都應時刻保持這種持續學習的狀態，有一本書叫做《168 hours》，書中介紹了關於時間利用的問題，一周7天，168小時，除去工作和睡眠和必要的時間消耗，其實屬於我們的可利用的時間還有很多，並不像我們想像的那麼忙，若我們能冷靜下來思考時間，並將這些時間利用起來擴充自己的知識面，提高自己各方面的技能，若能有這種自我驅動力，我覺得不久就能成為項目中的前端架構人才。跑遠了，拉回來。。

而前端架構的核心也是這本書通篇所講述的內容到底是什麼呢？作者將其概括為四個，代碼、流程、測試、文檔。

代碼解決的問題是如何實現系統架構中的HTML、CSS和JavaScript。關於代碼，有一句話我記得特別清楚：」代碼是給人看的，機器只是順便執行了一下而已。「從我知道這句話以後，就時時的提醒自己，自己所寫的代碼對待下一個可能接手我代碼的人有沒有很友善。有沒有寫好代碼的注釋？有沒有將代碼的格式縮進統一，使代碼美觀？有沒有將函數，類，變數的命名語義化？函數有沒有遵守單一職責原則？有沒有盡量降低組件之間的耦合？有沒有提高代碼的可復用性等。這些也是文中作者的觀點，我想能時刻提醒自己寫出高質量的代碼，定是寫出高質量代碼的必要條件。

流程解決的是在構建高效並且防止出錯的工作流中所需要的工具和流程。我認為流程是提高項目開發效率的重要途徑，流程包含在項目開發過程的各個環節，若能極大的優化項目開發的流程，必然會使項目有一個樂觀的結果。當然，在優化前端開發流程的過程中，一定會遇到各種優秀的工具，比如git，gulp等。我覺得這些工具，如果沒有使用過，有機會嘗試一下還是極好的。

流程核心的意義在於清晰地定義前端代碼從開發人員的腦海到用戶瀏覽器所需經歷的各個步驟。

測試也是項目中最重要的一步，能夠為網站搭建穩固基礎。測試也是自己目前最弱的一塊，一方面由於在學校做項目，幾乎所有的項目都是一兩人的小組完成，且最終交付時的要求不高，另一方面也是自己還沒有引起足夠的重視。但是這萬萬是不對的，新代碼給系統帶來的問題涉及方方面面，若不能及時測試，及時反饋自己的代碼，於客戶、於自己都必然是百害無一利吧。

書中在我們為應用程序規劃測試時，提供了以下四條建議。

測試用例應該在建站的同時，甚至在建站之前就需要開始編寫。

測試代碼是真實的代碼，應該一起或立即提交到系統代碼庫中。

必須在所有的測試用例都通過後，才能把代碼合并到主幹中。

在主幹上運行測試工具，結果應該都為通過。

文檔能夠規劃好系統設計的藍圖。身邊很多小夥伴都很厭倦寫文檔，我也不例外，每次接到導師布置寫文檔的任務都是一臉懵逼。但作者說的一句話我很為挺有用：」往往當團隊中重要成員離開時，才會意識到文檔的重要性，到那時大家不得不停下手頭的工作，優先編寫所有的文檔。」想想這句話說的真對，平常我們會覺得好好的寫文檔幹嘛，浪費時間，還不如擼一段代碼來的痛快，但是當我們忘記一些東西的時候，一定會想起來去查需求文檔，介面文檔吧。要調整自己的狀態，正確對待文檔，因為它很重要。

能夠將頭腦中這些看似常識的信息寫到文檔上並非易事，但我們因為沒有文檔而浪費的時間往往比寫文檔花費的時間更多。俗話說，」好記性不如爛筆頭嘛」

我認為這本書是不錯的，它為我指明了方向，幫我認識到自己的不足，以及今後需要繼續完善和努力的地方。額，不過這本書是講前端架構的，並不是提建議哈。

不過，若真能掌握這四大核心，再加上知識的廣度，未來說不定可以做架構呢，哈哈

關於本文

作者：@ 徐 進

原文：http://xujin.pro/2017-05-18-frontend-architecture-overview.html

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