前端進階之路: 前端架構設計(1)-代碼核心

DevYK 發布于2019-08-01 18:15 / 1893人閱讀

摘要：可能很多人和我一樣首次聽到前端架構這個詞第一反應是前端還有架構這一說呢在后端開發領域系統規劃和可擴展性非常關鍵因此架構師備受重視早在開發工作啟動之前他們就被邀請加入到項目中而且他們會跟客戶討論即將建成的平臺的架構要求使用還什么技術棧內容類型

可能很多人和我一樣, 首次聽到"前端架構"這個詞, 第一反應是: "前端還有架構這一說呢?" 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備受重視, 早在開發工作啟動之前, 他們就被邀請加入到項目中, 而且他們會跟客戶討論即將建成的平臺的架構要求, 使用還什么技術棧? 內容類型是什么? 這些內容如何被創建?軟件架構師的職責就是要保證項目中每一步都在總體架構的指導下進行, 而不會隨機決定.

現在的前端領域, 隨著JS框架, UI框架和各種庫的豐富, 前端架構也變得十分的重要. 如果一個大型項目沒有合理的前端架構設計, 那么前端代碼可能因為不同的開發人員隨意的引入各種庫和UI框架, 導致代碼量變得異常臃腫, 最終結果可能是代碼變得無法維護, 頁面性能低下,不得已只能推翻重構. 所以我們需要在項目開始前, 同樣的需要對前端代碼進行架構, 一旦前端架構師設計出所有前端開發人員都要遵循的檢驗機制, 建立起系統設計的規范, 那么項目就擁有了可以衡量代碼質量的標準, 前端開發人員也能享受到更高效的工作流. 所以, 前端架構的定義可以用以下一句話來總結:

前端架構是一系列工具和流程的集合, 旨在提升前端代碼的質量, 并實現高效, 可持續的工作流.

本系列的前端架構文章, 將分別圍繞前端架構的四個核心展開, 分別是代碼, 流程, 測試, 文檔.

前端架構的四個核心 (一) 代碼

歸根到底, 所有的網站都是由一堆文本文件和資源文件組成的. 當我們面對制作網站所產生的大量代碼時, 就會發現為代碼和資源設定一個期望是多么重要. 在代碼部分, 我們會專注于如果實現系統架構中的HTML, CSS, JavaScript.

(二) 流程

現在早已過了FTP上傳文件的時代, 那么現在重要的是思考怎么用工具和流程構建一個高效且避免出錯的工作流. 工作流變得越來越復雜, 那些用于它們的工具也同樣如此. 這些工具在提高生產力, 加快效率和保持代碼一致性上帶來了驚人的效果, 但也伴隨著過度工程化和抽象化的風險. 所以, 現有的工作流是需要改變的.

(三) 測試

要構建一個可擴展和可持續優化的系統, 必須保證新代碼和老代碼能夠很好的兼容. 我們的代碼不會獨立存在, 它們都是大型系統中的一部分. 創建覆蓋面廣泛的測試方案, 能確保老代碼還能正常運作.

(四) 文檔

一般而言, 如果不是團隊中的重要成員要離開, 我們幾乎都不會意識到文檔的重要性. 等到那個時候, 大家將不得不停下手頭的工作, 優先編寫所有的文檔. 作為前端機構師, 你要善于在項目開發的同時編寫良好的文檔.

代碼核心 (一) HTML

在前端的架構中, HTML作為頁面的基礎是十分重要的. 如果初始的HTML寫得很爛, 將要寫出很多不必要的CSS和JavaScript來彌補. 反之, 如果如果初始的HTML寫得足夠好, 就能寫出根據可擴展性和可維護的CSS和JavsScript.

首先我們來看一些初級的前端工程師可能寫出的HTML代碼:

這類"div亂燉"的代碼, 是很多初級的前端為應付切頁面的工作寫出來的. 只是單純為了還原psd圖, 而完全你不考慮HTML的可讀性和可維護性.

隨后, 在HTML5之后, 標簽的語義化受到了大家的重視, 采用語義化的標簽, 不僅增加了代碼的可讀性, 也有利于SEO. HTML語義化標簽的使用,這也是在前端架構中需要考慮到的,下面我們來看一下使用語言化標簽寫的這段代碼:

但是如果我們的頁面的菜單有數10項的時候, 就會額外添加

菜單N

, 這類重復的工作量完全可以交給Mustache這類模板引擎來解決, 已Vue中的模板引擎語法來寫HTML, 會減少很多的工作量 :

