《前端架構設計》讀後感

在讀了這本書後對前端架構也有了進一步思考。

書中提到

前端架構圍繞四個核心：代碼、流程、測試、文檔

圍繞這四個核心及項目經驗，我作了以下總結，並結合書中的內容給出相應的解決方案

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等