做前端工作一段时间了,也写了不少的项目。但是突然好像快要失去了兴趣。美工、后台、项目经理、测试等人员多层夹击。美工说就这么设计,你就得完全按着来。后台说这个需求做不了,得那样做,于是已经做好的页面推倒重来。测试说,这样做更符合大众习惯,这样的流程才正确。于是,一遍遍地改,没有话语权。就这样兴趣被慢慢磨灭着...。直到我看到了这本书。兴趣的小火苗又开始突突的窜了起来.
这本书把前端结构师,比喻成建筑工程师。都在一层层的搭建着自己的产品。这个产品有着完善的可遵循的体系设计、有着流畅运转的工作规划、有着持续优化的监督跟进。想象一下,我们亲手编码(绘制)的产品,大家都能看到,能为大家的生活带来些许的变化,甚至为之惊叹,那将是件多么美好的事情。
那什么是前端架构呢?
本书作者定义为:前端架构是一系列工具和流程的集合,旨在提升前端代码的质量,并实现高效、可持续的工作流。
作为一名前端架构师,你的工作是不断地探索和评估新的技术、平台、方法和框架。世界上没有一刀切式的解决方案,而前端架构师的使命正是将项目的需求与前端开发的实际情况相结合。
那怎么来实现一个好的前端架构呢?
本书作者认为应围绕四个核心来工作:
(1)代码
(2)流程
(3)测试
(4)文档
一、代码
作为前端架构师,你需要评估标记产生的过程。你对内容的顺序、使用的元素和 CSS 类名有多大的控制权?这些元素在将来改动起来会有多大难度?模板是否易用,或者是否只有后端开发人员才能更改?甚至,你的标记全是基于模板系统的吗?你可以通过系统做出更改,还是需要手动处理?通过回答这些问题,来不断优化自己的代码。同时要意识到我们的工作不是单纯地实现,某个页面,而是设计整个系统。
通过BEM原则模块化一个简单的导航,代码如下:
<nav class="nav">
<ul class="nav__container">
<li class="nav__item">
<a href="/products" class="nav__link">
<ul class="nav__container--secondary">
<li class="nav__item--secondary">
<a href="/socks" class="nav__link--secondary">
1、模块化CSS有几种方法:
(1)OOCSS(Object-Oriented CSS,面向对象的 CSS)方法:
OOCSS(http://oocss.org/)有两个主要的原则:分离结构和外观,以及分离容器和内容。
<div class="toggle simple">
<div class="toggle-control open">
<h1 class="toggle-title">Title 1</h1>
</div>
<div class="toggle-details open"> ... </div>
...
</div>
(2)SMACSS(Scalable and Modular Architecture for CSS,模块化架构的可扩展 CSS)方法
<div class="toggle toggle-simple">
<div class="toggle-control is-active">
<h2 class="toggle-title">Title 1</h2>
</div>
<div class="toggle-details is-active">
...
</div>
...
</dl>
(3)BEM(Block Element Modifier,块元素修饰符)方法
包括块名、元素和修饰符。BEM 使用非常简洁的约定来创建 CSS 类名,而这些字符串可能会相当长。元素名加在双下划线后(例如 toggle__details),修饰符加在双横杠后(如 toggle__details--active)。这里的 details 是元素,active 是修饰符,这个约定使得 CSS 类名非常清晰。使用双横杠是为了避免块名被混淆为修饰符。
<div class="toggle toggle--simple">
<div class="toggle__control toggle__control--active">
<h2 class="toggle__title">Title 1</h2>
</div>
<div class="toggle__details toggle__details--active">
</div>
</dl>
2、css采取原则:
(1)分离容器和内容
(2)区分布局与组件的角色和职责
(3)在标记上使用单一、扁平的选择器
(4)使用其他原则,比如单一职责原则、单一样式来源、内容修饰符
单一职责原则:规定你创建的所有东西必须有单一的、高度聚焦的理由。你应用到某个选择器里的样式应该是为了单一目的而创建的,并且能够很好地实现这个目标。
单一样式来源:在一个模块化设计中,任何组件的设计必须由组件本身决定,而不应该被它的父类名限制。
组件修饰符:让你能够定义一个组件在多个不同情况下的多种变化。
3、js的原则
(1)保持代码整洁:使用JS Hint
(2)创造可复用的函数
二、流程
(1)工作流
(2)任务处理流
三、测试
(1)单元测试
(2)性能测试
(3)视觉还原测试
四、文档
(1)样式文档
使用SassDoc来自动化生成sass文档。
(2)图形库
使用Brad Frost 的原子设计原则(http://patternlab.io)来生成图形库
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。