什么是前端架构？

介绍：当下，对于从事前端开发人员来讲，编写前端样式不仅是要当做事前来考虑的事情，而且还要先进行网站设计方案的讨论，然后才开发各种功能，这样做是避免一些定性的div、列表、或链接等后期难以修改造成的窘境。

文章目录

前言

前端架构含义：是指一系列工具和流程的集合，旨在提升前端代码的质量，并实现高效、可持续的工作流。

就我理解而言，前端编程好似作文一般，写作之前我们肯定是先思考一下文章的思路，模板排布等，如果没有逻辑可言，想写便写，宛如流水账，得分也不会高到哪去，前端也一样。本文一方面是介绍前端架构的重要性，浅解前端架构的深意；一方面也是勉励自己未来在前端开发方面少走弯路，不足之处还请见谅。

一、HTML设计

当我们开始网站构建时，面临的第一个挑战就是标记的规范化，如果初始内容标记做的不好，后期就要写很多不必要的CSS和JavaScript来弥补，造成后期的时间困扰和维护代码的麻烦。

而过去，我们的标记曾细分俩大阵营：程序式和静态式。它们编写的代码如下：

<divid="header"class="clearfix"><divid="header-screen"class="clearfix"><divid="header-inner"class="container-12 clearfix"><divid="nav-header"role="navigation"><divclass="region region-navigation"><divclass="block block-system block-menu"><divclass="block-inner"><divclass="content"><ulclass="menu"><liclass="first leaf"><ahref="/start">Get Started</a>

程序式的html如上所示，显而易见的是普遍代码没有控制标记，这就造成了复杂的渲染和标记源码打乱在一起，这不仅意味着更新标记的困难，而且给后端开发人员实现前后端合并造成了极大的困扰。毋庸置疑，这种标记之前的乱炖的确可以帮助我们实现静态网页的搭建，但随着我们对网页需求的提升，这种程序式的标记显然不能满足我们的要求。

<header><section><nav><div><ul><li><ahref="/products">Products</a><ul><li><ahref="/socks">Socks</a>

静态式的html如上所示，诚然，保持简介追求“语义化”的标记是我们的首选，但过于简洁的标记或导致样式会自动继承，如果项目规模较小还好，一旦规模较大会导致我们书写CSS时苦不堪言。如下请看

header > section > nav > div > ul > li > a{color: white;}header > section > nav > div > ul > li > ul > li > a{color: blue;}

为了更好的实现标记的可控化，模块化标记是最好的选择，它可以给你带来理想的灵活性和必要的自动化

<navclass="nav"><ulclass="nav__container"><liclass="nav__item"><ahref="/products"class="nav__link"><ulclass="nav__container--secondary"><liclass="nav__item--secondary"><ahref="/socks"class="nav__link--secondary">

咋一看和程序式没啥区别，但它的标记却恰到好处，这种标记是根据元素而添加相应类名，不是依赖那些为了样式标签而存在的CSS类名，前者重复使用更清晰了然，后者重复使用只能说，自己也看不懂自己写的啥。

二、CSS设计

单一职责原则：规定创建的所有东西必须有单一的、高度聚焦的。应用到某个选择器里的样式应该是为了单一目的而创建的，并且能够很好地实现这个目标。

<div class="calendar">
     <h2 class="calendar-header">This Is a Calendar Header</h2> 
</div> 
<div class="blog"> 
     <h2 class="blog-header">This Is a Blog Header</h2> 
</div> 
.calendar-header{color: red;font-size: 2em;}.blog-header{color: red;font-size: 2.4em;}

这种方法可能会导致一些代码重复(红色字体定义了两次)，但是带来的好处也超过代码重复的任何坏处。这里多出来的代码对网页大小的增加而言微不足道，如果整个项目强制执行单一责任原则，就能够确保在进一步改变时，我们可以毫不费力地完成，并且也不需要回顾之前的代码。