你也可以使用Handlebars, Jade, artTemplate各種模板引擎到你的項目中, 當然這些都是需要取決于前端架構師前期的所選擇的技術選型. 做為前端架構師, 需要評估HTML產生的過程, 你對內容的順序, 使用的元素和CSS類名有多大的控制權? 這些元素在將來改動起來會有多大難度? 模板的易用性? 你可以通過系統做出更改, 還是需要手動處理? 通過回答這些問題, 可能會顛覆你自己構建HTML和CSS的方法.

(二) CSS

構建CSS現在有很多成熟的方法, 例如使用新的命名空間, 擴充數據屬性或在JavaScript里面定義CSS. 這些方法你可以從BootStrap, ElementUI這類UI框架中找到影子. 下面, 介紹3種比較常用的方法.

1.OOCSS方法(Object-Oriented CSS 面向對象的CSS)

上面這段代碼就展示了如何使用OOCSS方法創建一個可切換的HTML代碼, OOCSS有兩個主要的原則:

分離結構和外觀

分離容器和內容

分離結構和外觀
這里的toggle用來控制結構, simple用來控制外觀,這就是分離結構和外觀的表現. 這樣可以實現外觀的復用, 例如當前的simple皮膚使用直角, 而complex皮膚可能使用圓角, 還加了陰影.

分離容器和內容
這里使用toggle-title就是分離容器和內容的表現, 無論toggle-title的容器是用的

還是

或者是

, 一旦加上了toggle-title這個類名, 那么該容器均已該類名所定義的樣式呈現內容.

2.SMACSS方法(Scalable and Modular Architecture for CSS 模塊化架構的可擴展的CSS)

上面的這段代碼基本展示了如何使用SMACSS方法,在我個人的理解中, OOCSS更多的其實是提供了一種CSS構建思想, 該思想要求將結構和外觀分離, 將容器和內容分離. 但是并沒有提供一套完整的CSS構建規范, 而SMACSS是提供了一套樣式系統, 該樣式系統有5個具體類別:

基礎: 如果不添加CSS類名, 標記會以什么外觀呈現

布局: 把頁面分成一些區域

模塊: 設計中的模塊化, 可復用的單元

狀態: 描述在特定的狀態或情況下, 模塊或布局的的顯示方法

主題: 一個可選的視覺外觀層, 可以讓你更換不同主題

基礎

//base.css
body, form {
    margin: 0;
    padding: 0;
}

a {
    color: #039;
}

a:hover {
    color: #03F;    
}

在基礎代碼中, 應該規定的是頁面中的一些通用樣式,例如將body的margin和padding設置為0 , 設置a標簽的顏色等. 類似于某些人常用的initial.css文件.

布局

//layout.css
#header, #article, #footer {
    width: 960px;
    margin: auto;
}

#article {
    border: solid #CCC;
    border-width: 1px 0 0;
}

這里的布局指的是頁面中一些通用的布局組件, 例如頭部, 側邊欄, 主體和底部這些. 這些布局組件會在多個頁面通用, 所以最好把其放入到一個css文件中. 方便復用. 在SMACSS中, 推薦將布局容器的頂級標簽設置為id, 這樣確保了每個頁面中擁有唯一持有該樣式的布局容器, 也方便其css和js選擇器的使用. 當然, 你也可以使用一個唯一的類名替代id.

模塊

//module.css

//module1
.module1 > h2 {
    padding: 5px;
}

.module1 span {
    padding: 5px;
}

//module2
.module2 > h2 {
    padding: 10px;
}

.module2 span {
    padding: 10px;
}

模塊是指頁面中可以多帶帶分離并提取出來復用的部分, 例如導航條, 側邊欄, 對話框或一些widget等. 所以, 模塊禁止使用id, 而應該采用類名的方式.

狀態


    
        
            There is an error!
        
        Search

State 負責定義元素不同的狀態下，所呈現的樣式. 上面的一段代碼中,已is-開頭的就是表示狀態的類名, is-collapsed, is-error等類名不會多帶帶使用, 而是和前面的布局和模塊一起使用. 下面的代碼, 就是在tab欄模塊和狀態一起使用:

//state.css
.tab {
    background-color: purple;
    color: white;
}

.is-tab-active {
    background-color: white;
    color: black;
}

主題

// module-name.css
.mod {
    border: 1px solid;
}

//theme.css
.mod {
    border-color: blue;
}

