del

极客时间专栏/geek/重学前端/模块四：前端综合应用/前端架构：前端架构有哪些核心问题？.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="前端架构：前端架构有哪些核心问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fd/02/fd0e444fd93f90025dc9a19886b25202.mp3"></audio>
+
+你好，我是winter，今天我们来谈谈架构。
+
+在传统桌面软件开发中，架构师是一种通过设计架构保证团队能够良好分工和有序工作的岗位。
+
+在工程领域，我们凡是要做点什么事儿，都会有明确的目的性，这个目的性，一定是为了完成生产服务业务的。
+
+为什么桌面软件开发需要架构师和架构设计呢？因为桌面软件开发具有高度的复杂性，如果没有架构，就没法分解成互相耦合低的模块来分工。
+
+所以一般来说，架构是为了分工而存在的。但是到了前端领域，这个问题是否还存在呢？答案是，不存在。
+
+前端是个天然按照页面解耦的技术，在多页面架构中，页面的复杂度大约刚好适合一个人的工作量。（所以，我们的结论是，前端根本不需要架构设计。当然，我这句话是开玩笑的。）
+
+前端不存在分工问题，但是在多人协同时，仍然要解决质量和效率的问题，这就需要组件化了。除此之外还有前端特有的兼容性问题，也是需要从架构的角度去解决的。
+
+对于一些追求极致的团队来说，会挑战“单页面应用”，通过单页面应用来提升用户体验，单页面应用的升级版本是谷歌提出的PWA，PWA既是业务方案也是技术方案，在技术层面，它近乎苛刻地规定了网页的各方面的体验标准。
+
+前端领域还有一个特有的生态：框架，第一代前端框架（如jQuery, PrototypeJS）重点解决了兼容问题和API的易用性问题，在现代浏览器普及之后，这些问题逐渐变得不存在或者不重要，所以第二代前端框架（如Vue，Angular，React）重点解决了组件化问题。选择合适的框架，可以节约架构的成本，还能够享受社区资源。
+
+本节课，我会围绕前端架构的几个核心问题，为你介绍前端架构工作。
+
+首先我们来讲讲组件化。
+
+## 组件化
+
+组件化讲起来是个非常简单的概念，前端主要的开发工作是UI开发，而把UI上的各种元素分解成组件，规定组件的标准，实现组件运行的环境就是组件化了。
+
+现行的组件化方案，目前有五种主流选择：
+
+- Web Component；
+- Vue；
+- React；
+- Angular；
+- 自研。
+
+Web Component 是W3C推行的规范，理论上是未来的选项；但是实际上这份标准的状态堪忧，Shadow DOM 的设计比较复杂，一般的前端掌握起来都比较困难。
+
+此外，CSS也比较难以应用，需要依靠CSS Houdini。目前来说，我还没有看到那个前端团队实际在使用Web Component作为组件化方案。当然，它的优势也非常明显：不需要任何额外的运行时支持，就能在现代浏览器环境运行，也可以跟HTML无缝结合。
+
+Vue 是目前最受欢迎的框架（从github star来看），由华人程序员尤小右开发和维护。它有两个主要特点，一个是比较符合原本的JavaScript/CSS/HTML书写习惯；另一个是它绑定了MVVM模式，直接确定了UI架构，通过DSL的支持，数据交互非常简洁。
+
+React 是Facebook推行的新一代Web框架。它利用JSX模式，把HTML、CSS和JavaScript都放进了js文件中，对于不喜欢CSS和HTML的前端工程师来说，是很理想的。它还可以迁移到React Native，直接编写简单的客户端应用。
+
+Angular 是Google推出的Web框架，它是比较标准的MVVM模式。Angular曾经因为大版本兼容性而饱受诟病，目前它的核心竞争力是与TypeScript结合得较好。
+
+上面是我对几种方案的简单介绍。但是实际上，我们做技术选型时的主要依据是团队的现状，开发移动端还是桌面端、是否跟Native结合、团队成员的技能分布都是需要考虑的因素，这些框架本身的特点，目前我认为仅仅是一种偏好选项，而不是关键因素。
+
+## 兼容性和适配性
+
+前端开发的特有问题就是兼容性，到了移动时代，需要面对不同的机型，我们又需要解决适配性问题。
+
+兼容性问题到2011年左右都是前端的主旋律，但是在之后，随着现代浏览器的逐渐普及，兼容性问题逐渐减小，所以我们这里就不多谈兼容性问题了。
+
+适配问题主要适配的是屏幕的三个要素。
+
+- 单位英寸像素数（Pixel Per Inch，PPI）：现实世界的一英寸内像素数，决定了屏幕的显示质量。
+- 设备像素比率（Device Pixel Ratio，DPR）：物理像素与逻辑像素（px）的对应关系。
+- 分辨率（Resolution）：屏幕区域的宽高所占像素数。
+
+在当前环境下，分辨率适配可以使用vw单位解决，DPR适配则需要用到CSS的viewport规则来控制缩放比例解决，而PPI主要影响的是文字，可以采用media规则来适配。
+
+## 单页应用
+
+前文已经讲过，前端架构的解耦问题不大，因为页面是天然解耦的，但是，大家都知道，浏览器加载HTML时是会有白屏过程的，对追求极致体验的团队来说，希望能够进一步提升体验，于是就有了“单页应用（SPA）”的概念。
+
+单页应用是把多个页面的内容实现在同一个实际页面内的技术，因为失去了页面的天然解耦，所以就要解决耦合问题。也就是说，我们要在一个“物理页面”内，通过架构设计来实现若干个“逻辑页面”。
+
+逻辑页面应该做到独立开发和独立发布，一种思路是，每个逻辑页面一个js，用一个SPA框架加载js文件。
+
+从交互的角度，这并不困难，但是，这里还有一个隐性需求：保持前进后退历史。
+
+一般来说，前进后退历史使用URL的Hash部分来控制，但是onhashchange事件并没有提供前进或者后退信息，目前还没有完美的解决方案，只能牺牲一部分体验。实现单页应用的逻辑页面发布需要改造发布系统，在工程上，这也是一个比较大的挑战。
+
+## 扩展前端新边界
+
+除了解决现实问题，我认为前端架构的职责还包括扩展前端的边界，所以前端架构还包含了很多Native开发任务：如客户端和前端结合的方案 Weex 和 React Native；如前端和图形学结合的方案 GCanvas；如前端的3D框架Three.js，这些都是试图用架构的手段赋予前端新的能力的尝试。
+
+这些具体的尝试涉及很多领域知识，我这里就不做详细介绍了，但是如果你成为了一个前端架构师，我希望你也把“拓展前端边界”当做团队的核心目标之一。
+
+## 总结
+
+今天我从宏观的角度介绍了前端架构相关的知识，我重点介绍了“组件化”“适配性”“单页应用”三个前端架构需要解决的核心问题，组件化在社区有很多现成的方案，我们需要做的主要工作是框架选型。适配性需要用到CSS的几种特性：vw单位、viewport规则和media规则，单页应用重点是逻辑页面解耦、独立开发和发布和保持前进后退历史。
+
+最后留一个思考问题，你所在的团队有前端架构师吗？如果有的话，他的工作职责是什么？
+
+

