qq_37756660的博客

我想在这篇文章中介绍十本书，但是不想推荐“经典”书籍，因为所谓的经典书籍，相信你可以在很多渠道找到这方面的推荐，做这样重复的劳动其实意义不大。因此，这十本书都相对“小众”，但从我的角度来说，都是非常值得一读的。再要说明的是，这十本书并非是围绕全栈工程师这个主题的，事实上在专栏的每一篇文章末尾，已经给出了扩展阅读的材料。这个书单中的书，它们中一半是技术书，但也有其它方面的书籍。具体来说，五本技术，一本产品和体验设计，一本工程师文化，两本数学，还有一本经济和企业传记。

再说说具体的技术，每个人都有偏好，但是不要因为自己的偏好，在技术的选择上失去程序员应有的理性判断，甚至将应当去接纳和学习的技术拒之门外。只有那些有着包容心的程序员，才能去接纳和抓住机会。在最后的 XML、JSON 和 YAML 这一讲，我把这几个数据承载格式的优劣进行了仔细的比较，包括简洁和严谨的程度，与 JavaScript 的亲和力，schema、转义方式和路径表达式等等。在这一章的一开始，首先介绍了这一层中互联网应用最广泛的技术之一——缓存，讲了它的本质、应用和常见的坑，以及缓存框架的设计要点。

今天我聊了聊 Web 全栈工程师在完成核心技术的修炼之后，可以考虑的下一步和进一步的方向，也就是个人的全栈衍化；也从项目和团队的角度，讲了全栈的优势和重要性。不知道正在阅读的你，关于这方面，从职业规划的角度看，你的思路是怎样的，能简单分享一下吗？

今天我们一边动手比较、一边学习了 XML 和 JSON 的前前后后，包括它们的风格、schema 和路径表达式等等，并在之后了解了可读性至上的另一种数据交换语言 YAML。希望这些内容能够帮助你对于这些数据交换语言有更为全面的认识，并能够在工作中选择合适的技术来解决实际问题。今天的提问环节，我想换个形式。这一讲我们已经比较了许多 XML 和 JSON 的特性了，其中一些涉及到了它们之间的优劣。那么，你能不能归纳出 XML 和 JSON 各自的一些优劣来呢？

今天我们一起学习了分页的前前后后，既包括设计、实现，也包括对分页常见的重复数据的问题的分析，希望今天的内容能让你有所收获。老规矩，来提两个问题吧：对于文中介绍的工具类 Paginatior，我把方法签名写出来了，你能把这个类实现完整吗？对于“分页代码设计”一节中介绍的两种分页对象的设计方法，它们各有优劣，你能比较一下吗？

今天我们学习了无损压缩算法中较为基础的几种，事实上，对于我们日常接触的那些实际的、商用的压缩算法，往往都是这些基础技术的综合使用。好，希望你已经理解了这些算法的本。现在又到了提问时间：对比哈夫曼编码和算术编码，你能否比较并分别说出二者的优劣？关于哈夫曼编码，如果编码后的串，其中的某个数值（无论是 0 还是 1）丢失了，你觉得这样的数据损坏，会导致多大比例的数据无法被正确解码？

今天通过一个常见的流量控制系统，向你介绍了全栈开发中几个典型的算法，包括基于固定时间窗口的简单计数法，滑动时间窗口的队列法，还有实际应用中更为常见的漏桶算法和令牌桶算法。希望通过今天的学习，你已经理解了它们的工作原理。现在提两个问题吧：漏桶算法我给出了示例代码，而具有一定相似性的令牌桶算法我没有给出示例代码，如果你理解了这两者，能否写出令牌桶算法的代码呢？为了简化问题，我在一开始的时候讲了，我们不考虑并发的问题。

今天从产品和架构、后端和持久化，以及前端和网络层三个角度，结合一些具体的技巧，介绍了一些常见的网站性能优化方法。网站的性能优化是一个大课题，希望在学完上一讲和这一讲之后，能从前到后比较全面地去分析和思考问题。下面来提两个问题吧：你在项目中是否做过性能优化的工作，能否介绍一下你都进行了哪些有效的优化实践呢？文中介绍了数据库表拆分的两种方式，水平拆分和垂直拆分，它们都带来了显而易见的好处。可是，我们总是需要辩证地去看待一项技术，你能说出它们会带来哪些坏处吗？