這里的主題理解為皮膚更加合適, 已上面的代碼為例, 在module-name.css中定義了邊框除顏色之外的樣式, 在theme.css文件中定義了該邊框的顏色, 這樣的好處就是, 如果定義其他顏色的類名去覆蓋這些有顏色的樣式, 那么就可以通過類名去切換皮膚的顏色. 達到更換主題的效果.

更多關于SMACSS的方法, 請參考: https://smacss.com/book

3.BEM方法(Block Element Modifier 塊元素修飾符)

BEM是由Yandex提出的給一個CSS命名方法, 該方法要求使用一個CSS類名, 盡可能使用以下三者組成:

塊名: 所屬組件的名稱

元素: 元素在塊里面的名稱

修飾符: 任何與塊或元素相關聯的的修飾符

塊名
這里的塊名很多初學者會以為是inline-block中的塊, 其實這里的塊名指的是一個獨立的模塊或組件. 例如一個

可以用做一個模塊,

中的

可以用作一個模塊. 模塊之間是可以相互嵌套的. 上面的示例代碼中 ,toggle就是一個獨立的模塊

元素
元素是指無法用在其他塊名中的部分, 在BEM方法中, 元素跟在塊名后面使用__連接, 之所以約定使用雙下劃線是因為方便在塊名中使用單下劃線命名. 上面示例代碼中的toggle__control, toggle__title就是塊名+元素的命名方式.

修飾符
修飾符與SMACSS中的狀態類似, 在BEM方法中, 修飾符需要跟在元素后面使用--連接. 有的人會覺得這種寫法會使得代碼冗余, SMACSS使用is-active同樣可以表示同樣的作用, 為什么上面的代碼要使用toggle__details--active呢? 其實, 如果多帶帶看open和is-active這兩個名字, 我們并不知道它們的含義是什么, 但是當看到一個toggle__details--active的類名, 我們就知道它是表示: 這個元素的名稱是details, 位置在toggle組件里, 狀態為active.

(三) JavaScript

1.框架的選擇
這里我不想陷入Angular, React, Vue三大框架之爭. 我是一個Vue的開發者, 我深知MVVM框架給我們開發者帶了極大的便利, 不用再以jQuery不停的操作DOM的形式去開發, 而是只關注數據的改變, 以數據去驅動DOM的改變. 這能夠把更多的時間放入到業務邏輯的處理上.

就目前三大框架的生態系統來看, 大部分業務三大框架實現起來其實并沒有什么大的差別,框架的選擇更多的取決于項目中團隊人員的偏好和學習成本. 比如Vue的學習成本就相比于Angular要小太多. 雖然我是一個Vue的開發者, 但我不得不說在React中使用JSX的語法讓寫代碼變得很愉快.

這里我還想說的是:  其實你很可能不需要任何的框架!

有很多成功的網站只不過是采用了一些模板語法, 加上少量手動創建的Sass文件和幾十個Javascript函數創建而成. 當項目的規模足夠龐大, 需要犧牲代碼文件體積大小去換取框架所帶來的開發效率的提高時, 再考慮評估引入哪類JS框架和UI框架, 否則不要輕易放棄精簡方案.

2.選擇一套JavaScript代碼規范

每個人寫代碼的方式是不同的, 有些人可能喜歡用==, 但有的喜歡用===; 有的人可能習慣給每個變量使用var去聲明, 但有的喜歡使用一個var加逗號運算符去同時聲明多個變量. 這些代碼習慣可能并不會對程序運行造成影響. 但是在大型業務中, 面臨多個開發者共同開發時, 如果沒有一套代碼規范, 那么就會出現代碼難以維護, 難以閱讀的情況. 為了讓新加入的團隊成員也能夠快速熟悉相關的代碼, 并且讓代碼可以維護, 一套Javascript代碼規范不論是開發大型項目和小型項目, 都是必須的.

如果公司沒有代碼定制自己的代碼規范, 可以使用大公司所制定的代碼規范, 這里向大家推薦以下三個代碼規范:

Airbnb JavaScript Style Guide

Airbnb的Javascript號稱是"最合理的編寫JavaScript代碼的方式", 也是互聯網中最流行的JavaScript代碼規范, 它在Github上足有6萬star, 幾乎覆蓋了JavaScript的每一項語言特性.

Google JavaScript Style Guide

Google的JavaScript代碼規范相比于Airbnb代碼規范更加全面, 它不僅從代碼美感,性能角度和代碼特性對編寫Js代碼進行了規范, 同時也對Js的命名, 導入方式, Js代碼文檔進行了規范. 在Introduction中, Google團隊表明, 在項目中全部使用了Google的Js規范, 才能被叫做Google Style的代碼!