极客时间专栏/geek/重学前端/模块四：前端综合应用/工具链：什么样的工具链才能提升团队效率？.md

@@ -0,0 +1,113 @@
+<audio id="audio" title="工具链：什么样的工具链才能提升团队效率？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/81/78/81b7588e832303b92e3c3e3f7372ad78.mp3"></audio>
+
+你好，我是winter。今天我们的主题是工具。
+
+古语云：“工欲善其事，必先利其器”，程序员群体对工具的爱好和重视是一个悠久的传统。简单趁手的工具是程序员开发的好帮手。
+
+但是在工程方面，工具不仅仅是简单的“趁手”即可，假如一个团队人人都自己发明几个小工具，那么后果将会是灾难性的：同一个团队的同学无法互相配合写代码，一旦有人离职，可能某一个项目就永远无法跑起来了。
+
+所以我们今天从工程的角度谈一谈工具体系的规划。
+
+## 工具总论
+
+跟性能不同，工具体系并非业务结果，所以我们没法用简单的数据指标来衡量工具，它的结果更多程度是一种开发体验：帮助技术团队内的同学提升效率和体验。
+
+作为工程体系，我们考虑工具的时候同样要遵循基本规则：现状与指标、方案、实施、结果和监控。
+
+不过，对工具而言，指标和结果都是一种“软性指标”，也就是团队的开发效率和开发体验。这里我不太推荐把开发效率和开发体验过度数据化，我的经验是：开发效率提升n倍永远是一种臆想或者主观论断。
+
+## 工具体系的目标
+
+前面已经讲到，工具是为技术团队本身服务的工程体系，那么，工具的目标是什么呢？其实每一种工具的出现，必然都有一个非常具体的目标，比如npm帮助我们进行包管理，Yeoman帮助我们初始化项目模板。
+
+但是这些目标是工具的目标，不是工具体系的目标。我们做一个假设，**假如你是一个前端团队的工具体系负责人，现在要你来规划团队的工具体系，你会怎么做呢？**
+
+如果你到社区找了一大堆工具，并且把它们要解决的问题都罗列出来，作为工具体系的目标，那就完全走上了错误的道路。
+
+实际上，在考虑具体的工具之前，我们应该解决工具体系的“元问题”，即：我们对工具本身的要求是什么？
+
+**考虑到工程行为都是团队合作，我们对工具最基本的要求就是：版本一致。**
+
+只有整个团队的工具版本一致，至少要做到避免大版本差异，才能做到互相接手代码时，团队成员能够正确的使用工具开发。
+
+**工具体系的另一个重要需求是：避免冲突**，一些工具可能互相没有干扰，比如Yeoman和gulp，有一些工具则由社区设计了配合方案，比如webpack和babel，有一些工具，则存在着根本性冲突，如gulp和grunt。
+
+所以，在谈及具体问题之前，我们必须要有这两个要求的解决方案。**这就需要引入一个新的概念：工具链。**
+
+工具链是一系列互相配合的工具，能够协作完成开发任务（注：工具链这个词最早是由C/C++程序员引入的概念，一般包含编译、链接、调试等工具）。
+
+下面我们就来谈谈工具链的设计。
+
+## 工具体系的设计
+
+要想设计一个工具链，首先我们需要整理一下，前端开发大约要做哪些事，下面是我的答案：
+
+- 初始化项目；
+- 运行和调试；
+- 测试（单元测试）；
+- 发布。
+
+那么，一个前端项目的工具链，大约就会包含这些功能。一个典型的社区项目工具链可能就类似下面这样：
+
+- Yeoman
+- webpack
+- ava/nyc
+- aws-cli
+
+但是，这显然不够，我们还需要一种机制，保证团队使用的工具版本一致。
+
+轻量级的做法是，在项目初始化模板中定义npm script并且在npm dev-dependency中规定它的版本号。
+
+重量级的做法是，开发一个包装工具，在命令行中不直接使用命令，而使用包装过的命令。如在我之前的团队，使用的工具名为def，它规定了一些命令：
+
+- def init
+- def dev
+- def test
+- def publish
+
+这样，工具链的使用者只需指定工具链名称，就不需要知道项目具体使用了哪些工具，这样只需要专注自己的需求就够了。
+
+同时，统一的命令行入口，意味着整个团队不需要互相学习工具链，就可以接手别人的项目开发。
+
+在稍微大一些的团队内部，往往会需要不止一种开发模式，如移动开发和桌面开发，这样，所需要的工具链也不一样，因此我们需要多条工具链。
+
+要想开发新的工具链，可以使用复制分支的方式来扩展原来的工具链。在我原来的工作中，不同的工具链被称作“套件”，每一种套件对应着一组互相配合的工具。
+
+## 工具体系的执行
+
+因为工具体系服务的是团队内部成员，所以执行非常简单，同时，工具体系的入口是初始化项目，所以只要初始化工具在手，可以控制其它所有工具。
+
+我们在性能的那一课里，已经讲过工程体系的执行分成三个层次：纯管理、制度化和自动化。
+
+工具体系因为其自身特性，可以说是最容易做到自动化的一个体系了。
+
+## 工具体系的监控
+
+工具体系的结果虽然是软性的，也不能完全不做监控。
+
+纯粹的社区方案比较难做到监控，但是如果我们使用了前面提到的统一命令行入口包装，那么就可以做一些简单的统计工作了。
+
+一般来说，以下指标跟开发者体验较为相关：
+
+- 调试/构建次数；
+- 构建平均时长；
+- 使用的工具版本；
+- 发布次数。
+
+在我之前的工作中，工具团队曾经从构建平均时长数据中发现构建效率问题，对webpack做了大量深度优化来改善开发体验。
+
+同时，工具的相关数据还能够帮助发现一些问题，比如某个项目频繁发布，可能说明它风险很高。工具的相关数据还能帮我们发现老旧的工具，如果某个套件使用频率极低，则可以考虑把它下线。
+
+总之，工具体系的监控不仅仅是衡量工具体系的好帮手，也是非常珍贵的研发数据，里面有很多可挖掘的价值。
+
+## 总结
+
+这一课，我们讲解了工具相关的工程知识。
+
+我们仍然从目标、方案设计、执行和结果四个方面来讲解，工具体系的目标除了单个工具解决具体问题之外，还要注意一致性和配合问题，因此我们需要工具链。
+
+工具链一般会涵盖研发阶段的各个主要操作。工具体系的执行比较简单，很容易就可以做到完全的自动化。工具体系的监控同样非常重要，工具的监控除了帮助我们改进工具体系，对研发体系的其它部分也有帮助。
+
+最后，请你思考下自己所在的团队，是否已经建立了工具体系？听完了今天的课程，你认为它有哪些可改进的部分？
+
+