今天我们学习了性能优化的基本知识，包括性能优化和软件设计的关系，性能指标和关注点，以及怎样去寻找性能瓶颈，希望你能够理解，在跳进性能优化的“坑”之前先有了足够的认识、分析和思考。现在，来提一个问题吧：对于下面这些资源角度定义的性能指标，你能说说在 Linux 下，该用怎样的工具或命令来查看吗？CPU 使用率、负载；可用内存、换页；磁盘 I/O；网络 I/O；应用进程、线程。

又到了相对轻松的特别放送时间，这一次，我想聊一聊程序员对于英语的学习。在专栏最开始的 [学习路径] 中就提到了工程师的一些“基础”能力，比如数据结构和算法，当然也包括英语。当时我说，，而且英文是所有进阶的软件工程师应当强化的能力，对全栈工程师来说更甚。但是我在当时并没有展开论述，为什么在中文技术材料如此丰富的今天，在工作环境是以中文为主的情况下，英语的学习依然那么重要。

今天我们学习了一些互联网搜索引擎的工作机制，并结合例子从工程的角度了解了几个常见的 SEO 相关技术。今天我们就不放具体的思考题了，但 SEO 本身是一个可以挖掘很深的领域，我在扩展阅读中放置了一些资料，供你延伸。好，到今天为止，“寻找最佳实践”这一章就接近尾声了，你是否有所收获、有所体会，欢迎你在留言区分享。

今天我们重点学习了常见的几种 Web 攻击方式，希望你从中学到了一些网站安全问题的知识和相应的应对办法，毕竟，安全无小事。下面来提两个问题吧：手动输入验证码的功能如今已经被广泛使用了，你觉得对于今天介绍的攻击方式，验证码可以用来防范它们中的哪一些？假如你需要设计一个电商的网上支付功能，用于在线购买商品，用户需要填写信用卡信息并提交。对于这个过程，从安全的角度看，你觉得有哪些措施是必须要采取，从而提高支付行为整体的安全性的？

今天我们学习了持续集成和持续发布，以及 Web 全栈项目中常见的测试维度，并讲到了各自容易出现的问题，依然希望你可以有效避坑。下面是提问时间：在你经历的项目中，你们是否实现或部分实现了持续集成和持续发布，能说说吗？除去文中介绍的，你觉得还有哪些测试的维度是 Web 项目特有或经常关注的（比如浏览器兼容性测试）？今天的正文就到这里，欢迎你继续学习下面的选修课堂。

今天详细介绍了负载分担下的集群和新代码部署的方式，也介绍了服务端 Session 和客户端 Cookie 的原理，希望你能有所启发，有效避坑。现在来提两个问题：在你参与过的项目中，代码部署环节，采用的是上面介绍的六种策略中的哪一种呢，或者是第七种？文中介绍了 Session 和 Cookie 都可以存放一定的信息，现在试想一下，如果你来实现极客时间这个网站（包括注册、登陆和课程订阅功能），你觉得哪些信息应当存放在浏览器的 Cookie 内，哪些信息应当存放在服务端 Session 中呢？

今天我们介绍了 Ops 中配置管理的一些常见的方式，以及一些配置文件常见的组织形式。内容本身并不复杂，也没有介绍配置文件的格式（它在后面的文章中会有介绍），但是配置管理确实是程序员每天都在打交道的对象，自然全栈工程师也不例外，遵从好的实践可以养成良好的 Ops 习惯。现在，提问时间又到了，来提两个问题吧：我们今天比较了常见的配置方式，其中一个是使用源代码中的常量，另一个是使用 Web 应用的运行参数，你觉得这两个各有什么优劣，各适合怎样的场景？

在今天的内容中，结合自己的经历，介绍了代码审查的方方面面，主要涉及了“为什么要做代码审查”以及“怎么样做代码审查”这两个方面。

到这一章末尾，我们对于数据持久层的介绍就完结了。不妨来回顾一下，设计持久层，都有哪些需要考虑的方面呢？首先，是代码层面的设计：提供数据服务的设计，即 MVC 中模型层的设计，可以阅读 [第 08 讲] 来复习回顾；对于模型到关系数据库的映射（ORM）和技术选择，在 [第 12 讲] 有所介绍；其次，是系统层面的设计：持久层内部或者持久层之上的缓存技术，请参阅 [第 21 讲] 和 [第 22 讲]；

