《前端架构设计》读后感
在读了这本书后对前端架构也有了进一步思考。
书中提到
前端架构围绕四个核心：代码、流程、测试、文档
围绕这四个核心及项目经验，我做了如下总结，并结合书中的内容给出相应的解决方案
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等