极客时间专栏/geek/重学前端/模块四：前端综合应用/性能：前端的性能到底对业务数据有多大的影响？.md

@@ -0,0 +1,135 @@
+<audio id="audio" title="性能：前端的性能到底对业务数据有多大的影响？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/12/45/1217bbbc08dab2354507c136a28f7545.mp3"></audio>
+
+你好，我是winter。
+
+从今天开始，我们就从前端知识学习的部分，过渡到了实践部分。这节课我来谈谈性能。
+
+性能是个特别有意思的话题，在我之前的工作中，从入门的初级工程师到高级别的技术专家，大家都很喜欢谈性能，我以前参与晋升评审，每年总能听到很多关于性能的晋升述职。
+
+那么，今天我就来谈谈我眼中的性能。
+
+## 性能总论
+
+> 
+while循环快还是for循环快？
+
+
+> 
+|0 是不是比 Math.floor 性能好？
+
+
+网上随处可以见到一类对性能的讨论。一些新人也非常热衷此类讨论。但是实际上，它们除了让你写代码的时候纠结之外，毫无意义。
+
+为什么这样讲呢？我想讲一个小故事。
+
+从前有个工程师，特别注重代码细节，有一天他发现系统中的一段代码写的性能很差，因此，他用汇编重写了整段代码，执行效率足足提升了三倍。但是最后，大家发现，用户反馈性能丝毫没有提高，因为他优化的那个进程名字叫“System Idle”。
+
+所以你看，性能优化不能只着眼于局部的代码。这里，我要提出一个我的观点：**一切没有profiling的性能都是耍流氓**。凡是真正有价值的性能优化，必定是从端到端的业务场景建立体系来考虑的。
+
+在我的认识中，性能体系的建立可以分成以下几部分：
+
+- 现状评估和建立指标；
+- 技术方案；
+- 执行；
+- 结果评估和监控。
+
+下面，我就来为你一一讲解。
+
+## 现状评估和建立指标
+
+要想做好性能优化，正确地评估现状和建立指标是最关键的一步，它又往往是会被轻视的一步。
+
+作为一个工程师，指标又要考虑两个因素。一方面，对用户来说，什么样的性能指标能更好地评估它的体验？另一方面，对公司来说，什么样的指标会影响业务价值呢？
+
+在我公布答案之前，我希望你能思考一下，你所负责的业务，是否有前端性能指标？它是否能够满足我上面提到的两个要求？
+
+在我之前的工作中，整个用了长达一年的时间来探索，才找到了合适的指标，并且回答好了两个问题。
+
+性能问题可以分成很多方面，最重要的几个点是：
+
+- 页面加载性能；
+- 动画与操作性能；
+- 内存、电量消耗。
+
+**注意，这里我们仅仅是对“性能”两个字的分析和解读，在对大量的用户数据分析后，我们发现，其实这三部分中，“页面加载性能”跟用户的流失率有非常强的关联性，而用户流失率，正是公司业务非常看重的指标。**
+
+因此，在开始阶段，我们决定把性能优化的重点放在页面加载性能上。
+
+那么，用什么指标来衡量页面加载性能呢？最容易想到的方案是“用户平均加载时间”，事实上，我们在相当长的一段时间，也都是在使用用户平均加载时间作为性能指标。
+
+但是，很快我们发现，这个指标有严重的问题：
+
+- 当加载时间低于一定数字，用户体感差别不大了，我们经过一定的研究，认为这个数字大约是1秒；
+- 少数超长时间加载的用户（如2G），会极大影响整个指标，即指标不能反映大多数用户的体验。
+
+于是，基于以上分析，我们设计了一个新的指标——秒开率，即一秒之内打开的用户占用户总量的百分比。这个指标后来逐渐推广到整个公司，甚至影响到了一些业内的其它企业，现在，谈秒开率已经是个非常自然的事情了，但是当初的设计确实走了不少弯路。
+
+## 技术方案
+
+有了指标，我们就有了优化的目标，接下来，就到了技术出场的环节了。
+
+我们这里还是以加载过程为例，来讲解一下。
+
+首先我们要简单分析一下，从输入URL后按下回车，到底发生了什么。
+
+我们在浏览器的原理课程中，已经讲解了浏览器大致的工作过程，但是，我们必须理解几件事：
+
+- 从域名到IP地址，需要用DNS协议查询；
+- HTTP协议是用TCP传输的，所以会有TCP建立连接过程；
+- 如果使用HTTPS，还有有HTTPS交换证书；
+- 每个网页还有图片等请求。
+
+从这个分析和实际试验的结果看，网页的加载时间，不但跟体积有关系，还跟请求数有很大关系，因此，我们最终设计的技术方案大约可以这样划分：
+
+<img src="https://static001.geekbang.org/resource/image/6b/f2/6b5051c452af8c3db5fbb8ba6b9e34f2.jpg" alt="">
+
+这里仅仅列出了性能优化的一部分技术方案，是我认为比较重要的部分，可以看到，这里涉及的并不仅仅是前端技术，有服务端、客户端、设计师团队，所以要想做好性能优化，绝对不能把自己限制在局部的视角，必须是整个业务一起考虑，才能有良好的收效。
+
+## 执行
+
+技术方案设计好了，它是不会自己变成线上页面的，所以，有了技术方案，我们只完成了一半的工作，接下来我们还需要一个执行过程。
+
+执行也不简单，如果说方案主要靠技术，那么执行就是靠工程实施了。
+
+根据公司的实际情况，工程实施可能有不同的程度，我把工程水平从低到高分成三个阶段：
+
+- 纯管理；
+- 制度化；
+- 自动化。
+
+纯行政管理，是由经理用纯粹的管理手段来执行方案，比如说，作为前端团队的Leader，我可以组织会议，要求整个团队使用我们前面谈的技术方案。
+
+但是纯行政管理有一些问题，一方面，需要的行政资源不一定有，比如我没法强制让后端团队配合我，另一方面，纯粹的管理方式，团队本身的体验并不好，也不利于团队成长，最重要的是，纯粹管理方式容易造成执行不到位。这样的执行方式多数出现在非技术岗位。
+
+制度化执行方式是用规则代替人的命令，指定责任人，通过培训、checklist、定期review等具体措施来保证实施。制度化执行可以极大地减轻管理工作量，一般现代互联网公司都会采用类似的方式。但是制度化执行方式还有很大成分是依靠人的主动性的，对程序员来说，还有更好的方式：自动化。
+
+自动化的方式是在一些重要的操作路径上设置规则，针对我们的性能优化，有两个点适合做这件事：一个是把开发好的页面发布上线，另一个是开发好的页面URL投放到首页等处的链接。
+
+在我之前的工作中，我们跟测试团队配合，开发了一套页面性能打分系统，它会自动扫面页面上的可优化点，并且跟发布平台和投放平台合作，把它加入日常机制中。现在多数公司都会采用制度化和自动化结合的执行方案。
+
+## 结果评估和监控
+
+执行完了之后，**就要向老板汇报争取升职加薪了**，还要有一定的结果总结，才是一个完整的工程实施，而且，凡是工程实施，肯定要有一定长效机制，不能优化完了退化，这些都要求有线上监控机制。
+
+要想做线上监控，分两个部分：
+
+- 数据采集；
+- 数据展现。
+
+数据采集部分，同样需要发布平台或者开发工具来配合，对性能数据来说，Performance API非常好用，它是浏览器记录的性能数据，一般来说，我们用统一的代码把它上传到服务器端就够用了。
+
+数据的展现部分就比较自由了，可以用不同的数据可视化方案来展现性能数据，没有一定之规。一般的数据监控平台，会提供报警机制，对性能来说，报警需求不是特别强烈，但是也可以设置一些条件，针对秒开率特别低的网页报警。
+
+有了监控，再配合一定制度，就可以保障整个团队产出的性能了，要注意，性能不是一个静态的事情，指标需要不断优化，技术方案还需要不断随着技术发展迭代，制度、自动化工具也需要不断改进，最终的监控平台产品也不能不做新需求，所以性能应该成为一个团队的日常工作的一部分，持续进行。
+
+## 总结
+
+今天我们学习了前端团队工程实施中的性能体系，首先我们介绍了总体思想：性能应该是基于业务和实际用户体验需求的一种工程实施，不是纯粹的技术游戏。
+
+接下来我们分成四个步骤介绍了性能工程体系，首先介绍了现状评估和建立指标，建立指标应当从业务的角度考虑，接下来讲了技术方案设计，技术方案应当从整体角度，基于Profiling的结果分析来设计。
+
+之后我们讲了实施，我们讲了工程实施的三个层次：纯管理、制度化、工程化，最后，我们讲了结果评估和线上监控，线上监控需要从数据采集和数据展现两个部分分别实现。
+
+最后，留一个小问题，请你为自己的团队和业务设计一下性能的整体方案，欢迎来留言分享。
+
+

