在讀了這本書后對前端架構也有了進一步思考。
書中提到
前端架構圍繞四個核心：代碼、流程、測試、文檔
圍繞這四個核心及項目經驗，我做了如下總結，並結合書中的內容給出相應的解決方案
1. 編碼規范
css類名命名無規律
問題暴露
就所在部門來講，由於前端開發能力欠缺，工程師在對css的編寫上天馬行空，一時爽就行了。
css類名的命名無規律將會導致可能出現的命名沖突，然后不同的工程師由於不清楚狀況就會通過提高自己樣式標簽的優先級來相互覆蓋。最后導致的是經常會有某個功能合並代碼之后直接不能用，於是還得花額外的時間來查找問題。
由於命名的不規范，很多標簽會有重名的情況，如果只想改一個標簽的樣式，可能還會涉及到其他多處標簽。
關於css代碼還有一個問題，就是通用屬性值沒有相應的變量，想改網站的字體顏色要逐個標簽地審查元素來找。
解決方案
-
css命名需要遵循某種規定，如書中提到的OOCSS、SMACSS、BEM方法
-
css命名盡量符合單一職責原則
-
減少css選擇器的層級，因為這不僅影響性能，還會導致樣式的節點依賴
-
使用css預編譯工具，如sass、less等，充分利用變量功能
2. 開發流程
代碼改動引發災難
問題暴露
實際項目中，js代碼和css代碼隨着項目的復雜度提高，其耦合性也相應提高。
對於js來說，比較好的設計應該是模塊化，所以項目中引入requirejs來進行模塊化加載。
然而工程師由於對模塊化觀念的淡薄以及不熟悉requirejs，他們會自己定義各種全局變量或全局函數以方便讀取。
加上公司使用的是svn進行版本管理，在看到提交的代碼時想死的心都有了。
一到需求變更的時候，某個涉及到變更的全局函數被修改了，還需要測試人員耗費工作量去測試其他相關的功能時候還能正常工作。
解決方案
-
使用插件強制代碼規范，如jslint等
-
正確使用版本控制工具，推薦git進行管理，能利用切換分支來檢驗各自提交的代碼
-
使用自動化部署方案，構建持續集成服務，並只發布編譯后的資源
開發的網頁和設計圖有出入
問題暴露
這個問題的出現是兩方面，一方面是ui設計師的專業性不強，比如在標注時會把所有元素標上像素值的長寬。另一方面主要是工程師在調樣式的時候可能會互相影響，就如書中提到
即使你的代碼完美無缺，也會被其他開發者的短短幾行不正確的代碼破壞掉。
其他開發者一直在做其他的表單組件。並沒有意識到他們正在編寫css類是和你的聯系表單共用的。
無關頁面上的小樣式的改動往往也會被QA 團隊忽略
我們在開發項目的過程中經常遇到合並完代碼后頁面莫名其妙錯亂了，這還好，能及時發現，但要是那些比較小的變動往往會通過客戶反饋給部門，於是又是一場災難。
解決方案
增加視覺還原測試，讓開發者能在樣式發生變動后及時知道並作出修改
3. 自動化測試
測試投入時間太多
問題暴露
正如先前提到的，往往在需求變更之后，測試人員需要分析需求變更點並對涉及到的功能進行重新測試。這是低效的方式。但開發人員一般注重功能開發而忽略測試用例的編寫。
這便導致了前端測試過程對測試人員來說相當痛苦。
解決方案
-
增加自動化單元測試的代碼編寫環節，條件允許時可引入測試驅動開發
-
測試用例盡量由測試人員擔任單元測試的編碼工作，做到盡量全面的測試覆蓋率
4. 文檔輸出
不重視文檔輸出導致額外工作量
問題暴露
文中提到
一般而言，如果不是團隊中重要成員要離開，我們幾乎都不會意識到文檔的重要性。等到那個時候，大家將不得不停下手頭的工作，優先編寫所有文檔。
這在項目中最有體會。
目前涉及到的項目都需要快速迭代，導致文檔輸出工作一直被往后延，最終只是勉強輸出交付件文檔，開發相關文檔一直不見蹤影。
到了項目交接，或者是交由維護人員維護時，開發人員還需要時刻准備被叫去解釋功能上的實現方式等問題，更別提重要成員離開了。
解決方案
新增自動化文檔生成工具，如Hologram、SassDoc等
在代碼中注釋要盡量詳細，並能使用Markdown進行內容注釋
其他（吐槽）
這兩年來的面試中，總會有自稱是前端工程師，但一問一些基礎問題都答不上來的人。我想說：只會寫簡單html+css+jquery的程序員離前端工程師還有距離的。
根據書中提到的及項目實踐總結出前端工程師大概需要具備的技能有：
-
基本計算機知識和html+css+js語言基礎
-
原生js編碼能力，不依賴jquery
-
編碼規范，如命名注釋等
-
前端框架思想，如mvx，模塊化等
-
熟悉markdown文檔編寫
-
熟悉主流前端工具的使用，如npm，grunt，gulp等