前端架構師們認為有多個關鍵的決策需要在專案啟動之初就制定下來，如果等到開發階段的後期再考慮，不是已經用不上，而是一開始錯誤的決定已經造成了無法挽回的損失。一旦做出這些決策，我們的任務就是去輔助視覺設計、平台開發、底層結構，使之能最大程度滿足需求。
如果我們有這樣的機會，那麼可以建立乙個很長的願望清單：
我們都在追求的理想的狀態是，**每一行html都由程式自動生成，而作為前端開發人員，我們只需要管理這個用來產生標記的模板和流程，遺憾的是，現實通常並非如此。即使在最好的情況下，也存在使用者生成的內容，而這些內容幾乎都無法自動新增css類名來標記。無論cms系統(可以理解為後台)自動生成html的能力如何，讓cms決定類似表單和導航欄這樣的標記，有時候會更簡單。
模組化標記和手寫的靜態標記的區別在於，程式化地執行完之後，我們還可以通過一套類名系統給標記動態新增css類名。而且不再通過元素標籤和層級關係來決定視覺外觀。讓我們看看如何用bem原則(乙個css規則，下面會說到)模組化地實現乙個簡單的導航：
要使用這種模組化方法，我們首先需要改變構建頁面的方法和思路。作為前端開發人員，我們的工作就是把視覺語言拆解成最小單元，拆解之後，我們可以建立規則，對這些最小單元進行重組。
上面提到的bem(block element modifier，塊元素修飾符)是乙個css類名命名規則，它建議每個元素都新增帶有如下內容的css類名：
如果我們想渲染我們樣式中的某一塊內容，首先需要載入以下內容
自上而下的樣式命名方法意味著，每次修改我們都要寫乙個更長的、更具體的選擇器，同時，因為標記順序極為嚴格，每塊內容都很難重排或者替換。當然我們可以抽出乙個單獨檔案，並把它需要的所有樣式合併到單獨的乙個檔案裡，但是這麼做基本意味著完全重做這個元件裡的css檔案，每塊內容都很難重排或者替換。
因此我們指定了一些規則，以下是我們指定這些規則時需遵循的規範：
最後指定的設計系統的規則如下
建立可復用的函式。比如我們常用的addclass操作，如果需要多次建立新的.green-alert類名，只需要修改定義好的add_background方法：
$.fn.add_background = function(color)
單元測試時將應用程式分解為盡可能小的函式，並建立可重複的、自動化的測試用例的過程。「一次只做一件事，並把它做好」是構建基於單元測試的應用程式的原則(函式式)，我們在寫函式時經常想同時實現很多功能，結果最後不僅降低了了效率，還增加了測試的難度。
單元測試的基本思路是呼叫要測試的函式，傳遞一些預先設定好的引數，並描述結果是什麼。
function calculateshipping(distance)
}qunit.test('calculate shipping', function(assert))
把你的**效能基線與行業平均水準和通用的最佳實踐相比較是必不可少的。
httparchive(是個不錯的服務，它測試並記錄了幾十萬個**，有幾個值得注意的資料如下：
前端架構設計 層次設計
我們在開發的不同階段，構成的架構因素是不同的，基於這個思路，架構可以分為 系統級架構 應用級架構 模組級架構 級架構 應用在整個系統內的關係，如與後台服務如何通訊，與第三方系統如何整合。在設計前端的時候，首先應該考慮的，是前端系統與其他系統之間是怎樣的關係。這種關係包含，業務關係和協作機制，比如與其...
vue專案前端架構設計
為更好地實施我們的業務需求，需要一些規則或思考來幫助我們設計架構我們的前端工程,本文將以vue專案為例，討論如何設計與實施我們的專案架構，來滿足版本的迭代 更新.元件 元件 乙個個的可復用單元，單頁面程式的元件跟傳統的ui元件稍有不同，不僅僅包含了樣式，也包含了容器元素。可以泛化元件，抽取出一些引數...
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...