极客时间专栏/geek/重学前端/模块四：前端综合应用/持续集成：几十个前端一起工作，如何保证工作质量？.md

@@ -0,0 +1,120 @@
+<audio id="audio" title="持续集成：几十个前端一起工作，如何保证工作质量？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/61/31/616be5d7ac0581678286420d7e768d31.mp3"></audio>
+
+你好，我是winter。今天我们来聊聊持续集成。
+
+持续集成是近现代软件工程中的一个非常重要的概念。它是指在软件开发过程中，以定期或者实时的方式，集成所有人的工作成果，做统一的构建和测试。
+
+与持续集成相对的做法是：独立开发各个模块，在软件开发的最终阶段才做集成。持续集成的优势是及早处理集成阶段的问题，使软件质量和开发进度可控。
+
+现在持续集成还有升级版本：持续交付和持续部署，这些因为需要更为完善的基础设施，目前很少有公司前端团队可以用上，我们暂且不谈。
+
+传统的持续集成概念诞生于桌面客户端开发，在Web前端领域，由于技术和产品形态的差别，我们需要构建的持续集成体系也有一些区别。
+
+## 持续集成总论
+
+传统软件的持续集成主要有以下措施。
+
+- daily build：每日构建，开发者每天提交代码到代码仓库，构建一个可运行的版本。
+- build verification test（BVT）：构建验证测试，每日构建版本出来后，运行一组自动化的测试用例，保证基本功能可用。
+
+对于前端来说，有一些现实的区别：
+
+- 前端代码按页面自然解耦，大部分页面都是单人开发；
+- 前端构建逻辑简单，一般开发阶段都保证构建成功，不需要构建；
+- 前端代码一般用于开发界面，测试自动化成本极高；
+- 前端页面跳转，是基于url，没有明确的产品边界。
+
+基于以上分析，传统的持续集成方案放在前端，要么不需要，要么不适用，要么实施成本高，因此我们不能套用传统的持续集成理论，而需要重新思考前端领域的持续集成体系。
+
+## 持续集成的目标
+
+前面我们已经分析过，每日构建不需要，前端构建验证测试成本过高难以实施，那么我们是不是可以有一些代替的措施呢？
+
+首先我们要确定前端持续集成的目标，我们回到持续集成的根本理念，一是要及早集成代码形成可测试的版本，二是通过一定的测试来验证提交的代码的有效性。
+
+## 持续集成的方案
+
+我们进一步思考，前端持续集成如何完成这两个目标呢？
+
+前端代码不需要构建，或者说只需要单页面构建，但是页面与页面之间的跳转是用url构成的，所以我们的可测试的版本，不可能通过“构建”来获得。
+
+我们只能通过“发布”来获得一个前端代码的可执行版本，在传统语境中，“发布”的目标是线上生产环境，这显然不行。于是，我们就需要一个预览环境，来做一种“虚拟发布”的操作。
+
+我们再来考虑一下，为界面编写自动化测试用例成本很高，那么如何代替构建验证测试呢？
+
+我们回忆一下，在性能一课，我有讲过，页面的性能可以通过一些自动化工具来分析，还可以通过一些数据采集方案来发现性能问题，对于预览环境前端页面，我们可以采用同样的措施。
+
+除了基于页面结构的分析和数据采集，我们还可以扫描代码。
+
+综上，我认为前端的持续集成的措施应该是这样的：
+
+- 预览环境，代替每日构建，前端每次（或指定次）提交代码到仓库都同步到预览环境，保证预览环境总是可用；
+- 规则校验，代替构建验证测试，通过数据采集（如前面提到的性能数据）和代码扫描，保证提交的代码满足一定的质量要求。
+
+接下来，让我来详细介绍一下预览环境的设计和规则校验的设计。
+
+### 预览环境
+
+前端代码发布到线上生产环境需要有线上的机器和域名，而预览环境同样需要机器和域名，不过，只需要在公司内网即可。
+
+所以建立预览环境的第一步就是申请机器和域名，我们需要运维协助，在预览环境的机器上部署Web应用服务器。
+
+有了预览环境的机器，下一步就是建立预览环境发布机制。
+
+有些公司使用脚本发布，有些公司使用git hook，有些公司则使用一个Web应用平台，进行白屏操作，因为各个公司的发布机制千差万别，我这里没办法讲解具体的方案。这里我建议，预览环境的机器发布流程应该跟线上发布保持一致，这样可以最大程度降低成本和降低心智负担。
+
+预览环境的部署和发布机制建立是最基本的需求，在实际应用中，情况要复杂的多，可能需要多个预览环境同时存在。
+
+比如，测试工程师可能要求一个相对稳定的环境来测试，这是一个合理的诉求，比如，全公司大部分业务都可能依赖登录页面，一旦登录页面在频繁发布导致一些预览环境的故障，可能全公司都没办法工作了。
+
+又比如，当服务端工程师联调时，会希望前端的预览环境跟服务端的预览环境对接，而当服务端的代码部署到线上生产环境后，可能又需要前端的预览环境跟服务端线上环境对接。
+
+这些问题都是我曾经遇到过的非常现实的问题，如果今天回过头来设计，我认为应该设计一套带参数和版本号的预览环境，为测试提供特定版本的预览环境，用参数解决那些跟服务端API对接问题，但是任何系统都不可能从一开始就设计完善，所以，建议你把重心放到建立预览环境的基本需求上来。
+
+### 规则校验
+
+接下来我们讲讲规则校验，规则校验可以分成三种措施：
+
+- 页面结构扫描；
+- 运行时数据采集；
+- 代码扫描。
+
+页面结构扫描可以使用无头浏览器（如phantomjs）配合一些JavaScript代码编写的规则来完成。
+
+运行时数据采集，可以通过在页面插入公共js文件的方式来完成，最基本的是用Performance API来采集性能数据，用window.onerror来采集js错误。
+
+代码扫描，社区有一些现成的方案，比如JSHint，你可以根据实际需要，选择社区方案或者自研。
+
+## 持续集成的实施
+
+持续集成的实施，是必须严格做到自动化和制度化的。我们可以通过上节课讲的工具来完成持续集成。其它部分，都可以通过工具和制度来完成，这里需要重点讲的是规则校验中的规则部分。
+
+我们刚刚讲解的规则校验仅仅是搭建好了平台，而规则本身，我们需要先形成一个共识，然后在前端团队内部形成一定的更新机制。
+
+这里，我建议用issue的方式来管理规则的提案，可以在周会或者月会上讨论，充分保证整个团队对校验规则的一致意见。
+
+这里，我们必须警惕三种错误：
+
+- 少数人拍脑袋决定校验规则；
+- 一成不变的校验规则；
+- 频繁无规律变化的校验规则。
+
+只有经过民主讨论、定期更新的校验规则，才能在团队中起到积极作用。校验规则决定了整个前端团队的开发体验，所以必须非常慎重。
+
+## 持续集成的结果
+
+持续集成机制的建立本身就可以视为一种结果，它能够让整个团队的代码质量有一个基本的保障，提前发现问题，统一代码风格，从而带来开发体验和效率的提升。
+
+此外，持续集成的结果也能够以数据的方式呈现出整个开发团队的健康状态，这是管理者会非常关注的一个点。
+
+## 总结
+
+今天我们讲解了持续集成，持续集成这个概念最早来自桌面客户端软件开发，应用到前端领域，会有一定的变化。这里我提出了一个预览环境+规则校验的前端持续集成体系。
+
+预览环境需要申请机器和域名、部署和建立发布机制，规则校验有三种方法：结构扫描、数据采集和代码扫描。
+
+持续集成的实施需要重点关注校验规则部分，要建立一个民主讨论、定期更新的校验规则。持续集成机制的建立就是其结果本身，此外，系统中产生的数据也可以有一定管理价值。
+
+最后留一个问题，你所在的团队，是否有做持续集成呢？请你设计或者改进这个持续集成方案。
+
+

