读《前端架构设计》-前端架构概况
前言
还记得这个活动吗？【活动】征集《前端架构设计》书评。这篇读后感来自北京 @徐进的分享。
正文从这开始～
这断时间在读《前端架构设计》这本书，虽未读完，但是已有不少收获。
这本书的作者结合自己在Red Hat公司的项目实战经历，探讨了前端架构原则和前端架构的核心内容，包括工作流程、测试流程和文档记录，以及作为前端架构师所要承担的具体开发工作，包括HTML、JavaScript和CSS等。这本书并不是在将某个技术细节，而是从宏观的角度分析了当下最高效的前端开发的工作流，以及代码，测试，文档的规范。反之，这应该也是这本书的一个小缺点，内容会给人一种蜻蜓点水的感觉。
但作为前端新人的我，很喜欢这本书，它能在前端领域为我指明正确的、高效的、规范的发展道路。如果任按照老旧的开发流程，尽管小的系统尚可应付，但是随着项目复杂性的增长，老旧的流程绝不是长久之计，但如果能够把前端开发当成一个值得做出战略规划和有投资价值的关键元素，那么我们一定会用另一种态度与谨慎来对待了吧。
什么是前端架构？
前端架构是一系列工具和流程的集合，旨在提高前端代码的质量，并实现高效、可持续的工作流。
书中是这样给出前端架构的定义的。最近几年，前端才开始蓬勃的发展，这个职业开始逐渐的被人认可，再早几年，人们对web前端似乎没有什么要求，只要能用就行，对于性能，人性化的交互也没有要求，前端似乎成为了低端的代名词，更少有人在前端领域深入钻研，建立一套完善的体系。
在当前蓬勃发展的前端领域，作为一个新晋的一线开发人员，在做项目中也确实会遇到一些问题，比如：该选用那一个前端框架，Vue、Angular亦或是React？如何更高效的和后端的开发人员整合，而不是等他们开发完了在整合，且整合中更会遇到很多问题？如何更方便的对页面进行调试，既能热更新，也能很便捷的调试移动端的界面？如果团队中没有人擅长于前端的架构，恐怕很可能又会沦为老旧的开发流程，生产出大片无用代码且效率极为低下。而在团队中承担此职责的人，被称为前端架构师。
架构更像是一种管理，一种对于代码、流程和规范的管理，对于大型Web项目，前端架构师和软件架构师同样不可或缺。软件架构师的职责是要保证项目中每一步都在总体架构的指导下进行，而不会随机决定；对于前端架构师也是一样，他们是项目的决策者，相比于具体编写的代码，他们更关注于开发工具和优化流程。
前端架构师职责：
体系设计——清晰描绘产品和代码的最终形态
工作规划——制定完整开发工作流
监督跟进——保证项目高效率完成
前端架构的核心？
前端架构师的成长之路不是一蹴而就的，而是需要保持不间断的学习状态。这种状态决定了我们的水平和价值。对于前端开发领域的广泛涉猎使我们能够很快上手新技术和方法论。
不能再同意作者文中所说的这句话了，我认为不仅是前端架构师，作为一名学生，工程师，等任何职业都应时刻保持这种持续学习的状态，有一本书叫做《168 hours》，书中介绍了关于时间利用的问题，一周7天，168小时，除去工作和睡眠和必要的时间消耗，其实属于我们的可利用的时间还有很多，并不像我们想象的那么忙，若我们能冷静下来思考时间，并将这些时间利用起来扩充自己的知识面，提高自己各方面的技能，若能有这种自我驱动力，我觉得不久就能成为项目中的前端架构人才。跑远了，拉回来。。
而前端架构的核心也是这本书通篇所讲述的内容到底是什么呢？作者将其概括为四个，代码、流程、测试、文档。
代码解决的问题是如何实现系统架构中的HTML、CSS和JavaScript。关于代码，有一句话我记得特别清楚：”代码是给人看的，机器只是顺便执行了一下而已。“从我知道这句话以后，就时时的提醒自己，自己所写的代码对待下一个可能接手我代码的人有没有很友善。有没有写好代码的注释？有没有将代码的格式缩进统一，使代码美观？有没有将函数，类，变量的命名语义化？函数有没有遵守单一职责原则？有没有尽量降低组件之间的耦合？有没有提高代码的可复用性等。这些也是文中作者的观点，我想能时刻提醒自己写出高质量的代码，定是写出高质量代码的必要条件。
流程解决的是在构建高效并且防止出错的工作流中所需要的工具和流程。我认为流程是提高项目开发效率的重要途径，流程包含在项目开发过程的各个环节，若能极大的优化项目开发的流程，必然会使项目有一个乐观的结果。当然，在优化前端开发流程的过程中，一定会遇到各种优秀的工具，比如git，gulp等。我觉得这些工具，如果没有使用过，有机会尝试一下还是极好的。
流程核心的意义在于清晰地定义前端代码从开发人员的脑海到用户浏览器所需经历的各个步骤。
测试也是项目中最重要的一步，能够为网站搭建稳固基础。测试也是自己目前最弱的一块，一方面由于在学校做项目，几乎所有的项目都是一两人的小组完成，且最终交付时的要求不高，另一方面也是自己还没有引起足够的重视。但是这万万是不对的，新代码给系统带来的问题涉及方方面面，若不能及时测试，及时反馈自己的代码，于客户、于自己都必然是百害无一利吧。
书中在我们为应用程序规划测试时，提供了以下四条建议。
测试用例应该在建站的同时，甚至在建站之前就需要开始编写。
测试代码是真实的代码，应该一起或立即提交到系统代码库中。
必须在所有的测试用例都通过后，才能把代码合并到主干中。
在主干上运行测试工具，结果应该都为通过。
文档能够规划好系统设计的蓝图。身边很多小伙伴都很厌倦写文档，我也不例外，每次接到导师布置写文档的任务都是一脸懵逼。但作者说的一句话我很为挺有用：”往往当团队中重要成员离开时，才会意识到文档的重要性，到那时大家不得不停下手头的工作，优先编写所有的文档。”想想这句话说的真对，平常我们会觉得好好的写文档干嘛，浪费时间，还不如撸一段代码来的痛快，但是当我们忘记一些东西的时候，一定会想起来去查需求文档，接口文档吧。要调整自己的状态，正确对待文档，因为它很重要。
能够将头脑中这些看似常识的信息写到文档上并非易事，但我们因为没有文档而浪费的时间往往比写文档花费的时间更多。俗话说，”好记性不如烂笔头嘛”
我认为这本书是不错的，它为我指明了方向，帮我认识到自己的不足，以及今后需要继续完善和努力的地方。额，不过这本书是讲前端架构的，并不是提建议哈。
不过，若真能掌握这四大核心，再加上知识的广度，未来说不定可以做架构呢，哈哈
关于本文
作者：@ 徐 进
原文：http://xujin.pro/2017-05-18-frontend-architecture-overview.html