《前端架构设计》读后感

在读了这本书后对前端架构也有了进一步思考。

书中提到

前端架构围绕四个核心：代码、流程、测试、文档

围绕这四个核心及项目经验，我作了以下总结，并结合书中的内容给出相应的解决方案

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等