今天我们从不同角度学习了关系数据库和非关系数据库，掌握了一些存储设计的原理和技巧，希望你可以将内容慢慢消化。下面是今天的提问环节了，我想换个形式。我们已经学习了几种常见的数据库范式，下面这张图书馆用户表的数据库表的设计是不合理的，你觉得它满足了第几范式呢？并且，你能不能通过学到的拆分方法，分析一下它的问题，把它进一步优化，消除冗余呢？

今天我们学习和理解了 CAP 理论，并且了解了一些实际应用的例子。希望你能够通过今天的内容，彻底掌握其原理，并能够逐渐在设计中应用起来，特别是在技术选型做“权衡”的时候。现在，我们来看一下今天的思考题吧：你是否了解或是接触过分布式系统，特别是分布式存储系统，它是否能归类到 NoSQL 三角形中的某一条边上呢？互联网上的绝大多数系统都是可以牺牲一致性，而优先保证可用性的，但也有一些例外。你能举出几个即便牺牲可用性，也要保证数据一致性的例子来吗？

今天我们学习和理解了数据持久化中一致性的相关概念和实现技术，希望通过今天的学习，你能做到“知其然，知其所以然”。现在，我来提一个问题，检验一下你的学习成果。请将下列存储系统按照“强一致性”“弱一致性”和“最终一致性”进行归类：关系数据库本地文件浏览器缓存网盘数据CDN 节点上的静态资源搜索引擎爬虫爬到的数据今天的正文内容就到这里。如果你对一致性哈希原理了解不够透彻的话，强烈推荐你继续学习今天的选修课堂。

今天我们结合实际案例学习了缓存使用中的一些常见的“坑”，并了解了千变万化的缓存框架中一些共性的东西。希望你能够重点体会和理解缓存使用中的问题，即这把双刃剑中向着程序员和系统自己的那一刃，绕开那些已经有人踩过的坑。毕竟，失败的故事总是比成功的故事更有总结的价值。现在，来提两个问题，请你思考：在你的项目中，是否使用到了缓存，在使用的过程中，是否遇到过什么问题，能否跟我们大家分享一下呢？缓存框架介绍了几个核心要素，但是，一个缓存框架还存在着许多的“重要特性”。那么，根据你的经验和理解，你觉得它们还有哪些呢？

今天我们学习了缓存的本质、应用，仔细比较了几种常见的应用模式。在理解缓存本质的基础上，Cache-Aside 模式是缓存应用模式中的重点，在我们实际系统的设计和实现中，它是最为常用的那一个。希望这些缓存的知识可以帮到你！现在来提两个问题，检验一下今天的学习成果吧。在你参与的项目中，是否应用到了缓存，属于哪一个应用模式，能否举例说明呢？这一讲提到了几种缓存应用模式，你能否说出 Cache-Aside 和 Write-Back 这两种模式各有什么优劣，它们都适应怎样的实际场景呢？

从技术的角度上看，和相对偏“硬”的常规内容不同，特别放送部分，一般倾向于介绍一些较“软”的其他内容。第一章的 [特别放送] 介绍了北美大厂工程师的面试流程，第二章的 [特别放送] 我们讨论了学习的方法。那第三章的特别放送，也就是正在阅读的这一讲，想结合自己的经历，谈一谈全栈团队的角色构成。这些团队的角色构成可以说各有春秋，但是和以往直接进行优劣比较的方式不同，今天想换个形式，在这一讲的分享中，将尽量保持中立和平和，而将有态度和有观点的思考留给你。

今天我们结合实例学习了 JavaScript 异步编程的一些方法，包括使用 Promise 或 async/await 来改善异步代码，使用生成器来实现协程，以及怎样进行异步错误处理等等。其中，Promise 相关的使用是需要重点理解的内容，因为它的应用性非常普遍。现在，来提两个问题：在你的项目中，是否使用过 JavaScript 异步编程，都使用了和异步编程有关的哪些技术呢？ES6 和 ES7 引入了很多 JavaScript 的高级特性和语法糖，包括这一讲提到的部分。

