描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121313691
★本书以实践的方式，将这一系列的领域及理论知识结合到一起
★来帮助读者构建全栈Web 开发的知识体系
★并辅以精益及敏捷的思想，来一步步开发Web 应用
第0章 绪论：Web应用开发周期 1
0.1 Web应用的生命周期 2
0.2 遗留系统与新架构 3
0.3 技术选型与验证 4
0.4 搭建构建系统 5
0.5 迭代 6
0.6 Web应用开发步骤 7
0.7 小结 9
第1部分 准备阶段
第1章 基础知识 12
1.1 搭建开发环境 13
1.1.1 基本要素 13
1.1.2 常用效率工具及其在不同操作系统下的安装 14
1.1.3 搭建开发环境 22
1.1.4 开发工具 23
1.2 版本控制 27
1.2.1 Git初入 28
1.2.2 Git工作流 30
1.3 任务拆分 32
1.3.1 一本书的任务拆分 32
1.3.2 一个功能的任务拆分 33
1.4 小结 35
第2章 最小可行化应用 36
2.1 最小可行化产品 37
2.2 最小可行化Web应用 41
2.2.1 使用Bootstrap模板 41
2.2.2 完善原型 46
2.2.3 简单上线 47
2.3 精益与敏捷软件开发 52
2.3.1 敏捷软件开发 52
2.3.2 精益 56
2.4 小结 58
第3章 技术选型与业务 59
3.1 技术选型 61
3.1.1 后端选型 63
3.1.2 数据持久化 67
3.1.3 前端选型：UI框架 71
3.2 Django 72
3.2.1 Django 简介 72
3.2.2 安装Django 74
3.2.3 创建项目 77
3.3 从真实世界到代码 83
3.3.1 模型、领域、抽象 84
3.3.2 前后端分离 88
3.4 小结 90
第4章 构建系统及其工作流 92
4.1 构建流 93
4.1.1 搭建开发环境 96
4.1.2 准备生产环境 98
4.2 打造后端构建系统 100
4.2.1 使用Fabric搭建构建系统 101
4.2.2 软件包管理 107
4.3 小结 109
第2部分 编码到上线
第5章 编码 112
5.1 创建首页应用 114
5.1.1 生成首页应用 115
5.1.2 编写第一个测试 122
5.1.3 使用Selenium进行功能测试 124
5.1.4 如何编写测试 128
5.2 创建博客应用 134
5.2.1 创建应用与博客管理 134
5.2.2 在页面上显示博客 141
5.3 数据与Web应用开发 150
5.3.1 管理数据 151
5.3.2 显示数据 151
5.4 小结 152
第6章 上线 155
6.1 手动部署 156
6.1.1 操作系统与服务器软件 157
6.1.2 第一次部署应用 162
6.1.3 配置管理 176
6.2 自动化部署 178
6.2.1 使用Fabric自动化部署 179
6.2.2 探索更优雅的方案 185
6.3 隔离与运行环境 187
6.4 小结 199
第7章 数据分析和性能优化 200
7.1 网站监测与分析 203
7.1.1 Google Analytics 203
7.1.2 自建监测和分析服务 212
7.2 性能分析及优化 214
7.2.1 前端优化：用PageSpeed工具分析和优化 215
7.2.2 后台优化：使用应用性能管理工具 223
7.2.3 使用New Relic进行优化 225
7.2.4 缓存初入 230
7.3 小结 234
第8章 持续集成与持续交付 236
8.1 持续集成与Jenkins 237
8.1.1 工具选择与Pipeline设计 239
8.1.2 Jenkins搭建持续集成 244
8.1.3 使用Jenkinsfile简化流程 252
8.2 持续交付与持续部署初探 255
8.2.1 持续交付 256
8.2.2 持续部署初探 260
8.3 小结 261
第9章 移动Web与混合应用 263
9.1 移动 Web 与单页面应用 264
9.1.1 单页面应用入门 266
9.1.2 API设计与框架选型 272
9.2 创建移动应用 277
9.2.1 使用Ionic 2创建应用 278
9.2.2 更新首页 293
9.3 实现博客应用开发 297
9.3.1 创建博客API 297
9.3.2 创建详情页和列表页 302
9.4 用户登录与博客创建 309
9.4.1 使用JWT实现登录 310
9.4.2 测试和发布应用 323
9.5 小结 325
第3部分 增量性优化
第10章 遗留代码与重构 328
10.1 遗留系统 330
10.1.1 什么是遗留系统 330
10.1.2 遗留系统改造 334
10.2 易读的代码与重构 336
10.2.1 命名 337
10.2.2 一次只做一件事 339
10.2.3 减少重复代码 340
10.2.4 排版 342
10.2.5 重构 343
10.3 小结 346
第11章 增长与新架构 348
11.1 增长 350
11.1.1 增长：回顾与改变 350
11.1.2 增长：技能学习与构建索引 354
11.2 设计新架构 357
11.3 小结 363
附 录
附录A 如何学习新的技术 366
附录B 安装Piwik 372
学习 Web 开发最难的不是学习相关技术，而是需要了解整个Web 开发的知识体系。多数时候并不是因为我们不学习，而是因为我们不知道学习什么。完整的知识体系不仅仅包括前端、后台开发，还应该包括持续集成、自动化部署等内容。这些往往需要几本不同的书才能学习到，另外，它们也难以保证知识体系的完整性。我们在学习的时候，也往往并没有注意到它们之间的联系。
本书可以为读者构建出清晰、完整的Web 开发体系，包括：前端、后台的技术选型，搭建构建系统，如何上线部署，并进行数据分析，以及如何在其中结合最好的工程实践等。希望作为读者的你，可以将本书当作一本索引书籍，以此来开启你的Web 开发新世界；你可以按书中的实践来进行Web 编程，并结合理论来实践。
★为什么写这本书
本书是我在实习的时候特别想写的一些内容——关于如何系统地学习Web 开发，只是我一直缺少一条主线来将这些内容一一串起来。
2016 年年初，我在GitHub 上开源了一个名为Growth 的应用（读者可以在App Store和各大应用商店下载该软件）。在该应用中便包含了本书的主要思想：Web 应用的生命周期。在不断迭代的过程中，该应用越来越受开发者喜爱，至今已经有超过10000 名用户用过这个应用。随后，笔者在GitHub 上推出了开源电子书《Growth：全栈增长工程师指南》，已经有超过4500 个Star。由于电子书本身只是一个指南，越来越多的读者还希望有一本实战。也因此诞生了《Growth：全栈增长工程师实战》，其在GitHub 上也有超过1000 个Star。
后来，我才下决心去出版这样一本书。写一本书不是一件容易的事，相比较而言，读一本书则要简单许多。前者要花费一个人几个月的时间来完成，而后者只需要几星期、几天，或者是几小时的事。花几分钟将书的目录过一遍，随后只看几页想看的内容，余下的内容则可以在以后闲暇的日子里探索。
本书是我在编程生涯初期的一些体会，它更像是一本关于Web 开发的索引书籍，但其实这些索引正是我读了大量书籍后，自己对精髓之处进行的理解加工。在这本书里，你会看到我对很多知识点进行了概括，并以实践的方式将一个个知识点连接到一起。
在最开始的时候，我曾经想将书名命名为“实习记”。后来又觉得虽然这是在我实习期间学到的知识，但其实很多内容在其他公司是学不到的。因此，在电子书里将其命名为Growth，它不仅可以使读者增长知识，也在让我自己成长。
★本书目标
本书的目标是帮助读者构建Web 应用的全栈开发所需要的完整知识体系，并以精益创业的思想来一步步开发Web 应用。
?? 从创建一个UI 原型到编写出静态的前端页面。
?? 从静态的前端页面到后台的应用，并部署应用。
?? 从Web 后台开发API 到开发移动Web 应用。
在这个过程中，我们还将介绍一些相辅相成的步骤：
?? 使用构建系统来加速Web 应用的开发。
为应用数据分析工具改进产品。
?? 使用分析工具改善应用的性能。
?? 通过自动化部署加快上线流程。
从而帮助读者开发出一个真正可用的全栈Web 应用。同时，我们也希望能帮助读者将这些步骤应用到现有的系统上，改进现有系统的开发流程。
★本书结构
本书从结构上分成了3 部分，每部分都会有不同的侧重点。
第 1 部分：准备阶段
在这一部分里，我们将主要集中于编码前的一系列开发准备工作，从选择一个合适的IDE 到创建一个Web 应用的构建流。
第 1 章基础知识介绍了搭建开发所需要的基本环境，以及IDE、操作系统、版本管理工具等日常工具的选择与使用；还介绍了如何对一个目标进行切分，以便我们在实现的时候可以一步步往下实践。
第 2 章最小可行化应用介绍了如何使用UI 工具来创建原型，并根据这个原型创建出一个最简单的Web 应用；接着介绍了在Web 应用开发的过程中，如何使用精益的思想来开发出用户喜爱的产品。
第 3 章技术选型与业务对后台开发所需要的技术进行简单概览，并介绍了不同后台组件的框架，以及如何从这些框架中选择出合适的框架。同时还介绍了Python 下的Web开发框架Django，以及如何用这个框架创建一个“hello，world！”程序。
第 4 章构建系统及其工作流介绍 Web 应用中常见的构建流程及组件，以及如何结合Fabric 打造后台的构建系统。
第 2 部分：编码到上线
在这一部分里，我们主要讲述大部分Web 应用的开发过程，并介绍在开发过程中一些好的实践。
第 5 章编码 介绍了如何使用Django 创建一个简单的博客应用，以及如何使用单元测试、UI 测试来测试代码的功能。
第 6 章上线 介绍了如何手动部署开发的Web 应用到产品环境，以及如何使用自动部署工具来完成自动化部署。
第 7 章数据分析和体验优化介绍了如何使用网页监测工具来分析网页的流量来源、用户行为等，并结合一些前端、后台的优化工具对应用进行优化。
第 8 章持续集成与持续交付介绍了如何使用持续集成工具，以及如何使用持续集成工具来改进开发流程，并实现自动化的部署。
第 9 章移动 Web 与混合应用介绍如何结写后台API 来创建移动应用，以及如何为单页面应用提供SEO 支持。
第 3 部分：增量性优化
第 10 章遗留代码与重构介绍什么是遗留系统，以及如何基于第2 部分中的经验来改进遗留系统。
第 11 章增长与新架构介绍如何使用回顾与反馈来使程序员成长，以及如何依据需要设计出新的架构。
技术栈概述本书所介绍的工具主要集中于前端、后台、构建工具和前端UI 框架四部分，分别如下。
?? Django 是Python 语言的一个MVC 架构Web 开发框架。本书使用这个框架来介绍如何编写单元测试、功能测试，并演示如何使用它进行持续集成和持续部署。
?? Bootstrap 是一个在前端领域相当流行的响应式Web UI 开发框架，本书出于开发便捷的缘故使用这个框架。
?? Fabric 是一个命令行的自动化部署工具，本书使用这个框架来展示如何搭建构建系统，并使用它来进行自动化部署。
?? Angular 2 是一个可以用于构建移动应用和桌面Web 应用的开发平台，我们在书里用它来展示如何开发前后端分离的Web 应用程序。上面的几个框架可以构成跨手机、桌面的一个Web 应用，以及如何对其进行自动化部署。另外，还将介绍一些工具和框架来帮助我们开发：
?? Ionic 2 是一个跨平台（Android、iOS、Windows Phone）的混合应用开发框架，基于Angular 2 框架，并搭建有大量的UI 组件，以及原生组件，我们在书里说明它与Angular 2 如何共用代码来开发手机端应用。
?? Jenkins 是一个持续集成工具，它提供了持续集成与持续部署工具链中所需要的大部分工具。我们将用它来展示如何进行持续集成，并结合Fabric 来实现自动化部署。本书将展示如何结合这些工具来做一些最佳实践，读者不必担心它会影响你的阅读，并且这些工具也很容易找到相应的替代品。
代码
本书相关的代码都可以从GitHub 上下载到：。混合应用部分的代码可以从 处下载。这些代码遵循MIT 协议开源，读者可以将这些代码用于学习、商业等用途的项目中，不需要笔者同意。同时，笔者也不对这些代码的衍生代码负责。
遇到问题
在遇到问题时，欢迎及时与笔者联系。遇到代码问题时，建议直接在GitHub 上创建一个相关Issue，以便我们帮助其他读者解决同样的问题。
遇到内容不清楚等问题时，可以通过下面的方式联系笔者：
1. 通过GitHub 上的Growth 项目参与讨论：
2. 在Growth 论坛上讨论：
3. 在微博上与我联系：@phodal
4. 通过邮件：
5. 加入QQ 群讨论：529600394
你也可以在知乎、SegmentFault 网站上进行提问，并@phodal 来帮助你解决这个问题。
致谢
我要把这本书献给花仲马，没有她，就没有这本书。感谢她在这本书的写作过程中一直陪伴着我，并为这本书进行了中文校对来保证语句的通顺。同时，我想特别感谢ThoughtWorks 的同事薛倩、阿里巴巴的孙辉在本书创作过程中提供了详细的反馈，正是他们的帮助让本书更加准确、容易阅读。我还想特别感谢在ThoughtWorks 学习时的同事，为我提供悉心指导与帮助。特别感谢王超、陈卿、王妮、曹隆凯、张静强、刘杰、王磊，在和他们进行结对编程时，我学习到了敏捷软件开发、Tasking等编程之外的技能，感谢他们帮我走了这么远。
此外，还有那些在GitHub 上为我提供反馈的用户，正是他们的反馈促使这本书更加完整。由于人数众多，这里仅列出这些用户的ID：
感谢 ethan-funny、izhangzhihao、kaiguo、gymgle、aidewoode、wenzhixin、sasuke6、wangyufeng0615 、walterlv 、lolosssss 、NehzUx 、mikulely 、yulongjun 、PhilipTang 、ReadmeCritic、ReadmeCritic、wangcongyi、loveisbug 等用户为《Growth：全栈增长工程师指南》提供反馈与修改。
感谢 Pandoraemon、wo0d、ReadmeCritic、zhangmx、felixglow 等用户为《Growth：全栈增长工程师实战》提供了反馈与修改。
轻松注册成为博文视点社区用户（
作者基于大量实践凝练而成的全栈工程师技能图谱，对任何想成为全栈的前端或后端开发人员来说，本书都能给你带来帮助。如果我早点结识这本秘籍，也许我早就是一名优秀的架构师了
——百度高级前端工程师 颜海镜
所谓全栈工程师，竞争力是什么呢？首先，能够从全局上把握项目的开展，对整体开发链路和技术体系有深入的理解；其次，就是掌握更多的知识（点）和工具，在每个环节都比别人了解得更全面、细致。Phodal的这本书恰好可以给你带来这些能力。
?
本书围绕Web全栈开发涉及的整体循环链路做了充分说明，时而穿插生动、详细的实战过程。看一遍，你可以更加深入地理解全栈工作；若能跟着实操，必会受益匪浅。书中涉及大量日常工作中不可错过的知识点详解，学一个赚到一个，值得推荐。
——资深 Web 研发工程师 小胡子哥
有幸作为早期预览者看到作者以非常严谨的态度在写这本书。这本书的问世是众多开发者的福音，作者以简单易懂、风趣的笔风为大家掀开了作为全栈工程师应该学习和具备的能力。本书将能让大家更好、更清楚地理解全栈工程师的成长历程，同时也可以帮助技术团队解决很多问题，提高开发效率，降低开发成本，也许会成为一些团队提高工程师能力的一种契机。
——W3cplus.com站长 大漠
本书通过大量的实例深入浅出地讲解了全栈开发的较佳实践，对基础概念的讲解也是抽丝剥茧、鞭辟入里，使枯燥的知识顿时鲜活起来。作者三年磨一剑，不管你是前端小白，还是全栈专家，本书都值得一看。
——在线回声前端技术专家 justjavac
全栈意味着我们不介意跳出自己的专业思考和解决问题；而精益则鼓励我们接近问题的本质和真相，然后大胆取舍，抓住那些四两拨千斤、以不变应万变的东西。这两方面的思考在当今社会中都特别珍贵。这本书可以帮助你了解很多被广泛实践的方法，以及被广泛应验的“套路”，也从个人和团队的角度谈了很多。如果你是全栈或精益的信徒，不妨读一读这本书。
——阿里巴巴技术专家 赵锦江（花名：勾股）
0.2 遗留系统与新架构
在我开始工作的时候，接触的第一个项目就是一个遗留系统。在一次休息时，我们在比赛找最古老的源码文件，最后找到了10年前写下的一个文件。尽管在我们的代码里有单元测试、针对具体业务功能的测试，项目的代码已经超过20万行，项目中仍然有相当多的代码超出了我们所理解的业务范围。毕竟在这些年头里，有相当多的功能已经不存在了。后来，我们选用微服务重构了这个系统。对于中型的遗留系统来说，这算是一剂良药。
让我们先从某某网站使用新架构重新设计说起。当我们决定使用新架构重新设计系统时，原因可能是多种多样的，如果我们排除一些无法抗拒的因素（如政治），那么剩下的原因可能就只有两个。
l 系统已经变得难以维护。这里的原因仍然有很多：大量的代码已经没有人知道其业务逻辑，变得难以修改；代码间耦合度过高，重构系统的难度过于复杂；项目所使用的技术栈已经过时，已经被市场所淘汰；团队的技术栈在成员变动的过程中，团队中大部分成员的技术栈已经和当前的项目不匹配了。
l 系统的技术栈已经难以符合业务的需求。绝大多数情况下，我们在最初开始创建项目的时候，所选择的技术栈都是符合当时业务需求的技术栈、可以快速验证其业务价值的技术栈。而随着业务的扩张，现有的技术栈很快将难以满足当前业务的需求，或出现性能优化上的限制。
在多数情况下，我们都会将这种系统称为遗留系统。在这时团队里的气氛便是“能不动这些代码就尽量不去动它”。我们已经很难将项目的问题归为人的因素，多数时候都是受业务扩张的影响。作为一个专业的程序员，我们的本能就是将程序写好，而我们往往没有这样的机会。
业务人员对项目经理说：“我们的竞争对手已经在本周上线了这个功能。”
项目经理对开发人员说：“这个功能下星期就要上线！”
是的，我们的功能不得不马上上线。这时候，我们往往要在代码质量和交付速度上做出一些妥协。妥协多了，系统也就变烂了。
开发人员说：“这个代码我不太敢修改，要是出了什么大Bug怎么办？”慢慢地人们就开始讨论起重构系统的事宜，并开始着手设计新的架构—使之可以满足当前的业务需求、可预测时间内的业务与技术需求。
0.3 技术选型与验证
在讨论新架构的过程中，不同的人可能会有不同的技术偏好，也会因存在一些政治因素导致不同技术方案的产生。如团队中的一些人可能出于稳定缘故而选择Java，一些人可能出于对新技术的需求选择Scala，而另外一些人可能考虑到团队中大部分人可能因为都会使用JavaScript而选择使用JavaScript。如图0-2所示，我们的考虑应该不仅仅取决于这一系列的技术因素。图0-2 技术选型考虑因素
需要注意的是：在做技术选型的时候，要尽最大可能以团队为核心。在做决定之前，我们要提出不同语言、框架下的技术模型，并且进行验证。随后就需要快速搭建出一个原型，并针对这个原型进行假想式开发，然后验证原型本身是经得起考验的。
在这一阶段，我通常喜欢在GitHub上搜索一些名字中带有boilerplate的项目，即模块文件。而当一个框架很流行的时候，我就会去相应的awesome-xx寻找，如awesome-react就可以寻找到react相关的项目集。然后，克隆这样一个项目，开始依照现有的系统创建简单的Demo。随后，就可以依据我们的业务试着在这上面进行扩展。最后，再决定是否使用这门技术和这个框架。
通常来说，在选择一门新技术设计系统时，需要承担的风险相当大，而如果能成功，那么它可能会带来巨大的收益。从这点看，使用最新的技术与赌博无异。在一些成熟的公司里，会有专门的技术委员会负责对新技术进行审核，来决定是否可以在某个项目里使用新技术。除了考虑其为开发带来的便利性，他们更多地还会考虑其成熟度、安全和技术风险等。
0.4 搭建构建系统
决定好架构并选择完技术栈后，我们就开始着手创建项目的构建系统，设计项目的部署流程。构建系统不仅包含项目相关的构建流程，还从某种意义上反映了这个项目的工作流程。
创建完“hello, world”程序后，我们要着手做的事情就是创建一个持续集成环境。这样的环境包含一系列的工具、步骤及实践，从工具上说，我们需要选择版本管理工具、代码托管环境、持续集成工具、打包工具、自动部署脚本等一系列流程，这些流程将会在第4章详细讨论。
图0-3便是笔者之前经历过的一个项目的构建流程。
图0-3 构建过程
这是一个后台语言用Java、前台语言用JavaScript的项目的构建流程。
0.5 迭代
在互联网行业里，能越快速地对市场需求做出反应，就越能有更好的发展。只要你细心观察就可以发现，大部分互联网公司都在以一定的规律更新产品，或者一周，或者两周，又或者一个月等，这种不断根据反馈来改进产品的过程称为迭代。如图0-4所示是一个简化的迭代模型。
图0-4 简化的迭代模型
当一个迭代开始时，我们需要收集上一个迭代的反馈或者新的需求，然后开始开发代码，最后再发布产品。开发的产品在这个过程中不断地增强功能。为此，还需要选择一个好的迭代周期。一个好的迭代周期既应该有充足的时间修复上一个迭代的Bug，又能在下一个迭代开始之前交付重要的功能。当然，如果交付的软件包里出现了重要的Bug，那么我们也能在第一时间使用旧版本的包，并在下一个迭代交付。在这样的开发节奏里，一周显得太短，一个月又显得太长，两周会是一个很不错的时间。
当一个团队在这方面做得不好时，那么他们可能在一次上线后，发现重要的Bug，不得不在当晚或者第二天更新他们的产品。即使是有经验的团队，在开发初期也会经常遇到这些问题，而这些问题可以依赖于在迭代中改进。好的迭代实践都是依据团队自身的需求而发展的，这意味着有时候适合团队A的实践并不一定适合团队B。
随后，我们会在这个“hello, world”的基础上不断添加各种功能。
0.6 Web应用开发步骤
令人难以置信的是，我们做了这么多事情以后还没有开始写代码。事实上，在这一步里，我们已经搭建好了一个最小可运行的Web应用。在这之后，我们所要做的事情就是提交代码即可。将代码从本地提交到服务器后，持续集成服务器将帮我们运行测试，在测试通过后，打包、发布现有的代码，最后部署到测试环境里。
（1）编码
如果不考虑技术难度的因素，写代码看上去就是一件很简单的事。我们只需要按照需求，将功能一点点往上叠加即可。如果不考虑这个过程中添加的代码质量，将会得到一个难以维护的系统，并且在拿到需求后的第一反应也并非直接开始实现功能，而是首先应该考虑可以将这个需求拆分为几步，我们将这个过程称为Tasking。
假如，我们正在实现某个详情页的显示功能，它依赖于前端和后台。那么可以直接先做后台API，再实现前台API，最后依据需要微微调整API。我们也可以先用Mock的数据实现前端页面，再依据定义出来的数据格式实现后台API。在这两种不同的实现中，我们都有一个明确的先后步骤。同样，对于一个更加复杂的功能来说，需要切分得更加仔细，每一次只挑选其中一个任务，实现后，再一步步往下执行，最后实现这个功能。
有意思的是，当我们已经决定切分为多步来实现功能的时候，就可以在每一步里进行几次不同的代码提交，以便以后知道每一步中做了什么内容。如果只是在最后一步直接提交代码，那么在未来修改代码时，便难以理清当时的思路。
一个合理的编码过程不仅包括功能的实现，还应该有测试。尽管出于项目进度的原因，多数项目都不存在测试，而正是因为没有测试，使得整个项目更加混乱。新的功能容易影响旧有的代码，除非有足够多的测试人员，否则我们无法保证所有的功能都是正常的。在有限的条件下，我们应该编写重要的测试，以保证核心功能不被破坏。在条件允许的情况下，我们应该尽可能地保证测试对重要功能的覆盖。由于代码库不只有一个人在提交，如果在某次提交中测试被破坏了，就可以知道谁破坏了测试，他/她应该有责任来修复这个测试。
在完成功能后，我们还可以对代码进行重构，以此来保证代码的质量。此外，在日常工作中，我们会用Code Diff（代码检视）来帮助大家提高代码质量。因此，并不是实现了功能就完事了，我们应该尽量保证代码的质量。
（2）上线和数据分析
好了，现在是时候上线了。在以前，上线就是登录到服务器做数据备份。随后，在本地构建、上传软件包，安装软件的依赖。最后，重启服务器、Done。
在今天看来，这是一件相当费力的事，我们可以使用自动部署工具来加快这个流程，甚至当我们有足够的测试覆盖率时，可以直接将测试通过的代码直接部署到产品环境。不过，要这样做应有相当的技术能力，并且要保证我们可以协调好开发人员、运维人员等。从技术上说，这可能是一件容易的事，但是从组织结构上说，这并不是一件轻松的事。
而故事并没有因此而止步于上线，在产品上线时，我们可以通过数据分析工具来监测用户的行为、网站的访问量等信息。
评论
还没有评论。