单一样式来源：每个 CSS 类名被创建为单一用途，而且每个标签的样式也只有单一的来源。

<divclass="blog"><h2class="blog-header">This Is a Blog Header</h2> 
 ... 
<divclass="blog"><h2class="blog-header">This Is a Blog Header</h2> 
 ... 
 <divclass="calendar"><h2class="calendar-header">This Is a Calendar Header</h2></div></div> 
/* calendar.css */ 
.calendar-header { 
    color: red; 
    font-size: 2em; 
} 
.blog .calendar-header { 
    font-size: 1.6em; 
} 
/* blog.css */ 
.blog-header { 
    color: red; 
    font-size: 2.4em; 
}

这种方法可以让我们知道所用可能变动的情况，并且能让我们为每个变动的情况创建适当的测试覆盖

组件修饰符：能够定义一个组件在多个不同情况下的多种变化。

<divclass="blog"><h2class="blog-header">This Is a Blog Header</h2> 
 ... 
 <divclass="calendar calendar--nested"><h2class="calendar-header">This Is a Calendar Header</h2></div></div> 
/* calendar.css */ 
.calendar-header { 
    color: red; 
    font-size: 2em; 
} 
.calendar--nested .calendar-header { 
    font-size: 1.6em; 
} 
/* blog.css */ 
.blog-header { 
    color: red; 
    font-size: 2.4em; 
}

这种方法把修改使用到任何地方，保证了所有组件的变动都在一个文件里，能用到任何需要的地方，不依赖于不确定的父节点 CSS 类名。

三、JavaScript设计

JavaScript是一种脚本语言，与HTML和CSS不同，忘记闭合一个 HTML 标签或者写了无效的 CSS，最坏的情况不过是页面上出现了一些小缺陷。如果你在 JavaScript 代码里添加了太多的逗号或者忘记闭合大括号，整个网站都有可能崩溃。

保持代码整洁：限制代码嵌套深度、限制函数的参数数量、避免函数重复定义、避免变量创建后未使用。

创造重复使用函数：

$.fn.log_text_on_click=function(){this.on('click',function(){ 
     console.log($(this).html());});returnthis;}; 
$.fn.add_background=function(color){this.css('background-color', color);returnthis;}$('.red-alert').add_background("red").log_text_on_click();$('.yellow-alert').add_background("yellow").log_text_on_click();

• 如果需要创建新的 .green-alert 类名，只需要修改定义好的 add_background() 和 log_text_on_click 函数
• 如果需要将console.log($(this).html())中.html()改成.text()，只需要在一个位置修改，而不是多个位置
• 可以在项目里的很多地方复用这两个函数

四、工作流程

需求分析：工作一般是从收集需求开始的，只有这样我们才能够定义出项目内容和衡量项目成败的标准。

原型设计：提供了一个讨论和反馈的公共空间，它把丰满的想法实现在桌面和手机浏览器中。在原型中，想法可以成型、摒弃、重拾、打磨。一旦开发人员和产品负责人对这个原型满意，那么它就可以被采纳了。

程序开发：需求可以实现得更加容易和顺利，拥有了实现这个设计所需要的全部标记。开发人员的工作就是收集和处理来自数据库的数据，然后把它们放置到对应的标记上。开发人员几乎不需要给标记添加额外的类，或者去掉一个容器 div，或者调整代码的顺序，因为所有的迭代和测试工作都在原型阶段完成了。

性能测试：为了避免不流畅的用户体验，而糟糕的网站性能正是导致用户体验不流畅的主要原因之一。因此，性能测试虽然不是针对系统或视觉问题的测试，却也是测试库的重要组成部分。

五、总结

随着对前端架构的理解越来越深入，从项目开始到现在所达到的高度，所需的时间会越来越短，而且所经历的迭代也会越来越少。我们的职责是认清目前的优势和劣势，并预测可能出现的机遇和问题。经历过后方能预测，曾经低估才能理解。我们所能展示的最大能力就是对前端开发过程的深刻理解。