今天，我们学习了 Web 绘图标准的基础知识，比较了 SVG 和 Canvas 这两种具备互补性的技术实现；同时，我们也学习了 Flot 和 D3.js 这两个差异很大，但都具备代表性的可视化 JavaScript 库。希望你除了这两项同类技术之间孰优孰劣的比较以外，还掌握了不同类型技术之间联系比较的方法。随着学习的进行，对不同类型技术慢慢具备“深入”和“浅出”两个方向的理解，逐渐将充满关联的知识体系网状结构建立起来。

今天我们学习了一些网页交互设计的理念，知道了怎样通过渐进式增强来照顾到尽可能多的设备和浏览器，也通过例子实际动手了解了怎样实现网页的响应式布局，希望你有所收获。现在，来提两个问题吧：在你的实际工作中，是否有考虑过不同能力的设备和浏览器的兼容适配问题，你又是怎样解决这样的问题呢？给你这样几个 HTML 标签，你能否说出哪些是有语义的，哪些是无语义的呢？

今天我们学习了从前端的角度怎样理解 MVC 架构，特别学习了 Angular 和 React + Redux 两个实际框架的具有代表性的特性。下面，留两个思考题给你：问题一：你在项目中是否使用过前端 MVC 框架，你觉得它带来了什么好处和坏处？问题二：案例判断。我们说它“不好”，因为点击行为和视图展现耦合在一起了，因此我们使用 jQuery 等工具在 JavaScript 中完成绑定，才最终把它移除出去，完成了“解耦”。对此，你怎么看，你觉得它会让代码结构和层次变得更好，还是更糟？

今天我们学习了 JavaScript 面向对象的实现方式和相关的重要特性，希望你能够掌握介绍到的知识点，通过思考和吸收，最终可以在项目中写出易于维护的高质量代码。现在，我想提两个问题，请你挑战一下：在你经历的项目中，是否使用过面向对象来进行 JavaScript 编码，项目的代码质量是怎样的？和静态语言不同的是，JavaScript 有好多种不同的方式来实现继承效果，除了文中介绍的原型链继承和构造继承以外，你是否还知道其它的 JavaScript 继承实现方式？

今天我们首先强调了对于基于 Web 的全栈学习来说，学习前端技术的重要性，接着我们介绍了前端思维的几个转变，特别是事件驱动编程。希望你已经了解了 JavaScript 的单线程运行机制，并能够慢慢习惯不断在代码中与异步和回调打交道。下面留两个思考问题：你在技术团队中主要扮演什么角色，你对前端技术的认识是怎样的？为什么 JavaScript 中，没有像 Java 或 Python 一样的 sleep 方法？毕竟，我就是想让当前执行过程稍等一下，再继续后面的逻辑，有 sleep 的话多方便啊。

今天的特别放送，结合了自己的积累，介绍了我们该怎样做出选择，来应对这个“学不过来”的话题，特别是介绍了一些常见的学习误区，希望你能从我的答案中有所收获。今天就不放特定的思考题了，因为我觉得，这一类主观性特别强的话题，很容易有不同的认识，不需要拿问题来引导思考方向了，不加限定地思考会更好。

今天我们了解了 Java EE 的各种模式，并且重点学习了拦截过滤器这个模式。模式的学习有一个特点，在理论学习的基础上，我们需要反复地实践强化，以及反复地思考。可以说，实践和思考这二者缺一不可。如果只有实践而没有思考，就没有办法灵活地将理论应用在复杂的实际项目中；如果只有思考而没有实践，那么到实际动手的时候还是很难顺利地实施想法。对于今天的内容，留两个问题：我们介绍了 DAO 层的两面性，那么，在你经历的项目中，你是怎样访问数据存储设施（例如文件和数据库）的，能说说吗？

今天我们一起学习了面向切面编程，从学习概念，熟悉配置，到了解实现原理，希望你对于 AOP 已经有了一个清晰的认识，在未来设计和开发系统的时候，无论技术怎样演进，框架怎么变化，始终知道什么时候需要它，并能够把它从你的武器库中拿出来使用。现在来提两个问题，我们一起讨论吧：你过去的项目中有没有应用 AOP 的例子，能说说吗？介绍了 AOP 的优点，但却没有提到它的缺点，但其实任何技术都是有两面性的，你觉得 AOP 的缺点都有哪些呢？