JavaScript Standard Style Guide

standard JS是一個功能強大的 JavaScript 代碼規范, 自帶 linter 和自動代碼糾正, 無需配置, 自動格式化代碼. 可以在編碼早期就發現代碼中的低級錯誤. 這個代碼規范被很多知名公司所采用, 比如 NPM、GitHub、mongoDB 等.

下面截取部分airbnb的ES5規范, 來對比一下使用了規范和未使用規范的區別:

數組

使用直接量創建數組

//bad
var items = new Array()

//good
var items = [];

拷貝數組時, 使用slice

var len = items.length;
var itemsCopy = [];
var i;

// bad
for (i = 0; i < len; i++) {
  itemsCopy[i] = items[i];
}

// good
itemsCopy = items.slice();

使用slice將類數組對象轉換成數組

function trigger() {
  var args = Array.prototype.slice.call(arguments);
}

字符串

使用單引號""包裹字符串

//bad 
var name = "LITANGHUI"

//good
var name = "LITANGHUI"

程序化生成的字符串使用join 連接而不是使用連接符。尤其是 IE 下

var items;
var messages;
var length;
var i;

messages = [{
  state: "success",
  message: "This one worked."
}, {
  state: "success",
  message: "This one worked as well."
}, {
  state: "error",
  message: "This one did not work."
}];

length = messages.length;

// bad
function inbox(messages) {
  items = "";

  for (i = 0; i < length; i++) {
    items += "" + messages[i].message + "";
  }

  return items + "";
}

// good
function inbox(messages) {
  items = [];

  for (i = 0; i < length; i++) {
    // use direct assignment in this case because we"re micro-optimizing.
    items[i] = "" + messages[i].message + "";
  }

  return "" + items.join("") + "";
}

比較運算符 & 等號

優先使用 === 和 !== 而不是 == 和 !=

使用快捷方式

// bad
if (name !== "") {
  // ...stuff...
}

// good
if (name) {
  // ...stuff...
}

// bad
if (collection.length > 0) {
  // ...stuff...
}

// good
if (collection.length) {
  // ...stuff...
}

空白

使用 2 個空格作為縮進

// bad
function () {
????var name;
}

// bad
function () {
?var name;
}

// good
function () {
??var name;
}

大括號前放一個空格

// bad
function test(){
  console.log("test");
}

// good
function test() {
  console.log("test");
}

// bad
dog.set("attr",{
  age: "1 year",
  breed: "Bernese Mountain Dog"
});

// good
dog.set("attr", {
  age: "1 year",
  breed: "Bernese Mountain Dog"
});

使用空格把運算符隔開

// bad
var x=y+5;

// good
var x = y + 5;

以上內容就是前端架構四大核心中的代碼核心部分, 接下來的幾篇文章會分別介紹其他三個核心, 分別是流程, 測試和文檔.

友情鏈接

前端進階之路: 前端架構設計(2)-流程核心

GPU云服務器云服務器前端架構設計前端開發前端設計前端設計前端開發前端開發和前端設計

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/51601.html

前端進階之路: 前端架構設計(3) - 測試核心

摘要：而測試驅動開發技術并不只是單純的測試工作。需求向來就是軟件開發過程中感覺最不好明確描述易變的東西。這里說的需求不只是指用戶的需求，還包括對代碼可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備受重視, 早在開發工作啟動之前, 他們就被邀請加入到項目中, 而且他們會跟客戶討論即將建成的平臺的...

Karuru 2019-08-01 18:16 評論0 收藏0
前端進階之路: 前端架構設計(3) - 測試核心

摘要：而測試驅動開發技術并不只是單純的測試工作。需求向來就是軟件開發過程中感覺最不好明確描述易變的東西。這里說的需求不只是指用戶的需求，還包括對代碼可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備受重視, 早在開發工作啟動之前, 他們就被邀請加入到項目中, 而且他們會跟客戶討論即將建成的平臺的...

宋華 2019-08-22 11:22 評論0 收藏0
前端進階之路: 前端架構設計(1)-代碼核心

摘要：可能很多人和我一樣首次聽到前端架構這個詞第一反應是前端還有架構這一說呢在后端開發領域系統規劃和可擴展性非常關鍵因此架構師備受重視早在開發工作啟動之前他們就被邀請加入到項目中而且他們會跟客戶討論即將建成的平臺的架構要求使用還什么技術棧內容類型可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備...

baishancloud 2019-08-22 11:18 評論0 收藏0