极客时间专栏/geek/重学前端/模块四：前端综合应用/搭建系统：大量的低价值需求应该如何应对？.md

@@ -0,0 +1,128 @@
+<audio id="audio" title="搭建系统：大量的低价值需求应该如何应对？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1b/8b/1b046607b8be1181b8f878bb5652678b.mp3"></audio>
+
+你好，我是winter。
+
+不知道你在工作中有没有遇到过这样的事情：一个运营找过来说，有一个紧急又简单的临时活动页面要做，希望打断现有的产品开发节奏临时插入。
+
+这类页面技术难度不高，业务上通常属于“紧急不重要”的事情。
+
+这些需求技术上没挑战，线上存在时间短，上线时间紧又没有任何调整空间，它们往往会成为前端团队里人人都不喜欢的“垃圾需求”，谁要是接了这种需求，就只能自认倒霉。
+
+但是，这些真的是垃圾需求吗？换个视角来看，我认为它反而是宝藏。
+
+所谓工程师，就是为了解决这些问题而存在的岗位，我们从工程的视角来看，“大量紧急不重要的页面”，才是真正的需求，现在需求有了，我们就应该按照工程的方式，定目标、设计方案、做实施、拿结果来解决问题。这就是我们今天要讲的搭建系统。
+
+## 搭建系统的目标
+
+搭建系统的目标是解决大量的简单页面生产问题。衡量这个目标的指标应该是生产页面的数量，这部分非常的明确，你如果要做搭建系统，可以根据业务的体量和服务的范围来决定具体的指标要求。
+
+## 搭建系统的设计
+
+搭建系统设计大概有几种流派，这里我介绍几种常见的搭建系统的设计。
+
+第一种，是模板化搭建，由前端工程师生产页面模板，再由运营提供数据来完成页面，可以用以下公式来理解：
+
+> 
+模板 + 数据 = 页面
+
+
+模板化搭建是一种简单的思路，它的优点是整个系统实现简单。
+
+第二种思路是，模块化搭建，由前端工程师生产模块，由运营把模块和数据组织成页面。
+
+第三种思路，是数据驱动界面，这是一种比较新的思路，即数据中包含了展现自身所需要的模块相关的信息，本身决定了界面。
+
+但是不论何种流派，都可以认为是数据、模块、模板、页面几种实体的相互作用，下面我就来详细讲解一下这几样实体。
+
+### 数据
+
+数据是用于展现界面所需要的信息。
+
+我们按照数据用途，可以分成界面配置数据和内容数据。
+
+- 界面配置数据：决定了页面上颜色、尺寸、位置、图片、文字等展现形式的数据，通常是以页面为单位的配置。
+- 内容数据：页面要展示的信息，如电商活动页面的商品信息、文章的文字信息等。
+
+按照数据来源，我们又可以分成运营人员手工填写的数据和来自API产生的数据。
+
+- 运营手工填写固定数据：运营人员依靠自己的专业技能决定的数据，可能包含线下招商信息、商品选品、文章等。
+<li>来自API的数据：
+<ul>
+- 固定数据，由服务端逻辑到指定存储处获取的数据；
+- 用户相关数据，由算法系统或者服务端逻辑，根据用户信息或者用户喜好推荐的数据。
+
+搭建系统本身是个产品，我们针对数据这个实体，要设计增、删、改、查的能力，根据我们以上的分析，搭建系统的数据部分有两个难点。
+
+第一个难点是数据的手工编辑能力，现在一般的数据都会采用JSON格式，JSON格式中有数字、字符串、数组、对象、布尔等数据类型，我们需要根据数据的格式定义为每一种类型设计编辑器。
+
+但是仅仅是基本类型还不够，我们实际开发中，还需要跟实际业务结合来设计编辑器，下面，我就把我在之前的工作中设计的数据编辑器列一下。
+
+- 整数：整数编辑器，可用HTML原生输入框`&lt;input type=number min=1 max=100/&gt;`实现。
+- 数字：数字编辑器，可用`&lt;input type=number min=1.0 max=100.0/&gt;`实现
+- 字符串：字符串编辑器，可用`&lt;input /&gt;`实现。
+- URL：URL编辑器，可用`&lt;input /&gt;`配合格式校验。
+- 图片：图片编辑器，需要自研图片上传功能。
+- 固定字段对象：对象和字段编辑器，可用多个`&lt;input /&gt;`和`&lt;label&gt;`实现。
+- 布尔型：开关，可用`&lt;select&gt;`或者自研组件实现。
+- 自由字段对象：需要自研KV输入组件。
+- 数组：需要自研列表组件实现。
+- 对象数组：需要自研表格组件或者列表组件实现。
+- 矩形区域：需要自研区域选择组件。
+
+这里要注意JSON是一个级联的格式，所以对象、数组中很可能需要插入各种不同的数据类型的编辑器，这部分技术上有一定挑战。此外，实践中，对象数组很多时候都来自Excel数据，Excel导入也是非常重要的。
+
+第二个难点则是跟服务端API的对接，对于服务端系统统一性较好的公司，这不是什么难事，对服务端系统比较奔放的公司，如果服务端API调用方式不统一，就非常麻烦了。这一块只能根据实际情况见招拆招，我这里没办法详细介绍，
+
+### 模板
+
+模板可以简单得理解成挖了许多坑的页面，它一般是由前端工程师来生产的一种实体。与数据之间的连接是数据的格式，对JSON格式来说，JSON Schema是社区接受度较高的一个方案。
+
+最简单的模板可以用字符串模板来设计，复杂一点的模板则可以由JavaScript进行渲染，通过约定全局变量名称或者约定调用函数入口做到把数据传递给模板，你可以根据实际需求复杂程度选择合适的方案。
+
+需要注意，在产品设计上，模板可不是“增、删、改、查”那么简单，考虑到实际工程需要，模板必须是版本化的，也就是说，前端每发布一个模板，都需要永久性存储一条记录，并且产品设计上必须保持可以回滚，这样，一旦线上发现问题，可以迅速回滚到一个可工作的版本，有效降低不可用时长。
+
+此外，模板设计还有批量更新的需求，一些运营活动可能包含数百个页面，它们使用同一套模板，产品设计上必须要注意提供批量更新机制。
+
+### 模块
+
+模块跟模板非常相似，但是从产品的角度，模块是可组合的。跟模板相似的部分如数据连接、版本化发布、批量更新等，这里就不再赘述。
+
+模块化搭建有额外的技术难点，就是可拖拽的模块编辑器，移动端搭建布局相对简单，可以通过简单的自上而下布局和拖拽改变位置来实现。
+
+桌面的模块拖拽比较复杂，一般都会采用一些变通的思路简化设计，如提供几种固定的布局模板，提供布局容器，或者采用纯绝对定位布局。
+
+在一些产品设计中，会先用模块拼成模板，再指定数据源，这种模式中的“模块”，我们认为是一种开发模板的技术方案，跟我们此处讲的产品上的模块概念不同。因为在我们的认知中，模板应该是由前端工程师产生的，具有复用性的一种实体。
+
+### 页面
+
+不论是模板搭建还是模块搭建，我们的最终生产的目标都是页面。页面同样需要版本化发布，便于回滚。
+
+页面部分实现的难点是跟发布系统的结合，在我们前面讲的所有产品实体中，模板、模块、数据都是存储在搭建系统本身的，但是页面不一样，页面必须要提供线上服务，所以页面是要发布到线上生产环境的。
+
+如我们上一课讲的，假设前端持续集成系统有校验规则，页面也必须经过这个过程。
+
+在我之前的工作中，是通过自建静态Web服务器+CDN回源的方式来支撑搭建系统的线上应用的。
+
+因为服务器上只发布静态内容，并且有CDN挡住用户流量，所以只需要少量几台线上机器即可。
+
+## 搭建系统的实施
+
+在我工作的实践中，搭建系统的实施可以说是所有系统中最容易的了，对多数公司来说搭建系统是一种刚性需求，只要完成了产品开发，立刻会有大量的用户。
+
+所以只要正确识别了需求，搭建系统的推行几乎完全不需要担心。
+
+## 搭建系统的监控
+
+作为一个工具型技术产品，搭建系统同样会产生大量有价值的数据，搭建系统的用户访问和生产页面数量是衡量自身的重要指标。
+
+## 总结
+
+本课我为你讲解了搭建系统，搭建系统是为了应对大量简单页面的生产需求而设计的一种工具型产品，它的目标非常明确，就是快速生产大量的页面。
+
+方案上，它重点和难点在于几个产品实体的设计，数据部分重点在于编辑器和跟服务端API的对接，模板部分则主要是版本化和数据的格式定义，模块除了模板的重点，还有拖拽系统，最终产生的页面主要的难点是跟生产环境的对接。
+
+搭建系统的实施主要是把产品在做出来，一般来讲推广是非常自然的事情，最后，搭建系统产生的数据监控关键的指标是用户访问数和生产页面数。
+
+本课的思考问题是，请你分析一下你们公司是否有搭建系统的需求，尝试用本课的知识来设计或者改进一下你们的搭建系统。
+
+