今天我们学习了 MVC 架构中的控制器层，整个控制器的逻辑比较密集，从请求抵达，到转出到视图层去渲染，控制器的逻辑通常包括下面这几步，但是，严格说起来，下面这些步骤的任何一步，根据实际情况，都是可以省略的。我们对比了在原生 Servlet、Struts 框架和 Spring MVC 框架下，上面各个步骤的实现，希望你能够感悟到其中的“套路”。是的，具体某一个框架的配置使用，是很容易学习和掌握的，这当然很好，但那只是死的知识，而这也只是机械记忆。

今天我们学习了 MVC 架构中的视图层（View），对于五花八门的页面聚合技术，我们需要抓住其本质，和前面学习 Model 层的解耦一样，应对软件复杂性的问题，绝招别无二致，就是“拆分”。无论是分层、分模块，还是分离静态模板和动态数据，当我们定义了不同的拆分方法，我们就把一个复杂的东西分解成组成单一、职责清晰的几个部分，分别处理以后，再聚合起来，不同的聚合方法正是由这些不同的拆分方法所决定的。

今天我们详细剖析了 MVC 架构中 Model 层的方方面面，并结合例子理解了贫血模型和充血模型的概念和特点，还介绍了一种典型的模型层的内部层次划分方法，接着介绍了 CQRS 这种将命令和查询行为解耦开的模型层设计方式。其中，贫血模型和充血模型的理解是这一讲的重点，这里我再强调一下：贫血模型，逻辑从模型实体中剥离出去，并被放到了无状态的 Service 层中，于是状态和逻辑就被解耦开了；充血模型，它既包含数据，也包含逻辑，具备了更高程度的完备性和自恰性。

如果你有使用 Java 作为主要语言开发网站的经历，那么你一定听过别人谈论 JSP 和 Servlet。其中，Servlet 指的是服务端的一种 Java 写的组件，它可以接收和处理来自浏览器的请求，并生成结果数据，通常它会是 HTML、JSON 等常见格式，写入 HTTP 响应，返回给用户。

作为特别放送，今天的思考题，我想换个形式。如文中介绍的那样，设计一道合理的面试题其实并不容易，需要综合考虑多个因素。下面我列出了几道面试题，假设今天你就是面试官，你能说说它们中哪些适合作为全栈工程师岗位面试的“主要问题”，哪些不适合吗？A：设计一个算法，把一个小于一百万的正整数，使用罗马数字来表示；B：对一个 Web API，设计一个流量控制系统；C：写一个 C++ 算法，实现 atoi 算法，即将字符串转换为数字；D：设计一个网约车系统；

在上面这三步通用和共性的步骤完成之后，我们就可以正式跳进具体的接口定义中，去确定 URL、参数、返回和异常等通用而具体的形式了。还记得上一讲中对 REST 请求发送要点的分解吗？在它的基础上，我们将继续以 REST 风格为例，进行更深刻的讨论。1. 条件查询/books/123分别查询了 ID 为 123 的图书的全部属性，和该图书的价格信息。/books?你看条件查询书籍，查询条件通过参数传入，指定了作者，要求显示第二页，每页大小为 10 条记录，按照书名降序排列。

今天我们认识并学习了 SOAP 和 REST 这样两种截然不同的风格，前者工整、严谨和细致，后者自由、灵活和简约。两道思考题如下：在做技术比较的时候，文中已经简单介绍了 REST 和 SOAP 的优劣，你觉得，它们各自适合怎样的业务场景呢？有位程序员朋友在应用 RESTful 风格设计用户管理系统的接口时，“删除单个用户”功能的 URL 举例如下，你觉得有哪些问题？今天的内容就到这里，希望你已经享受到了技术学习的快乐，如果你还有余力，请继续学习下面的选修课堂和扩展阅读。

今天我们从 HTTP 的交互局限性引出了网络交互中 Pull 和 Push 的两大模型，比较了它们的优劣。服务端 Push 的方式具备高效性和实时性的优势，而客户端 Pull 的方式令服务端免去状态的维护，从根本上简化了系统。之后我们以 Comet 和 WebSocket 为重点，介绍了服务端推送的不同方式，尤其是用了实际抓包分析，介绍了通过 HTTP “升级”的方式来建立 WebSocket 连接的原理。今天学习得怎样呢？