mod

极客时间专栏/软件工程之美/经典案例解析篇/40 | 最佳实践：小团队如何应用软件工程？.md

@@ -0,0 +1,188 @@
+<audio id="audio" title="40 | 最佳实践：小团队如何应用软件工程？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7a/91/7a7b4a2a7c061cae1589eebab7093391.mp3"></audio>
+
+你好，我是宝玉。经过前期理论知识的学习，你可以开始尝试在实践中去应用所学到的软件工程知识了。
+
+想象一下，现在你要加入一家创业公司，从头组建一个开发团队，一开始只有三五个人，你会怎么去应用软件工程的知识，让你的团队能高效率、高质量地开发软件产品？
+
+或者说，你现在就是在一个小团队，各种流程不规范，开发效率低，软件产品质量不高，你打算怎么应用学到的知识去改善现状呢？
+
+在这一篇里，我将带你一起运用学过的软件工程知识，看如何在小团队中应用软件工程？（在这里我补充说明一下：本文讨论的小团队，不是指大厂的一个小组，而是小公司或者三五个人的小开发团队）
+
+## 小团队在软件开发中存在的常见问题
+
+不知道你有没有在小团队工作的经历，如果有的话，建议你可以自己先总结一下：小团队在软件开发中存在的一些常见问题是什么？
+
+为什么说你需要先自己去发现问题呢？因为在学习完软件工程的理论知识后，并不是说你把所有知识点一股脑儿全应用上就解决问题了，而是要先去发现问题在哪，然后针对这些问题，再去应用软件工程的知识去寻找问题的解决方案。
+
+就像小团队如何应用软件工程这个问题，你首先要先找出来小团队的问题在什么地方，然后去分析这些问题可以应用软件工程的哪些知识，从而找到适合你的解决方案。
+
+我个人有过一段时间的小团队工作经历，也见过很多类似的小团队的开发，就我的经验来说，小团队在软件项目开发上，主要问题体现在以下几个方面。
+
+#### 1.小团队成本敏感
+
+首先，小团队对成本都很敏感，成本是小团队很多问题的根源，对成本的控制也衍生出一系列大公司可能感受不到的问题。
+
+因为控制成本，所以开不出好的薪水，难招到优秀的程序员；因为控制成本，所以进度都催的紧，毕竟多干一天就要多发一天工资；因为控制成本，舍不得在工具上的投入，都得要尽量用免费的、开源的；因为控制成本，通常几个项目并行，一个人可能要同时在几个项目中切换。
+
+#### 2.小团队人少活多
+
+小团队人一般不会多，但是活不一定少。
+
+从分工上来说，通常在大厂前端后端几个人合作完成的事，在小团队就得一个人从前端写到后端了，可能甚至都不会有专业的产品设计和功能测试人员，都是开发兼任。
+
+从人员构成来说，大厂在组建技术团队时会注意梯队的搭配，整个团队像金字塔的结构，顶部有几个特别资深的开发人员，中间有一些经验丰富的，底部的是有潜力但经验比较少的。而小团队就算是运气好，也可能只有一两个技术大牛，更多的是水平一般、经验比较少的。
+
+这样的分工协作和人员构成，导致的问题就是大家每天都很忙，但是感觉技术上积累有限。对个别技术大牛的依赖性强，他们一旦离职，影响非常大。
+
+#### 3. 小团队缺少流程规范
+
+在流程规范方面，恐怕是大家对小团队吐槽最多的地方，也是很多从大厂跳槽到小公司的程序员特别不适应的地方。
+
+项目开发比较随意，拿到需求可能就开始直接写代码了，没有严格的需求分析、架构设计，写完了后简单测试一下就上线了，上线后再修修补补；需求变更是家常便饭；多个项目并行的时候，每个项目的负责人都觉得自己的项目是最重要的，希望你能把他的项目进度往前赶一赶；老板权力很大、想法多变，经常会直接干预项目。
+
+这样不规范的开发流程，导致的结果通常就是开发效率低下，软件产品质量不高，项目计划难以遵守甚至没有计划。
+
+## 小团队如何应用软件工程？
+
+成本敏感、人少活多、缺少流程规范，这几个是小团队在项目开发中存在的主要问题。那么在小团队应用软件工程的时候，我们就需要去解决好这些问题。
+
+成本敏感的问题，如果这个是客观存在的，就没有太好的办法去解决，只能说我们在做一些决策、制定流程的时候，需要充分考虑好成本因素，减少浪费。
+
+人少活多，那么我们就相应地提升个人和团队的整体水平和效率。缺少流程规范，那么我们就建立适合小团队特色的流程规范，让开发流程规范起来。
+
+所以接下来，我就从团队建设、流程建设这两个维度来谈谈如何应用软件工程。
+
+#### 1.团队建设
+
+也许你会觉得好奇，软件工程的各个知识点，都是在讲过程、方法、工具，似乎都没有讲人的，但为什么在实践的时候，反而最先考虑的却是团队建设？
+
+但你要换个角度想就很容易理解了：软件工程上讲的所有的过程、方法和工具，最终还是落实在人身上，需要人去基于开发过程去制定流程遵守流程；需要人去应用软件工程中总结好的方法；需要人去使用工具。如果团队对软件工程缺少认识，那再好的方法和工具也无法落地。
+
+所以要实施好软件工程，也要同步做好团队建设，让你的团队有一点基础的软件工程知识积累，有几个技术骨干可以帮助一起推广和实施。如果对软件工程知识的推广能扩大到团队之外，比如你的老板和业务部门，那么在后续推进一些流程规范，会起到事半功倍的效果。
+
+团队建设，绕不开几件事：招人、培养人、管理人和开除人。
+
+- **小团队如何招人**
+
+小团队招人，难点在于成本有限，开不出很高的工资，品牌也不够吸引人，招人的时候相对选择有限，能否直接招到技术大牛就得看运气了。**但这不意味着就要大幅降低标准，比较现实的方法就是招有潜力的程序员培养。**
+
+那么怎么知道候选人是不是有培养潜力呢？可以参考我们专栏《[27 | 软件工程师的核心竞争力是什么？（上）](http://time.geekbang.org/column/article/93062)》这篇文章，考察候选人的学习能力、解决问题能力。
+
+我以前在创业团队时，每年会招不少实习生，然后对实习生进行培训，参与实际项目，最后留下来一批优秀的有潜力的实习生，在一两年后，就能成长的不错，能独立完成小型的项目。
+
+但我在这种方式上也犯过错误，就是新人的比例太高，中间断层，日常的技术指导和代码审查一度跟不上，导致代码质量低下。所以在招人时，也不能一味节约成本，还要注意梯队的建设，中间要有几个有经验的技术骨干帮助把控好代码质量。
+
+- **小团队如何培养人**
+
+在培养人方面，相对来说，小团队不像大公司有完善的培训制度，资源也有限，难以请到外面的人来讲课，**所以培养人主要还是要靠内部形成好的学习分享的机制。**
+
+在大厂，新人加入，通常会指定一个Mentor，也就是导师或者师傅，可以帮助新人快速融入环境，新人有问题也可以随时请教。这种师傅带新人的机制其实对小团队一样适用，对新人来说可以快速融入，及时获得指导，对于师傅来说，通过带人，也能促进自身的成长。
+
+除了有师傅带，新人的技术成长，更多还是来源于在工作过程中不断实践和总结，在这个过程中，及时准确的反馈很重要。软件工程中，像代码审查、自动化测试、持续集成都可以帮助对工作结果进行及时反馈。
+
+代码审查，可以帮助团队及时发现代码问题，也能促进团队相互学习，代码风格统一；自动化测试，可以对代码结果马上有直观的反馈，有问题早发现修正；持续集成也是通过频繁地集成频繁地给出有效反馈，及早发现代码问题。
+
+在小团队推行这样好的开发实践，让团队获得及时准确的反馈，有助于整个团队的成长。
+
+另外，内部的技术分享也是很好的共同提升的方式，对于听的人来说可以学习到一些新鲜的知识，对于分享的人来说，准备一个技术分享，本身就是最好的学习总结方式。我以前在团队会定期组织这样的技术分享，不止我自己，每个团队成员都会去分享，整个团队分享讨论的技术氛围形成的很好。
+
+还有在分工方面，不要因为一两个技术大牛能干，就把大部分工作都让他们做了，这其实对团队整体是不利的，“大牛”的发展也遇到瓶颈，而其他人缺少锻炼。所以最好是让“大牛”一半的精力负责一些重要的像架构设计、框架开发的工作任务，同时还要有一半的精力在代码审查、带新人等方面，帮助其他人一起成长，整个团队的发展才能更健康。
+
+- **小团队如何管理人**
+
+因为小团队人数不多，对人的管理上，可以不需要像大公司一样用复杂的组织结构，用复杂的管理制度。**小团队的管理，核心在于营造好的氛围，鼓励成员自我驱动去做事。**
+
+其实这个理念和敏捷开发的理念是吻合的。在专栏文章《[05 | 敏捷开发到底是想解决什么问题？](http://time.geekbang.org/column/article/84351)》中，我也提到了：敏捷开发的实施，离不开扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性。
+
+要鼓励团队自驱动，具体做法上也可以参考敏捷开发的一些做法，比如说通过任务管理系统和看板，让团队成员自己领取开发任务；在制定一个迭代的计划的时候，让团队成员一起参与对任务的打分，参与计划的制定。
+
+除了这些鼓励成员自驱动，发挥主动性的做法，在营造好的团队氛围上，还要注意的就是遇到线上故障、进度延迟这些不太顺利的情况，更多的是提供帮助，一起总结复盘，而不是甩锅问责。
+
+- 有关开除人
+
+在应用软件工程的时候，团队中可能有些人会成为障碍，要么是能力不足无法落实，要么是态度有问题抵触软件工程的实施。
+
+在这种情况下，首先对于有问题的成员肯定是要努力挽救，如果是能力不足，就给予帮助，给时间成长，对于态度有问题的，明确指出其问题，限期改正。但如果最终结果还是达不到预期的话，那就必须要果断地将这些成员淘汰。
+
+#### 2. 流程建设
+
+小团队被人诟病较多的地方就是在于流程规范的缺失，但像大公司，流程规范繁多，也容易造成效率低下，人浮于事的情况，这也就是为什么现在大公司的开发团队也在分拆，从大团队拆分成小组，精简流程规范。
+
+对于小团队，一开始也不宜有太多的流程规范，不然，如果流程不合适反而会成为一种束缚，最好只是先设置最基本的流程规范，然后在实践过程中针对团队特点和业务特点去逐步完善。
+
+那么哪些流程是软件开发中最基本的流程规范呢？
+
+- **选择适合你的软件开发模型**
+
+现在的软件开发，已经不再像以前那样采用原始边修边改的开发模型，而是应该采用科学的开发模型。我们专栏一开始就有大量的篇幅介绍各种开发模型，大的方面有瀑布模型和敏捷开发，基于瀑布模型还有很多衍生模型。
+
+那么小团队应该采用哪种开发模型比较合适呢？
+
+也许你会认为应该采用敏捷开发。敏捷开发确实是一种非常适合小团队的开发模型，整个开发过程非常有效率。如果能采用敏捷开发是最好的。
+
+但需要注意的是，如果你的团队是以瀑布模型为主，大家都有丰富的瀑布模型开发经验，但是对敏捷开发都没有实践过，对于敏捷开发的各项活动还不熟悉，还没能充分理解敏捷的价值观和原则，那么最好不好贸然直接换成敏捷开发。
+
+因为这样做的话，团队在一段时间内，都需要去摸索如何用敏捷开发，可能反而会降低开发效率。
+
+对于团队只熟悉瀑布模型这种情况，有条件的话，聘请外部的敏捷顾问帮助实施敏捷开发是个不错的选择。如果条件有限，可以先尝试逐步借鉴敏捷开发中好的实践。
+
+敏捷开发中哪些实践是适合小团队借鉴的呢？
+
+首先在开发周期上，应该缩短交付的时间，使用快速迭代的开发模型。因为小团队的一个特点是需求变化快，要求交付的速度快，那么快速迭代或敏捷开发就是一个合适的开发方式。即使团队习惯了瀑布模型开发，切换到快速迭代也会比较容易，只需要把大瀑布拆分变成小瀑布。
+
+具体在实施上，可以缩短并固定开发周期，比如说每2～4周可以发布一个版本。在做迭代的规划时，优先选择当前最核心最重要的功能；在一个版本内，不轻易接受新的需求变更，有需求变更放到下一个迭代中；在迭代时间结束了，无论新功能是否开发完成，都按时发布新版本，没完成的放入下一个迭代。
+
+通过这样的变化，可以保证在一个迭代中整个团队的开发状态是稳定的，不需要受到需求变更的干扰，也可以慢慢形成适合团队的迭代节奏。
+
+另外在会议上，敏捷Scrum的几个会议也可以借鉴，像每日站立会议，可以帮助团队及时了解项目进展，解决进度上的障碍；每个迭代的计划会议，可以让大家一起参与到计划的制定中；每个迭代的验收会议，可以让业务部门、老板及时的验收工作成果，看到大家的工作进展；每个迭代的回顾会议，可以帮助阶段性复盘总结，不断优化开发流程。
+
+还有基于看板的任务可视化，也可以帮助团队直观的看到当前迭代中的任务进度，可以主动选取任务，而不需要去问项目经理下一步该做什么。
+
+以上这些内容，也可以参阅专栏文章《[06 | 大厂都在用哪些敏捷方法？（上）](http://time.geekbang.org/column/article/84652)》，里面有更详细的解释。
+
+- **构建基于源代码管理工具的开发流程**
+
+很多小团队开发质量低，开发混乱的一个原因就是没有使用源代码管理，也没有一套基于源代码管理的开发流程。在专栏文章《[26 | 持续交付：如何做到随时发布新版本到生产环境？](http://time.geekbang.org/column/article/92587)》和《[30 | 用好源代码管理工具，让你的协作更高效](http://time.geekbang.org/column/article/93757)》中，对于如何基于源代码管理工具构建和开发已经有了非常详细的介绍，这些开发流程一样适用于小型团队。
+
+有一点要注意的是，小型团队完全没有必要自己去从头搭建自己的源代码管理工具、持续集成工具，应该尽可能采用在线托管的服务，这样可以节约大量搭建、维护工具的人力和时间成本。
+
+类似的策略也应体现在技术选型上，小团队应该尽可能使用现成的工具、框架，而避免自己造轮子，把主要精力放在业务功能的开发上面。
+
+- **建立外部提交需求和任务的流程**
+
+小团队在流程规范上混乱的一个体现是，业务部门包括老板对于提交开发任务非常随意，可能直接找某个开发人员私下让改一个需求，增加一个功能，导致开发人员不能专注于任务开发，经常被打断。还有多个项目并行而资源又紧缺的情况下，每个项目负责人都觉得自己的业务是最重要的，希望能尽快完成。
+
+如果你有过在火车站售票口排队买火车票的经历，你会发现，无论人有多少，只要大家有序排队，售票窗口就能按照先后顺序为大家服务，如果大家一窝蜂挤上去买，就会乱成一团，如果有人插队，那么其他人的进度就会受影响。
+
+其实软件项目开发也是类似的，对于开发团队来说就像是售票窗口，买票的人就相当于一个个的开发任务，无论开发任务有多少，只要你将这些开发任务排成队列，就可以有序地解决。如果一个业务团队的开发任务特别紧急要插队，那么意味着其他业务团队的任务就必须要受影响，那么就需要大家一起去协调。如果你不去通过流程规范任务，那么任务一多，必然就会乱成一团，无论是开发团队内部还是外部，都不会满意。
+
+建立外部提交需求和任务的流程，可以参考专栏《[14 | 项目管理工具：一切管理问题，都应思考能否通过工具解决](http://time.geekbang.org/column/article/87787)》的内容，让所有人都基于任务跟踪系统去提交需求和开发任务，所有任务都先进入Backlog（任务清单），然后在每个开发迭代中，去按照优先级选择当前迭代的任务，如果有优先级的冲突，应该需要事先沟通解决。对于提交需求和任务的人，也能通过任务跟踪系统，及时的了解到任务的进展。
+
+在团队之外推行这样的流程是会有一定阻力的，最好是能事先去找几个关键的业务负责人私下沟通，取得理解和支持，让他们知道这样做对他们的好处，比如说可以更好地跟踪任务的进展，让开发效率更高，更好地为他们完成任务。
+
+以上这几个流程，就是在小团队的软件开发中应用软件工程，需要建立几个最主要的的流程，把这几个基础流程建立起来后，就可以帮助小团队的开发，从无序逐步进入有序。
+
+## 总结
+
+今天，我带你一起分析了小团队在软件项目开发上的主要问题是：对成本敏感、人少活多和缺少流程规范。相应的，我们就需要从团队建设和流程建设两个地方入手，去解决这些问题。
+
+在团队建设方面，需要从四个方面入手：招人、培养人、管理人和开人。
+
+- 招人的时候，找一些有潜力的培养，也要注意梯队建设，中间有技术骨干补充；
+- 对团队的人才要悉心培养，通过给新人安排师傅的方式培养新人，日常注意代码审查，内部技术分享是个不错的共同提高的方式，技术高手要注意不只是闷头干活，也要承担一定的带人的工作；
+- 管理人核心在于营造好的氛围，鼓励成员自我驱动去做事；
+- 对于不适合团队的人也不要手软，及时的淘汰。
+
+在流程建设方面，要着重建设好三个方面的流程：
+
+- 选择合适的软件开发模型，建立项目开发流程；
+- 构建基于源代码管理工具的开发流程；
+- 建立外部提交需求和任务的流程。
+
+团队建设和流程建设是在小团队中应用软件工程的关键，通过团队建设让团队成员有共同的软件工程意识，有实施软件工程的基础，通过流程建设让软件工程好的实践流程化、工具化。
+
+## 课后思考
+
+你有小团队的项目经历吗？你觉得小团队面临的主要问题是什么？你觉得可以从哪些方面在小团队中应用软件工程？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/经典案例解析篇/41 | 为什么程序员的业余项目大多都死了？.md

@@ -0,0 +1,124 @@
+<audio id="audio" title="41 | 为什么程序员的业余项目大多都死了？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/41/0c/4114763a8e595de46437008881fce90c.mp3"></audio>
+
+你好，我是宝玉。对于不会写程序的人来说，想做一个软件项目，就得找程序员帮忙写程序。而对于程序员来说，想做一个软件项目，写程序不是问题，产品设计自己也能做一点。所以对于很多程序员来说，一旦有了一个想法，可能就会利用工作之外的时间，做点自己的业余项目（也叫Side Project）。
+
+然而大部分项目，都是怀着美好的期望开始，结果做到一半就无疾而终，就算少数坚持到了上线发布，最终还是因为少人问津而不得不放弃。
+
+所以今天将带你一起分析一下，为什么程序员的业余项目大多都死了？怎么样可以借助学习到的软件工程知识提升业余项目成功的概率？
+
+## 为什么程序员的业余项目大多都死了？
+
+作为程序员，我也很热衷于做业余项目，周围的程序员朋友们也有不少做业余项目的案例，通过对这些案例的观察和分析，我觉得程序员做的业余项目，主要死于以下这些情况。
+
+#### 1. 想法大，时间少
+
+我有个朋友，前一段突然有了一个想法，想做一个类似于Excel的基于网页的在线电子表格程序，这是个很大的想法，毕竟微软和谷歌都是有一个团队在完成这样的项目。
+
+但他觉得如果只是实现最核心功能还是可行的，于是激情满满地找资料，写原型代码。然而现实还是很残酷的，他上班就忙，经常加班，下班还要带娃，留给自己的时间其实不算多，一段时间看不到成果后，慢慢的激情就消逝了，这个项目也就不了了之了，而现在他已经又在尝试其他项目了。
+
+这是一个常见的现象，很多程序员在业余做项目开始之前激情满满，经过一段时间没有进展，没有正向反馈，很容易就激情消逝，不想再继续了。尤其是一段时间后，可能又有新的项目想法了，于是就又开始了一个新的循环。
+
+#### 2.过于追求技术，缺少约束
+
+在公司的项目中，我还是比较保守的，毕竟要受限于项目的成本、时间和范围的限制，而且有Dead Line的强约束，所以不会太激进，能稳定上线运行是第一位的。而我一旦去做业余项目，就会陷入过于追求技术的困境。
+
+我前年的时候，想对自己的一个网站进行升级，如果用传统的熟悉的技术方案应该不需要太长时间，但我想体验当时比较新的React Universal技术，后端API要使用当时时髦的GraphQL，要考虑多数据库的支持，还要用上WebSocket保持内容及时更新。结果有些知识还需要边学边用，虽然在学习这些知识的时候收获不小，但是项目进度却是惨不忍睹，到今天还只有一点雏形。
+
+程序员的业余项目，因为缺少成本、时间和范围的限制，没有设置Dead Line约束，所以经常会天马行空，只为了追求技术上的兴奋点，恨不得把新酷技术都用上。
+
+但如果看看项目的定义：
+
+> 
+项目是指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。（摘自百度百科）
+
+
+你就可以发现，项目是要有目标要有约束的。一个缺少目标和约束的项目，是难以成功的。
+
+#### 3.缺少产品能力和运营能力
+
+有一些程序员，是有做产品的梦想的，希望能打造一款好的产品，解决工作生活中的一些问题，或者就是想通过做产品去赚点钱。其实这样的不乏成功案例，比如像业余时间打造出知名的iOS应用Pin和JSBox的[钟颖](http://sspai.com/post/46390)，还有像[图拉鼎](http://sspai.com/post/30876)这样的人，他们先是程序员，后来因为有了成功的产品而做独立开发者的例子。
+
+但这样的例子并不多，普遍存在的情况是，当程序员们真正要去打造产品的时候，却发现要做一个产品并不是那么容易的事情，缺少产品能力就无法设计出好的产品，缺少运营能力就算产品做出来也鲜有人问津。而那些真正成功的独立开发者，无不是能兼顾产品设计能力和产品运营能力，既能设计出真正解决用户需求的产品，又能通过一定的运营让用户了解产品，为之买单付钱的人。
+
+## 怎样提升业余项目成功的概率？
+
+想法大，时间少；过于追求技术，缺少约束；缺少产品能力和运营能力。这几点是程序员业余项目失败的主要原因。如果要应用软件工程知识来寻找这些问题的解决方案，你会想到什么方案呢？
+
+#### 1. 怎么样让项目不至于半途而废？
+
+想法大，时间少怎么办？怎么样让项目不至于半途而废呢？
+
+回想一下专栏文章《[08 | 怎样平衡软件质量与时间成本范围的关系？](http://time.geekbang.org/column/article/85302)》中的金三角理论，在这一篇中，我解释了如何去平衡软件质量与时间成本范围的关系，今后你会发现项目中很多问题都能应用到金三角的理论。
+
+比如说，想法大，其实就是范围大，按照金三角的理论，你要去固定一条边或者两条边，然后去调整剩下的边。
+
+对于业余项目来讲，其实时间是很难去控制的，也就是你不可能像每天上班那样投入大量的时间在上面，所以这条边要被固定起来。
+
+然后看成本这条边，虽然理论上来说你可以花钱请人帮你，也可以花钱买成熟的商业组件，但作为一个业余项目，一般来说前期不会投入大成本的。你也可以假定它是固定的。
+
+那么最适合调整的边就是范围这条边，毕竟作为一个业余项目，你可以先实现最核心的功能。可以采用 MVP（minimum viable product，最小化的可行性产品）的模式，一开始只推出最核心的功能，满足用户最核心的需求，然后在用户的使用过程中收集反馈，进一步升级迭代。
+
+前不久一个朋友做了一款播客的应用，他就是采用的MVP的开发模式，先快速发布了一个只有核心功能的版本，甚至还很多Bug。发布后邀请了几个朋友试用，收集了反馈，并且也把发现的Bug 修复了，再逐步增加新功能。这样几个迭代后，他的App已经登上了新闻分类的排行榜。如果一开始他就想的是要做一个很大的项目，也许到现在还在开发中呢。
+
+即使程序员做的是业余项目，还有必要补充的一点就是：**在决定做什么项目之前，一样要充分考虑项目的可行性研究。**关于这一点，你可以参考专栏文章《[09 | 可行性研究： 一个从一开始就注定失败的跨平台项目](http://time.geekbang.org/column/article/85730)》去从经济可行性、技术可行性还有社会可行性方面，去分析一下项目是不是真的可行，再动手不迟。
+
+#### 2.怎么避免陷入过于追求技术，项目难以交付的困境？
+
+过于追求技术，缺少约束是程序员业余项目失败的另一个主要原因。
+
+程序员追求技术是天性，这一点其实也不是坏事，重点是要有所约束，毫无约束的结果就是迷失在技术中，而忘记了项目的整体。
+
+这其实也是我在专栏一开始就写的《[02 | 工程思维：把每件事都当作一个项目来推进](http://time.geekbang.org/column/article/83277)》中提到的，要把业余项目也当作一个正式的项目，做你的业余项目时，也要站在项目的整体去思考项目的进展，而不是沉迷于局部的技术实现。
+
+所以你有业余项目的话，也要像专栏文章《[11 | 项目计划：代码未动，计划先行](http://time.geekbang.org/column/article/86817)》中提到的那样，去做项目计划，去设置里程碑。还要敢于把计划和里程碑分享给你的家人和朋友们，公开的做出里程碑的承诺，让他们帮助监督你的计划执行。
+
+当你有了一个可行的计划，有了真正的Dead Line，你的项目交付就有了基本的保障。
+
+我前些年运营过网站，一个针对我的母校西北工业大学校友们的论坛网站叫开放实验室，我需要负责这个网站的日常运营和程序开发，所以每次升级之前，我都会在论坛发帖子公布我的升级计划，设定一个上线时间，这样网站的用户会监督我的项目进度。有了进度的压力，就会逼着我必须按时完成，而不是老想着用什么新酷的技术。
+
+在你的业余项目难以交付的时候，记住一句话：**Dead Line就是第一生产力。**
+
+#### 3. 怎么弥补你的短板？
+
+产品能力和运营能力是大部分程序员的短板。
+
+关于产品设计，我们专栏需求分析篇的几篇文章可以参考。《[17 | 需求分析到底要分析什么？怎么分析？](http://time.geekbang.org/column/article/88833)》可以帮助你去分析用户真正的需求是什么，从而让你可以做出来用户想要的，而不是自己凭空想象出来的用户需求。
+
+产品能力的锻炼不是一朝一夕就能炼成的，但日常多模仿，多实践，还是能做出来不错的产品设计，我在专栏文章《[19 | 作为程序员，你应该有产品意识](http://time.geekbang.org/column/article/89480)》中如何培养产品能力上，给出了一些具体的建议。
+
+比如说你可以从解决自己的需求，解决家人朋友的需求开始，设定一个小的产品目标，然后借鉴类似的产品，模仿它们的产品设计、交互设计，就能做出来一个基本可用的产品。
+
+像UI设计，其实现在无论是网站的UI设计还是App的UI设计，都趋向于标准化，对于一个业余项目，使用一些标准模板，或者花点钱购买一套漂亮的界面模板，都是不错的选择。
+
+对于产品的运营，这一点很遗憾，软件工程重点是讲如何做项目的，并没有太多运营相关的知识。我个人的一点经验就是，如果你要运营一款产品，你需要想清楚以下几个问题：
+
+- 想清楚你的产品能给用户带来什么样的价值？帮助用户解决什么问题？
+- 商业模式是什么？也就是用户是不是会为你的产品付钱？或者你的产品通过什么方式赚钱？
+- 如何让用户知道你的产品？如何让用户知道你产品所能带来的价值？
+
+只有想清楚了你的产品的核心价值是什么，才好去针对性的运营你的产品。具体产品的运营上，可以找你的朋友作为第一批用户，然后去像[Product Hunt](http://www.producthunt.com)这样的网站发帖子自荐，还可以通过微博、Twitter这样的社交媒体宣传。
+
+除了自己去学习产品知识和运营知识之外，其实还有一种方式，就是组建一个小团队，找到志同道合的人一起，你写程序，有人做产品设计，有人负责运营推广，大家取长补短，一起把产品做好！
+
+## 总结
+
+今天带你一起分析了程序员的业余项目失败的原因。想法大，时间少；过于追求技术，缺少约束；缺少产品能力和运营能力。这几点是程序员业余项目失败的主要原因。
+
+针对想法大、时间少的问题，可以借助软件项目金三角的理论，去缩小范围，在做项目时，可以采用MVP的开发模式，先实现核心需求，再逐步增加功能。
+
+针对过于追求技术、缺少约束的问题，应该要对你的项目制定计划，设定里程碑，把时间点告诉你的家人和朋友，让他们监督你执行，通过Dead Line来保障项目的进度。
+
+针对缺少产品能力和运营能力的问题，需要有针对性地去学习相关知识，也可以去组建小团队，弥补这些方面能力的不足。
+
+最后，即使程序员们的业余项目很可能会是以失败告终，我做过很多失败的业余项目，但我还是强烈的建议你多尝试做一做业余项目。因为做业余项目，即使项目失败了，一样可以让你收获很多：
+
+- 通过业余项目，你可以学习和使用工作中不会使用的技术。你工作中做后端开发，你业余项目完全可以体验iOS App开发。
+- 通过业余项目，你有机会去按照自己的想法去实现。很多时候在工作中，因为你无法去做决策，无法改变架构的设计或产品的设计，而在自己的业余项目中，你可以完全按照自己的想法去尝试，去证明自己。
+- 通过业余项目，可以锻炼你的大局观和工程思维。当你真的去自己负责一个项目时，就会更多地去站在项目的整体去思考一个项目，而不是局限于专业领域。
+- 通过业余项目，帮助你更好地在项目中沟通。在做过业余项目后，在工作中，和产品经理、测试沟通，你会更懂他们，因为他们的工作你也体验过了，你会体会到他们的工作其实不像你最初想的那么容易。
+
+## 课后思考
+
+你有做过业余项目吗？你有经历过哪些成功的和失败的业余项目经历？你从中收获的经验教训是什么？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/经典案例解析篇/42 | 反面案例：盘点那些失败的软件项目.md

@@ -0,0 +1,169 @@
+<audio id="audio" title="42 | 反面案例：盘点那些失败的软件项目" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/dd/e4/dd7f4c55ed936ce52a5fd52f2d27bbe4.mp3"></audio>
+
+你好，我是宝玉。我想你日常一定看到过很多项目失败的案例，有些失败项目的案例甚至超出我们的想象，比如说我的朋友圈就被两个项目刷过屏，一个是号称史上最烂的开发项目，开发12年，六百万行代码；一个是美国联邦调查局的一个软件项目，花了1.7亿美元，最后变成了豆腐渣工程。
+
+也许大多数人看完这类文章后，会当作一个有趣的故事，觉得他们软件工程水平太差了，居然会把项目做成这样。当你学习完软件工程知识后，再看到这些项目失败的案例，不妨从软件工程的角度来分析一下，这些项目失败的真正原因是什么？你能从中获得什么启发？
+
+## 什么样的软件项目算是失败的项目？
+
+如果我们说一个项目是失败的项目，那么怎么算是一个失败的项目呢？
+
+项目管理协会（PMI）认为成功的项目必须满足六个条件：
+
+1. 按时交付。
+1. 成本在预算范围内。
+1. 能按照当初的设计正常运行。
+1. 有人使用。
+1. 满足项目最初的目标。
+1. 项目出资方对项目满意。
+
+相应的，如果上面有一个或者多个条件没有满足，那么项目就有可能是失败的，比如说：
+
+1. 没能按时交付。
+1. 成本超出预算。
+1. Bug太多，无法按照当初的设计正常运行。
+1. 产品没有得到市场认可，没有人使用。
+1. 产品偏移了最初的目标。
+1. 项目出资方不满意。
+
+而那些特别失败的项目，往往是多个条件甚至所有条件都不能满足，并且时间、成本、交付结果跟最初目标都相差很大，无疑都造成了巨大的损失。
+
+IEEE（电气和电子工程师协会）有一个专门的网页，把过去十年间，那些著名的失败软件项目，做了一个墓碑来展示，墓碑里的这些项目加起来的损失大约700亿美元。WikiPedia上也有一个网页（[List of failed and overbudget custom software projects](http://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects)）列出来那些损失严重的软件项目，也是惊人的数字。
+
+<img src="https://static001.geekbang.org/resource/image/57/e8/57495077b46d33c2d7f4322dfd7676e8.png" alt="">
+
+（图片来源：[Monument to Failure](http://spectrum.ieee.org/static/monuments-to-failure)）
+
+而这些软件项目的失败，很大程度上是可以预测和避免的。如果把问题简简单单归结为软件工程水平太差了，或者是项目实施者的水平太差了，那么我们就无法真正的从这些失败中吸取教训，在下一次还会再犯同样的错误。
+
+## 分析失败软件项目的原因
+
+在航空业，如果一架飞机坠毁，会有专业的调查小组去对飞机失事原因进行详细调查，比如分析说当时的天气情况、飞机的维护记录、飞行员的性格特点，平时受到的培训是怎样的，航空公司的文化，对安全的重视程度等等，从而找到事故的根源，并且提出相应的改进方案，避免类似的灾难再次发生。
+
+软件项目其实也是类似的，对于一个失败的软件项目案例，要去分析：外部环境、技术管理、项目管理和组织文化，这样才能帮助你找到项目失败的根源。
+
+- 外部环境
+
+在调查员去调查飞机失事原因的时候，首先会看的是不是外部环境导致的，例如恶劣的天气环境。分析软件项目失败原因，也可以首先看看外部环境。
+
+如果你去看看历史上那些有名的失败的项目案例，其中政府主导的项目占大多数，而且通常主要因素不是成本，而是各种政治因素导致的不切实际的项目进度，或者是频繁变更的需求，从而严重的影响了成本和质量。
+
+而对于商业软件项目，很多是由于缩减成本导致的。因为商业竞争的大环境，企业为了节约成本，总是希望用更少的人做更多的事情。
+
+还有一些常见的场景就是在一个项目开始之前，销售为了拿下项目，通常会过度夸大项目的成果，而又会相应的压缩项目预算、时间，并且也可能低估了技术实现的难度，最终项目要开发的时候，开发人员才发现根本无法如期完成当初承诺的项目目标，最终导致项目失败。
+
+- 技术管理
+
+在调查飞机失事原因时，调查完外部环境，还要分析是不是飞机本身设计原因导致的，比如前不久的波音737 MAX飞机事故，就是因为软件故障导致的。类似的，分析软件项目失败原因，也一样要去分析技术管理上的问题，很多软件项目失败的原因也是技术原因导致的。
+
+比如说在项目中使用了不成熟或不熟悉的技术，最终导致技术不可控，或者浪费大量的时间在技术的学习上。
+
+项目的规模也会导致技术复杂度直线上升，想象一下，做一个普通的个人网站和做一个淘宝这样的网站，复杂度不可同日而语。通常越大的项目，技术越复杂，需要考虑各种软件硬件的交互，服务之间的耦合。也就是说，项目规模越大，失败的概率也更大。
+
+- 项目管理
+
+调查飞机失事，飞行员是重点调查对象，因为飞行员直接决定了飞机是否能安全行驶。对于软件项目来说，项目经理在软件项目中起着至关重要的作用。很多项目失败不是因为外部环境导致的，也不是技术原因，而是因为糟糕的项目管理。
+
+在一个软件项目中，项目经理掌握了资源的分配，还要制定项目的计划，对任务进行分配，组织分工协作，管理风险，项目成员的日常沟通等等。而这些决策通常很难量化，需要基于当时的情况进行权衡，一旦这些决策出现大的失误，就会导致项目的失败。
+
+- 组织文化
+
+在飞机失事后，调查人员调查的最后一个领域就是所属航空公司的文化环境，看航空公司是不是足够重视安全。在软件项目中，一个开放、平等、注重沟通协作的团队或组织更容易及早发现和解决问题。
+
+就像文章开头提到的美国联邦调查局的项目，当有雇员指出来项目中的问题，最后的结果竟然是被扫地出门。
+
+当然，我们在分析盘点那些失败的软件项目时，从多个方面去分析，就是为了能找出这些项目失败的根本原因，从而避免类似的错误再次发生。
+
+## 盘点那些失败的软件项目
+
+接下来，我们来一起盘点几个著名的失败的软件项目，看看这些案例可以给我们的日常开发带来哪些启示。
+
+在分析这些案例时，我会先分别从外部环境、技术管理、项目管理和组织文化这几个方面去分析问题和原因，最后一起总结从这些案例中收获的经验教训。
+
+#### 案例1. 来自地狱的项目
+
+**案例描述：**
+
+这个案例来自法国政府，当时参与项目的一名项目成员专门为这个项目开了一个博客叫[ProjectFailures](https://projectfailures.wordpress.com)，将这个项目描述为来自地狱的项目。原计划2-3年开发，结果干了十几年都没有完成，最终以项目负责人被以欺诈罪关进监狱而告终。详细内容可以查看中文版本：《[开发12年 整整6百万行代码：史上最烂的开发项目长这样](http://zhuanlan.zhihu.com/p/39827365)》。
+
+**案例分析：**
+
+- **外部环境：**法国政府官员腐败，对于项目进度并没有施加压力；
+- **技术管理：**没有好的开发实践，完全C++开发，600万行代码，版本控制一团糟；
+- **项目管理：**糟糕的项目管理，团队成员55人，35名经理，20名开发人员，管理人员比开发人员还多；不断开会，只是展示PPT；
+- **组织文化：**禁止超过9点打卡，禁止喝咖啡等奇葩要求。
+
+#### 案例2. 美国联邦调查局虚拟案件文档系统
+
+**案例描述：**
+
+FBI（美国联邦调查局）虚拟案件文档系统的项目开始与2001年，项目初始目标是3年内将原有的FBI案件文档管理系统升级，但因为911恐怖袭击事件爆发，项目目标从升级变成了重写。最终2005年项目宣布废弃，而此时已经在这个项目上花费了1.7亿美元。有关项目的细节可以参考：《[著名豆腐渣软件项目：美国联邦调查局虚拟案件文档系统](http://blog.jobbole.com/51919/)》。
+
+**案例分析：**
+
+- **外部环境：**FBI没有真正懂技术的负责人领导和管控项目，对承包商缺少控制；
+- **技术管理：**无法解决项目的复杂性，系统在设计上不完整，不充分，不到位，以至于在现实场景中完全无法使用，上线前没有测试；
+- **项目管理：**开发方和客户之间沟通不畅；频繁需求变更，项目管理混乱，外行领导内行；
+- **组织文化：**指出问题的雇员反而被调查和开除。
+
+#### 案例3. 微软Vista项目
+
+**案例描述：**
+
+微软的Windows Vista项目开始与2001年7月，预计2003年发布。比尔盖茨为Vista提出了三大目标：1. 完全使用C#提升开发效率；2. 使用数据库作为新的文件系统WinFS；3. 使用全新的显示技术Avalon （后来改名为WPF），打破桌面软件和网站的用户界面界限，提升微软竞争力。
+
+目标非常好，但技术难度非常大，结果三年后也未能开发完成，不得不在2004年对目标进行调整：不用 C#、取消 WinFS、删改 Avalon ，一开始的三大目标就这样被完全否决，最终2007年才发布Vista。参考文章：《[五年磨砺:微软Vista开发过程全记录](http://blog.51cto.com/jiayu/22476)》。
+
+**案例分析：**
+
+- **外部环境：**在目标的设定上，主要不是为了满足用户需求，而是为了商业上的竞争需要；
+- **技术管理：**技术上难度过大，超出团队控制范围，无法完成任务；
+- **项目管理：**比尔盖茨对项目直接干预较多，项目周期太长；
+- **组织文化：**盖茨制定目标后，核心团队明知困难，却不敢也没有反对，当看到任务无法完成时，他们不再努力工作，只想着如何推卸责任。
+
+通过对这些项目的分析，再结合我们之前学习过的软件工程知识，其实软件工程对这些问题都有方案可以应对。
+
+在设定项目目标的时候，如果真正的将可行性分析落到实处，那么像Vista这样的技术不可行的项目目标，也许一开始就可以进行调整，而避免后续更大的损失。
+
+如果在项目开始的时候，有认真的对需求进行分析，和客户有很好的沟通，对于需求的随意变更有管理和控制，那么像FBI这样的项目，就有机会做出来满足用户需求的软件项目。
+
+在项目开发之前，如果做了架构设计，做了技术选型，那么像法国政府项目、FBI项目，也许可以有更简单可行的技术方案，要知道架构设计就是控制技术复杂的最好手段。
+
+在项目开发的时候，如果做好版本控制，持续集成，自动化测试，那么像法国政府项目、FBI项目，质量上就更有保障，不至于一测试全是问题。
+
+在设置项目周期的时候，如果能缩短版本发布周期，尽快发布第一个版本，那么很多延期本可以避免或者不至于那么严重。想想看法国政府项目花了12年，如果他们在第一年内能先发布一个简单的版本，后续再逐步迭代，也许结果会完全不一样。
+
+缩短项目周期也是微软在Vista项目上收获的一大教训，在Vista之后，微软的项目周期都大幅缩短，而且发布频率也大幅提高，每天都有内部测试版本发布。缩短周期后，可以尽早发布，尽早验证项目的可行性，也让测试可以尽早介入。
+
+在团队的文化上，如果日常营造平等的沟通协作的氛围，让项目成员敢于提出不同的意见，那么像FBI、Vista这样的错误也许可以早点被修正。
+
+类似于这样的项目还有很多，比如有一本书叫《[梦断代码](http://book.douban.com/subject/3142280/)》，讲述了一堆优秀程序员，一起开发一个大型的开源项目，最终如何走向失败的过程，有兴趣可以看看。邹欣老师对这本书也有非常独到的点评：《[梦醒时分 - 梦断代码读后感](http://zhuanlan.zhihu.com/p/19970642)》
+
+以后你遇到类似的案例，也可以尝试去对它们进行盘点分析，找出它们失败的根本原因，能从中吸取教训，避免类似错误发生。
+
+## 总结
+
+今天我带你一起学习了如何从软件工程的角度分析失败的软件项目。
+
+通过借鉴航空业对飞机坠毁原因的调查，也可以从四个方面去分析软件项目失败的原因，那就是外部环境、技术管理、项目管理和组织文化。
+
+如果细化一下，还可以总结出一些具体的常见的失败原因：
+
+- 不切实际或者不明确的项目目标；
+- 对项目所需要的资源估算不准确；
+- 需求不明确或者频繁变更；
+- 没有对风险进行有效管理；
+- 和客户之间沟通不畅；
+- 无法解决项目的复杂性；
+- 没有好的开发实践；
+- 糟糕的项目管理；
+- 上层的政治斗争；
+- 商业压力。
+
+其实软件项目失败并不可怕，最重要的还是在失败后，总结原因，吸取教训。就像微软在Vista项目失败后，总结经验，改进了开发流程，加快了发布周期，在Windows 7项目上重新取得了巨大的成功。还有像暴雪，在泰坦项目失败后，基于泰坦项目开发出了大受欢迎的守望先锋游戏。
+
+## 课后思考
+
+你有经历过或者听说过印象深刻的失败的软件项目吗？你觉得原因是什么？有哪些经验教训？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/经典案例解析篇/43 | 以VS Code为例，看大型开源项目是如何应用软件工程的？.md

@@ -0,0 +1,208 @@
+<audio id="audio" title="43 | 以VS Code为例，看大型开源项目是如何应用软件工程的？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f9/f7/f9855f0917e93c3977a80206af91fcf7.mp3"></audio>
+
+你好，我是宝玉。如果你所在的团队在日常的软件项目开发中，能科学地应用软件工程的知识，让你的项目能持续取得进展，最终交付的产品也有很好的质量，那么是一件非常幸运的事情。
+
+然而现实中，很多人并没有机会去参与或观察一个好的项目是什么样子的，也没机会去分析一个好的项目是如何科学应用软件工程的。
+
+好在现在有很多优秀的开源项目，不仅代码是公开的，它们整个项目的开发过程都是公开的。通过研究这些开源项目的开发，你能从中学习到一个优秀项目对软件工程的应用，加深你对软件工程知识的理解，进而应用到你自己的项目实践中。
+
+我想你对VS Code应该不陌生，它是一个非常优秀的编辑器，很多程序员包括我非常喜欢它。VS Code也是一个大型的开源项目，整个开发过程非常透明，所以今天我将带你一起看一下VS Code是如何应用软件工程的，为什么它能构建出这么高质量的软件。
+
+## 如何从VS Code的开发中学习软件工程？
+
+也许你会很好奇，平时也去看过VS Code的网站，但并没有提到软件工程的呀？
+
+是的，VS Code的网站并没有特别突出这些信息，但是如果你有心，可以找到很多有价值的信息，它的整个开发过程都是公开透明的。
+
+比如通过它项目的[WIKI](http://github.com/microsoft/vscode/wiki)和[博客栏目](http://code.visualstudio.com/blogs)，可以看到项目的计划、项目开发流程、测试流程、发布流程等信息。通过它的[GitHub](http://github.com/microsoft/vscode)网站，你可以看到团队是如何基于分支开发，开发完成后提交Pull Request，团队成员如何对代码进行审核，合并代码后如何通过持续集成运行自动化测试。
+
+除此之外，团队成员在网上也有一些对于VS Code开发的分享，比如说VS Code主要负责人Erich Gamma 2016年在GOTO技术大会上有一个专门关于VS Code的[主题演讲](http://passport.weibo.com/visitor/visitor?entry=miniblog&amp;a=enter&amp;url=https%3A%2F%2Fweibo.com%2F1727858283%2FHy6b647zm&amp;domain=.weibo.com&amp;sudaref=https%3A%2F%2Fshimo.im%2Fdocs%2FCTa8mSsYEcc8KgOg&amp;ua=php-sso_sdk_client-0.6.28&amp;_rand=1560153401.1655)。
+
+也许你还会想问：这些信息我也知道，也能从网上看到，但怎么通过这些信息去观察和学习它跟软件工程相关的部分呢？
+
+不知道你是否还记得，在我们专栏的第一篇文章《[01 | 到底应该怎样理解软件工程？](http://time.geekbang.org/column/article/82848)》中提到了：**软件工程的核心，就是围绕软件项目开发，对开发过程的组织，对方法的运用，对工具的使用。**所以当我们去观察一个软件项目，我们就可以去看它的开发过程是怎么被组织的？运用了哪些软件工程的方法？使用了哪些工具？
+
+接下来，我就带你一起从以下几个方面分析VS Code对软件工程的应用：
+
+- VS Code的开发过程；
+- 团队的分工角色；
+- 各个阶段如何进行；
+- 使用了哪些工具。
+
+## VS Code的开发迭代过程
+
+如果你是VS Code的用户，你会发现VS Code每个月都会有新版本的更新，每次更新都会有很多新酷的功能。这是因为VS Code每个版本的开发周期是4周，每四周都会发布一个新的版本。
+
+从开发模式来说，VS Code采用的是快速迭代的开发模式，每四周一个迭代。那么这四周迭代的工作都是如何进行的呢？
+
+- 第一周
+
+每个版本的第一周，通常是起着承上启下的作用，一方面要准备新版本，一方面还要对上一个版本的工作进行收尾。
+
+在这一周里，开发团队要去做一些偿还技术债务的事情，比如说重构代码，优化性能。所以如果你的团队抱怨说没有时间做偿还技术债务的事情，不妨也去学习VS Code团队，定期留出专门的时间，做偿还技术债务的事情。
+
+另一个主要工作就是一起讨论下一个迭代要做的功能。其实这有点类似于敏捷开发中，每个Sprint开始之前的项目计划会议。
+
+如果上一个版本开发完成的功能，发现了严重Bug，第一周还要去修复这些紧急Bug。
+
+- 第二周和第三周
+
+第二周和第三周主要工作就是按照计划去开发，一部分是开发新功能，一部分是修复Bug，所有的Bug都是通过GitHub的Issue来分配和跟踪的。
+
+团队成员每天还要先检查一下分配给自己的Issue，如果遇到线上版本紧急的Bug，要优先修复。
+
+- 第四周
+
+VS Code团队把最后一周叫End game，你可以理解为测试周，因为这一周只做测试和修复Bug。
+
+这一周要测试所有新的Feature和验证已经修复的Bug，确保被修复。同时还要更新文档和写Release Notes。
+
+测试完成后就发布预发布版本，这个预发布版本会先邀请一部分人使用，比如说微软内部员工、热心网友。
+
+- 下一个迭代第一周
+
+每个迭代开发测试完成的版本，会放在下一个迭代的第一周发布。如果在预发布版本中发现严重Bug，需要在第一周中修复。
+
+如果没有发现影响发布的Bug，那么第一周的周三左右就会正式发布上一个迭代完成的版本。
+
+前面我在专栏文章《[40 | 最佳实践：小团队如何应用软件工程？](http://time.geekbang.org/column/article/98985)》中，建议小团队可以缩短迭代周期到2-4周，有同学担心不可行，但你看VS Code这样稳定的4周迭代，不但可行，而且还是VS Code能保持每月发布一个新版本的关键所在。
+
+## VS Code团队的角色和分工
+
+VS Code的开发团队现在大约20人左右，一半在苏黎世，一半在西雅图。整个团队基本上都是开发人员，结构很扁平。
+
+从分工上来说，在开发新功能和修复Bug的时候，会有一些侧重，比如有人侧重做Git相关的功能，有人侧重做编辑器部分功能。这样有侧重的分工对于提升开发效率是有好处的。
+
+从角色上来说，除了开发，还有主要有两种角色：[Inbox Tracker](http://github.com/microsoft/vscode/wiki/Issue-Tracking#inbox-tracking)和[Endgame Master](http://github.com/microsoft/vscode/wiki/Running-the-Endgame#duties-of-the-endgame-master)。这两种角色在每个迭代的时候是轮值的，每个人都有机会去担任这两个角色。
+
+- Inbox Tracker
+
+Inbox Tracker的主要任务就是收集、验证、跟踪Bug。但这个工作对于VS Code团队来说可不轻松，现在Issue的总量已经超过了5000，每天提交的新的Issue的量大概有100左右。所以VS Code团队写了一个机器人叫[VSCodeBot](http://github.com/apps/vscodebot)，可以帮助对Issue先自动处理，打标签或回复，然后Inbox Tracker再对剩下的Issue进行人工处理。
+
+Inbox Tracker要检查新提交的Issue是不是一个真正的Bug，如果是提问，建议到StackOverflow去问，如果是Bug，打上Bug的标签，并指派给相应模块的负责人。
+
+- Endgame Master
+
+VS Code团队是没有专职的测试人员的，所有的测试工作都是开发人员自己完成。在每一个迭代中。Endgame Master在这里就很重要，要组织管理整个迭代的测试和发布工作。
+
+Endgame Master在每个迭代测试之前，根据迭代的开发计划制定相应的测试计划，生成Check List，确保每一个新的功能都有在Check List中列出来。
+
+因为VS Code团队没有专职测试，为了避免开发人员自己测试自己的代码会存在盲区，所以自己写的功能都是让其他人帮忙测试。Endgame Master一个主要工作就是要将这些测试项分配给团队成员。
+
+最后整个测试计划会作为一条GitHub Issue发出来给大家审查。比如说这是某一个月的[Endgame计划](http://github.com/microsoft/vscode/issues/74412)。
+
+团队的日常沟通是通过Slack，在测试期间，Endgame Master需要每天把当前测试进展同步给所有人，比如说总共有多少需要测试的项，哪些已经验证通过，哪些还没验证。
+
+## VS Code的各个阶段
+
+接下来，我们来按照整个开发生命周期，从需求收集和版本计划、设计开发、测试到发布，来观察VS Code各个阶段是如何运作的。
+
+**1. VS Code的需求收集和版本计划**
+
+VS Code每次版本发布，都能为我们带来很多新酷的功能体验，那么这些功能需求是怎么产生的呢？又是怎么加入到一个个版本中的呢？
+
+VS Code的需求，一部分是团队内部产生的；一部分是从社区收集的，比如GitHub、Twitter、StackOverflow的反馈。最终这些收集上的需求，都会通过GitHub的Issue管理起来。如果你在它的GitHub Issue中按照[feature-request](http://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Afeature-request+sort%3Areactions-%2B1-desc)的标签去搜索，可以看到所有请求的需求列表。
+
+VS Code每半年或一年会对下一个阶段做一个[Roadmap](http://github.com/microsoft/vscode/wiki/Roadmap)，规划下一个半年或一年的计划，并公布在GitHub的WIKI上，这样用户可以及时了解VS Code的发展，还可以根据Roadmap上的内容提出自己的意见。
+
+大的RoadMap确定后，就是基于大的RoadMap制定每个迭代具体的开发计划了。前面已经提到了，在每个迭代的第一周，团队会有专门的会议讨论下一个迭代的开发计划。在VS Code的WIKI上，也同样会公布所有确定了的[迭代计划](http://github.com/microsoft/vscode/wiki/Iteration-Plans)。
+
+那么，有了功能需求和Bug的Issue，也有了迭代的计划，怎么将Issue和迭代关联起来呢？
+
+GitHub的Issue管理有一个Milestone的功能，VS Code有四个主要的Milestone。
+
+- 当前迭代：当前正在开发中的Milestone；
+- On Deck：下一个迭代对应的Milestone；
+- Backlog：还没开始，表示未来要做的；
+- Recovery：已经完成的迭代，但是可能要打一些补丁。
+
+<img src="https://static001.geekbang.org/resource/image/2c/1a/2cd5a5c18253658323dd296ec751be1a.png" alt=""><br>
+（图片来源：[VSCode Milestones](http://github.com/microsoft/vscode/milestones)）
+
+**2. VS Code的设计和开发**
+
+VS Code的架构设计现在基本上已经定型，你在它的WIKI和博客上还能看到很多VS Code架构和技术实现的分享。
+
+在每个迭代开发的时候，一般小的功能不需要做特别的架构设计，基于现有架构增加功能就好了。如果要做的是大的功能改造，也需要有设计，负责这个模块开发的成员会先写设计文档，然后邀请其他项目成员进行Review，并给出反馈。
+
+VS Code的开发流程也是用的[GitHub Flow](http://guides.github.com/introduction/flow/)，要开发一个新功能或者修复一个Bug，都创建一个新的分支，开发完成之后提交PR。PR合并之前，必须要有核心成员的代码审查通过，并且要确保所有的自动化测试通过。
+
+对于GitHub Flow的开发流程，我在专栏文章《[30 | 用好源代码管理工具，让你的协作更高效](http://time.geekbang.org/column/article/93757)》中有详细的介绍。你也可以在VSCode 的[Pull requests](http://github.com/microsoft/vscode/pulls)中看到所有提交的PR，去看看这些PR是怎么被Review的，每个PR的自动化测试的结果是什么样的。通过自己的观察，去印证专栏相关内容的介绍，同时思考是否有可以借鉴到你自己项目中的地方。
+
+VS Code对自动化测试代码也是非常重视，在实现功能代码的时候，还要加上自动化测试代码。如果你还记得专栏文章《[29 | 自动化测试：如何把Bug杀死在摇篮里？](http://time.geekbang.org/column/article/93405)》中的内容：自动化测试有小型测试、中型测试和大型测试。VS Code的自动化测试也分为单元测试、集成测试和冒烟测试。
+
+VS Code的[CI（持续集成](http://dev.azure.com/vscode/VSCode)）用的是微软自己的Azure DevOps，每一次提交代码到GitHub，CI都会运行单元测试和集成测试代码，对Windows/Linux/macOS三个操作系统分别运行测试。在[持续集成](http://dev.azure.com/vscode/VSCode)上可以直观地看到测试的结果，VS Code现在有大约4581个单元测试用例，运行一次1分钟多；集成测试466个，运行一次大约3分钟。
+
+<img src="https://static001.geekbang.org/resource/image/ca/9a/ca8dc2cc12e423d92020a7a5a964c99a.png" alt="">（图片来源：[VSCode的持续集成工具Azure DevOps](http://dev.azure.com/vscode/VSCode)）
+
+如果你的团队还没有开始相应的开发流程，没有使用持续集成工具，不妨学习VS Code，使用类似于GitHub Flow的开发流程，使用像Azure DevOps这样现成的持续集成工具。
+
+** 3. VS Code的测试**
+
+前面提到了，迭代的最后一周是End game，这一周就是专门用来测试的，并且有轮值的Endgame Master负责整个测试过程的组织。
+
+具体测试的时候，大家就是遵循Endgame Master制定好的测试计划，各自按照Check List逐一去检查验证，确保所有的新功能都通过了测试，标记为修复的Bug真的被修复了。对于验证通过的Bug，在对应的Issue上打上verified的标签。
+
+在人工测试结束后，Endgame Master就需要跑[冒烟测试](http://github.com/Microsoft/vscode/wiki/Smoke-Test)，确保这个迭代的改动不会导致严重的Bug发生。
+
+如果你的团队也没有专职测试，可以学习VS Code这样的做法：留出专门的测试阶段，事先制定出详细的测试计划，把所有要测试的项都通过测试跟踪工具跟踪起来，开发人员按照测试计划逐一测试。
+
+**4. VS Code的发布流程**
+
+在Endgame测试后，就要从master创建一个release分支出去，比如说 release/1.10 ，后面的预发布版本和正式版本包括补丁版本都将从这个 release 分支发布。
+
+如果在创建release分支后发现了新的Bug，那么对Bug修复的代码，要同时合并到master和release分支。每一次对Release的代码有任何改动，都需要重新跑冒烟测试。
+
+在Release分支的代码修改后的24小时之内，都不能发布正式版本。每次Release代码修改后，都会发布一个新的预发布版本，邀请大约两万的内部用户进行试用，然后看反馈，试用24小时后没有什么问题就可以准备发布正式版本。
+
+发布正式版本之前，还要做的一件事，就是Endgame master要写Release Notes，也就是你每次升级VS Code后看到的更新说明，详细说明这个版本新增了哪些功能，修复了哪些Bug。
+
+如果版本发布后，发现了严重的线上Bug，那么就要在Release分支进行修复，重新生成补丁版本。
+
+除此之外，VS Code每天都会将最新的代码编译一个最新的版本供内部测试，这个版本跟我们使用的稳定版Logo颜色不一样，是绿色的Logo。VS Code内部有“吃自己狗粮”（eat your own dog food）的传统，也就是团队成员自己会使用每天更新的测试版本VS Code进行开发，这样可以在使用过程中及时发现代码中的问题。
+
+<img src="https://static001.geekbang.org/resource/image/a6/2b/a6540bfea13c3679e3a4dad78d9ae02b.png" alt=""><br>
+（图片来源：[The Journey of Visual Studio Code](http://gotocon.com/dl/goto-amsterdam-2016/slides/ErichGamma_TheJourneyOfALargeScaleApplicationBuiltUsingJavaScriptTypeScriptNodeElectron100OSSComponentsAtMicrosoft.pdf)）
+
+像VS Code这样的发布流程，通过创建Release分支可以保障有一个稳定的、可以具备发布条件的代码分支；通过预发布内部试用的机制，有问题可以及时发现，避免造成严重的影响。
+
+关于发布流程的内容，你也可以将VS Code的[发布流程](http://github.com/microsoft/vscode/wiki/Release-Process) 对照我们专栏文章《[35 | 版本发布：软件上线只是新的开始](http://time.geekbang.org/column/article/96289)》中的介绍，加深理解。
+
+## VS Code使用的工具
+
+VS Code的源代码管理工具就是基于GitHub，整个开发流程也完全是基于GitHub来进行的。
+
+它的任务跟踪系统是用的GitHub的Issue系统，用来收集需求、跟踪Bug。通过标记不同的Label来区分[Issue的类型和状态](http://github.com/microsoft/vscode/wiki/Issue-Grooming#categorizing-issues)，比如bug表示Bug，feature-request表示功能请求，debt表示技术债务。通过Issue的Milestone来标注版本。
+
+VS Code的持续集成工具最早用的是[Travis CI](http://travis-ci.org)和[AppVeyor](http://www.appveyor.com)，最近换成了微软的[Azure Pipelines](http://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/)，在他们的Blog上有一篇文章《[Visual Studio Code using Azure Pipelines](http://code.visualstudio.com/blogs/2018/09/12/engineering-with-azure-pipelines)》专门解释了为什么要迁移过去。
+
+VS Code的文档一部分是用的GitHub的WIKI系统，一部分是它网站的博客系统。WIKI主要是日常项目开发、维护的操作说明，博客上更多的是一些技术分享。
+
+另外VS Code团队还自己开发了一些小工具，比如说帮助对Issue进行自动处理回复的GitHub机器人VSCodeBot。
+
+通过这些工具的使用，基本上就可以满足像VS Code这样一个项目的日常运作。像这些源代码管理、任务跟踪系统、持续集成工具的使用，在我们专栏也都有相应的文章介绍，你也可以对照着文章的内容和VS Code的使用情况加以印证，从而加深对这些工具的理解，更好把这些工具应用在你的项目中。
+
+## 总结
+
+当你日常在看一个开源项目的时候，不仅可以去看它的代码，还可以去观察它是怎么应用软件工程的，不仅可以加深你对软件工程知识的理解，还能从中学习到好的实践。
+
+比如观察一个软件项目的开发过程是怎么被组织的，团队如何分工协作的，运用了哪些软件工程的方法，以及使用了哪些工具。
+
+VS Code使用的是快速迭代的开发模式，每四周一个迭代：
+
+- 第一周：偿还技术债务，修复上个版本的Bug，制定下一个版本的计划；
+- 第二、三周：按照计划开发和修复Bug；
+- 第四周：测试开发完成的版本；
+- 下一迭代第一周：发布新版本。
+
+在团队分工上，VS Code的团队很扁平，没有专职测试，通过轮值的Inbox Tracker和Endgame Master来帮助团队处理日常Issue和推动测试和发布工作的进行。
+
+在工具的使用方面，VS Code使用的是GitHub托管代码，基于GitHub Flow的开发流程使用。还有使用Azure DevOps作为它的持续集成系统。
+
+通过观察对VS Code对软件工程知识点的应用，再对照专栏中相关文章的介绍，可以帮助你更好的理解这些知识点，也可以借鉴它们好的实践到你的项目开发中。
+
+## 课后思考
+
+你可以尝试自己去观察一遍VS Code项目对软件工程知识的应用，得出自己的结论。你也可以应用这样的观察分析方法，去观察其他你熟悉的优秀开源项目，比如像Vue、React，看它们是怎么应用软件工程的。欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/经典案例解析篇/44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的？.md

@@ -0,0 +1,174 @@
+<audio id="audio" title="44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d0/41/d000b71b296214d1465dbced23012c41.mp3"></audio>
+
+你好，我是宝玉。在上一篇文章里，我带你一起了解了像VS Code这样的开源项目对软件工程的应用，以及如何学习借鉴优秀的项目对软件工程的应用。今天我将带你去看看像微软、谷歌、阿里巴巴这些大厂是怎么应用软件工程的，以及我们应该如何学习和借鉴他们对软件工程的实践。
+
+我想无论你现在是否在大厂工作，都有很多途径了解到大厂是如何应用软件工程的，网上已经有很多他们员工的分享。你可能更想知道的是： 从大厂应用软件工程的实践中，你能学习什么，又该如何学习借鉴。
+
+每个公司，都有自己的历史和文化，他们的文化又影响了各自的软件开发模式。
+
+比如说谷歌，谷歌崇尚工程师文化，请来的工程师都是万里挑一的，开发也没有太大的进度压力，所以Google的工程师做项目就会不紧不慢，质量优先，有统一的代码规范，严格的代码审查和严谨的自动化测试。还会频繁地重写系统，每隔几年，就把软件重写一遍。
+
+再比如说Facebook，Facebook有一种黑客精神，创始人马克·扎克伯格有句名言是“Move Fast and Break Things”，也就是说快速做出产品，不要怕犯错。所以Facebook的工程师做软件开发的时候不会想太多，先实现再说，做出来就发布，哪怕可能有Bug。发布后根据用户的反馈再不断完善，真的把线上功能弄坏了，再打补丁去修复。
+
+然而这些带有各自文化特色的部分，却是我们很难学习借鉴的，因为这样的文化都只适合各自的公司。假设让微软去学习Facebook的黑客精神，发布带有很多Bug的Windows系统，那么用户是不能忍受的；而让普通公司去学Google的工程师文化，项目没有严格的Dead Line，系统隔几年重写一遍，那公司恐怕都要撑不住了。
+
+所以，要学习大厂，**你要多去关注大厂们对软件工程实践共通的地方，可以应用在你自己项目的地方，另外还要去看大厂对软件工程实践的变化趋势，在朝什么方向发展。**通常这些大厂的很多实践都是业界的风向标，一旦一些实践大厂都在应用，那么很多中小厂就会跟风，最终变成行业标准。
+
+在上一篇《[43 | 以VS Code为例，看大型开源项目是如何应用软件工程的？](http://time.geekbang.org/column/article/100141)》中，我从项目的开发迭代过程，团队的角色分工和项目开发各个阶段来分析了VS Code对软件工程的应用。类似的，我也将从大厂的开发团队组成、开发工具的使用、项目开发流程这几个方面来分析一下大厂对软件工程的应用中，有哪些共同点？有哪些变化趋势？有什么地方可以借鉴？
+
+## 软件项目开发团队组成
+
+软件项目开发，最终要落实到“人”上面。大厂在招人方面一向舍得投入，不仅花很多人力财力在招聘上面，同样对于员工待遇上也很大方，只为了能招到最优秀的人才。
+
+对于普通的公司和团队来说，很难像大厂那样有一群行业内顶尖的人才，但是它在软件团队的一些管理和实践方面，还是有一些共通的地方，有值得普通公司学习借鉴之处。
+
+#### 1. 软件开发团队规模小
+
+网上曾有一张流传甚广的关于各大公司的组织结构图。<br>
+<img src="https://static001.geekbang.org/resource/image/e3/4f/e3d4dfaa2287116cd574f5ea4adb7f4f.png" alt=""><br>
+（图片来源：[HOW YOUR STARTUP’S ORG CHART CHANGES YOUR PRODUCT](http://tomtunguz.com/conways-law/)）
+
+这张图形象生动的描述了各大公司的组织结构，各具特色。然而这些大厂的组织结构具体细分到软件项目开发团队的时候，却惊人的相似：那就是一个软件项目开发团队都不会太大，一般不会超过10个人，如果超过就会被分拆。最著名的就是亚马逊的“两个披萨原则”，也就是团队的人数不应该多到让两个披萨不够吃。
+
+其实大厂的软件项目都采用小团队的原因很好理解，那就是团队规模越大，交流就越复杂，成本也越高！要想沟通更高效，那么就要求团队的规模必须足够小。
+
+组织架构的小型化也会对软件架构有影响，通过架构的隔离，让各个不同的团队可以在一起高效地协作。有在谷歌YouTube工作的朋友跟我说，YouTube的App，其中一个导航菜单，都是一个专门的小团队在维护。
+
+如果你所在团队规模大，沟通效率不高，那么可以考虑向大厂学习，分拆成小团队，可以有效提高沟通协作的效率。
+
+#### 2. 没有专职测试
+
+在我们专栏文章《[32 | 软件测试：什么样的公司需要专职测试？](http://time.geekbang.org/column/article/94941)》中，探讨了专职测试这个话题，而现在像微软、谷歌、Facebook、阿里巴巴这些大厂，都没有专职的测试人员。
+
+但没有专职测试人员不代表他们不重视质量，只是他们在用更高效的方式来代替人工“点点点”的手工测试。就像专栏文章中介绍的，Facebook能做到没有专职测试人员，是因为他们有大量的自动化测试；另外，Facebook在功能发布之前，先在内部使用，上线之后能做到有效监控，出现问题能随时回滚或者打补丁。
+
+大厂替代专职测试的这些手段，对于普通公司来说，可能现阶段去实施是有难度的，但是随着这些发布、监控工具的不断普及，自动化测试的普及，开发团队不设置专职测试会逐步变成一种趋势，现在的手工测试将来也许会被逐步淘汰。
+
+#### 3. DevOps 文化
+
+在我们专栏文章《[36 | DevOps工程师到底要做什么事情？](http://time.geekbang.org/column/article/96895)》中，有过对DevOps进行探讨，DevOps，本质上就是一种紧密协作的工作方式。
+
+早些年像微软这样的大厂，工程师团队有三种角色：项目经理，开发人员和测试人员，而运维团队则是工程师团队的另一组人。虽然好处是分工更明确，但是久而久之也造成了不同工种之间的隔离，尤其是各自目标不一致导致的利益冲突。
+
+所以微软也在前些年进行了转型，将运维团队合并到了工程师团队，运维人员和开发人员协作更加紧密了，有效提高了编码效率，质量和产量。
+
+除了微软，其他大厂也纷纷采用了类似的DevOps转型和实践。这里有两篇关于谷歌和阿里巴巴的DevOps实践文章可以参考：《[孙宇聪：来自Google的DevOps理念及实践](http://yq.aliyun.com/articles/582942)》《[阿里研究员毕玄谈应用运维体系的变迁，DevOPS是大势所趋](http://102.alibaba.com/detail?id=117)》。
+
+如果你的团队也存在不同工种之间协作的矛盾和冲突，不妨借鉴一下大厂对DevOps的实践。
+
+## 开发工具的使用
+
+大厂都爱自己造轮子，对开发工具也是如此，都有一个专门的部门去做内部工具的开发和维护。
+
+如果你有幸在一个大厂工作，那么你会很幸福，基本上开发过程中，各种像编译、部署、持续集成等等都有好用的工具可以帮助你自动化，提升效率，你只要专注于写代码就好了。然而一旦离开大厂，你会发现这些日常工具都要自己去搭建，甚至得自己去写。
+
+但好在大厂用的这些主要工具，你在网上几乎都能找到开源的或商业的替代品。只是没有那么好用罢了。
+
+比如说谷歌一名前员工在 GitHub 上分享了他在谷歌工作时，日常会使用的一些工具，以及外界对应的替代方案（[工具和替代方案](http://github.com/jhuangtw-dev/xg2xg)）。再比如微软和阿里巴巴都将自己的工具（[Azure DevOps](http://azure.microsoft.com/zh-cn/services/devops/) 和 [阿里云DevOps](http://develop.aliyun.com/devops)）做成了服务供第三方使用。
+
+有一点倒是可以看得出：这些大厂舍得在工具上投入。应用工具，也确实可以有效地提升效率，改进软件项目质量。
+
+关于工具，我们专栏在各个章节也都有介绍，建议可以学习下大厂，把这些工具用起来，帮助你更好地完成项目。
+
+## 项目开发流程
+
+各个大厂基本上都没有规定必须要用什么开发模型或者不允许用什么开发模型，各个开发团队都可以自行决定采用的开发模型。
+
+所以你会看到有的团队是敏捷开发，有的团队是快速迭代，甚至有的团队还用的是瀑布模型。但他们在项目开发中有很多共通之处。
+
+#### 1. 迭代周期短
+
+即使是像微软这样，以前要几年才发布一个版本软件的公司，现在也加快了迭代。现在Windows 10，每半年就会更新一个大的版本，每天都会发布可以测试的版本。
+
+上一篇介绍的VS Code的开发，也是每个月就会有一个大的版本发布。还有像谷歌的Chrome浏览器，也是每6周发布一个新版本，如果某个新功能还没准备好，那么放到下个版本发布。
+
+<img src="https://static001.geekbang.org/resource/image/ad/48/ad3443663876f2a90c552e0666697f48.png" alt=""><br>
+（图片来源：[Chrome发布周期](http://www.slideshare.net/36kr/46659928-chromereleasecycle12162010)）
+
+如果你的项目需要半年以上的开发周期，也要考虑一下，是否可以缩短开发周期，快速迭代起来。
+
+#### 2. 严格的开发流程
+
+其实我在专栏已经反复地、苦口婆心地讲了很多开发的流程，比如说基于分支开发、代码审查、自动化测试、持续集成等等，希望大家能在实践中去应用这些好的实践。
+
+然而在大厂，这些开发流程基本上都是硬性要求：
+
+- 要基于分支进行开发新功能或者修复Bug；
+- 要遵守公司或者团队的代码规范；
+- 合并之前要有至少一个人Review通过；
+- 要写自动化测试代码，并且保证所有测试用例通过。
+
+在谷歌的卫生间里面，甚至会张贴着有关Testing on the Toilet的贴纸，让你在去卫生间的时候还能学学怎么写测试，好让你的PR能早点通过审查。
+
+<img src="https://static001.geekbang.org/resource/image/72/51/726d0bc7c1bae8f809571c881eff3d51.jpeg" alt=""><br>
+（图片来源：[Testing on the Toilet](http://mike-bland.com/2011/10/25/testing-on-the-toilet.html)）
+
+#### 3. 严谨的测试流程
+
+虽然大厂都没有专职测试，但是测试可不含糊，都有一套严谨的，并且行之有效的测试流程。
+
+以谷歌的Chrome浏览器为例，除了自动化测试以外，每个Chrome的版本发布之前，都要经历以下几个版本。
+
+- 金丝雀版本（Canary Channel）： 过去煤矿工人要下井会带着金丝雀，这种鸟对危险气体的敏感度超过人。如果金丝雀死了，矿工便知道井下有危险气体，需要撤离。金丝雀版本会频繁发布，但并不太可靠，就像金丝雀一样用来第一时间发现严重的问题。
+- 开发版本（Dev Channel）：工程师日常使用的版本，一边开发一边使用，让工程师可以第一时间验证自己开发的功能。
+- 测试版本（Test Channel）：给内部员工的版本，就像上一篇VS Code介绍的Eat your own food，自己人先试用。
+- Beta 版本或发布版本（The Beta Channel or Release Channel）：是给外部用户使用的测试版本，并不保证稳定，但是用户可以提前体验新功能，也能帮助开发团队及时发现Bug。
+
+类似的，如果你看Windows 10的发布流程，也是这样一个一个的测试版本的测试流程，最后正式发布的版本已经是经过千锤百炼，反复测试过的。
+
+<img src="https://static001.geekbang.org/resource/image/0a/62/0adda87200a5b6ea2f89d31caeba6e62.png" alt=""><br>
+（图片来源：[微软邹欣：Hit refresh背后的软件工程革新](http://zhuanlan.zhihu.com/p/61855923)）
+
+#### 4. 完善的发布和监控流程
+
+就算经过完整的测试，也不能保证质量就是可靠的。所以大厂们还会配合一套完善的发布和监控流程。
+
+发布前，先评估风险，增加相应的监控数据和设置报警的阈值。制定出现问题的应对方案。
+
+上线后，先推送一小部分用户，并同时进行线上数据的监控，如果没有发现异常，自动加大比例，直到完整覆盖；如果发现异常，自动报警通知相关负责人，上线处理，并直接关闭新功能。
+
+有关上线发布和数据监控的内容，你也可以参考专栏文章《[35 | 版本发布：软件上线只是新的开始](http://time.geekbang.org/column/article/96289)》和《[38 | 日志管理：如何借助工具快速发现和定位产品问题 ？](http://time.geekbang.org/column/article/97682)》中的更多介绍。
+
+#### 5. 事后总结，不断改进
+
+在专栏文章《[39 | 项目总结：做好项目复盘，把经验变成能力](http://time.geekbang.org/column/article/98141)》中，提到了项目复盘的重要性，以及如何做好项目复盘。
+
+对于大厂来说，复盘也是整个项目开发过程中很重要的一部分，正是因为有这样一次次的“事后诸葛亮”会议，才让团队成员能从中总结成功经验，吸取失败教训。
+
+<img src="https://static001.geekbang.org/resource/image/29/42/29158c3392b49d88168d4fd7f6d83242.png" alt=""><br>
+（图片来源：[微软邹欣：Hit refresh背后的软件工程革新](http://zhuanlan.zhihu.com/p/61855923)）
+
+## 参考阅读
+
+其实，大厂的软件工程实践，网上有很多相关的文章，这里我将收集的一些内容在这里分享一下，供参考阅读：
+
+- 《[Google公司的软件工程之道](http://mp.weixin.qq.com/s/6KMFeVlt1QzLkfcYcWC08A?)》
+- 《[软件工程在微软的演化——邹欣](http://zhuanlan.zhihu.com/p/61855923)》
+- 《[解密Facebook产品的开发流程](http://history.programmer.com.cn/15584/)》
+- 《[微软、谷歌、Facebook、Amazon软件质量控制实践](http://blogs.msdn.microsoft.com/billliu/tag/software-testing/)》
+- 《[微软开发团队的 DevOps 实践启示](http://www.infoq.cn/article/devops-lessons-microsoft)》
+- 《[The Facebook Mobile Release Process](http://www.infoq.com/presentations/Facebook-Release-Process/)》
+- 《[敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结](http://zhuanlan.zhihu.com/p/33554080)》
+- 《[如何在2周内交付85%以上需求？阿里工程师这么做](http://yq.aliyun.com/articles/663714)》
+
+## 总结
+
+现在业界顶级的互联网或者软件公司，他们都对软件工程都有非常好的应用和实践，这也是他们能跻身成为顶级互联网的一个不可或缺的前提。通过学习和观察大厂的软件工程实践，能帮助我们拓宽视野，提升软件工程知识水平。
+
+学习大厂，要多去关注大厂们对软件工程实践共通的地方，以及可以应用在你自己项目的地方。
+
+在团队管理方面，大厂的软件项目团队规模都被拆的比较小，这有助于团队成员之间的沟通协作；没有专职的测试人员，测试工作被自动化测试代替；有很好的DevOps文化，各个工种之间紧密协作。
+
+在开发工具方面，大厂都很重视工具的开发和使用，很多工具我们也能找到替代品，或者直接使用大厂提供的工具服务。
+
+在项目开发流程上，大厂有严格的开发流程，代码必须写自动化测试代码，自动化测试通过，并且有人Review通过的PR才能被合并；大厂虽然没有专职测试人员，但是整个测试过程很严谨，在发布前都经过了充分的测试；大厂对于软件发布也都有完善的发布和监控流程，不仅可以快速发布，还可以及时发现线上问题；大厂也会有上线后的复盘总结，总结成功经验，吸取失败教训，将项目经验变成团队能力。
+
+从大厂对软件工程实践中，你可以学习到一个优秀的公司是如何来应用软件工程，打造出高质量产品的，也可以借鉴其中好的实践到你自己的项目中。
+
+最后你要清楚，即便是大厂，对软件工程的应用也不是一成不变的，会随着技术的发展、软件工程的发展不断改进。比如说微软早些年就使用的类似于瀑布模型的开发模式，现在也变成了敏捷的快速迭代的开发模式。这种不断学习改进的方式，也值得我们大家学习和思考。
+
+## 课后思考
+
+这些大厂里面，你最喜欢哪几家？你觉得他们对于软件工程的实践哪些做的比较好？哪些是你可以学习借鉴的？欢迎你在留言区分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/经典案例解析篇/45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术.md

@@ -0,0 +1,131 @@
+<audio id="audio" title="45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/56/07/56477334a4db5b3062bcae644d182d07.mp3"></audio>
+
+你好，我是宝玉。这些年来，新技术新概念层出不穷，比如说微服务、云计算、人工智能等。你有没有去学习和了解这些新技术呢？又是怎么去理解这些新技术的呢？
+
+也许你会从技术的角度，去学习和理解这些新技术，去看如何把服务分拆，看如何应用虚拟化、容器技术，如何用人工智能切页面。
+
+这些新技术可能会让你很兴奋，毕竟又有很多新知识可以学习和应用；但另一方面也可能会增加一些困惑，比如说：
+
+- 我该不该在项目中使用微服务？
+- 在设计微服务架构的时候，服务拆分的粒度该多细？该拆成10个服务还是100个？
+- 云计算对我的项目会带来什么影响？我应该怎么应用？
+- 人工智能会代替我写程序吗？
+
+如果只是从技术角度思考这些问题，难免会陷入技术之中，反而不容易看清楚这些问题。在我们专栏一开始《[02 | 工程思维：把每件事都当作一个项目来推进](https://time.geekbang.org/column/article/83277)》这篇文章中，我就提到了工程思维的概念：
+
+> 
+工程思维，本质上是一种思考问题的方式，在解决日常遇到的问题时，尝试从一个项目的角度去看待问题、尝试用工程方法去解决问题、站在一个整体而不是局部的角度去看问题。
+
+
+在学习使用这些新技术的时候，你不妨从项目的整体，从软件工程的角度来理解这些技术，这能给你带来不同的视角。那么怎么从软件工程的角度去理解呢？
+
+我想你应该对我们专栏上两篇文章有印象，我分别从团队、项目过程、工具这几个维度，分析了开源项目和优秀公司对软件工程的应用。类似的，你也可以跳出技术之外，从软件工程的角度来理解微服务、云计算、人工智能这些新技术和概念。
+
+## 软件工程中技术架构和组织架构的关系
+
+首先我们来看看微服务，你可能第一反应就是：它是一种架构技术。没错，从技术角度来看，微服务就是一种架构技术。经过对我们专栏的学习，我相信你对架构应该不会陌生，比如：前后端分离架构、微服务架构。
+
+不知道你有没有观察过：通常系统架构和组织架构是相似的。比如说前后端分离的架构，那么在组织上一般也会分前端组和后端组；而微服务架构，则分组是和服务相关的，可能一个组就是负责一个微服务。
+
+其实组织架构和技术架构相似这个现象不是偶然的，这个现象背后有个定律叫康威定律(Conway’s Law)。康威（Melvin Conway）博士在1967年提交的一篇论文《[How Do Committees Invent?](http://www.melconway.com/Home/Conways_Law.html)》中最有名的一句话是：
+
+> 
+Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations. — Melvin Conway
+
+
+如果对这句话翻译一下，它的意思是：
+
+> 
+你设计的软件系统架构，会以某种方式反映出构建软件背后团队的组织架构，你在设计软件的系统架构时，同时也在设计你的组织架构，反之亦然。也可以简单理解为：组织架构的设计等同于系统架构的设计。
+
+
+如果你拿康威定律去验证你现在的团队组织架构，或者你熟悉的其他团队的组织结构，你会发现运行良好的项目，都很好地符合这条定律。那些大型复杂的单体软件系统，背后也对应着一个庞大的开发团队，那些应用微服务的项目，背后都是一个个的小组。
+
+<img src="https://static001.geekbang.org/resource/image/ed/b5/ed102dbcac40d0f8f002c222732feeb5.png" alt=""><br>
+（图片来源：Conway’s Law）
+
+看完康威定律再回过头来看微服务，你会发现，**微服务架构的设计，不仅仅是一个对服务拆分的架构设计，同时也是对组织架构拆分的设计。**
+
+当你在做架构设计，在考虑你的微服务拆分粒度的时候，不妨先想一想：你团队的组织结构是什么样的？真的大到需要用微服务了吗？你能按照微服务的设计去重新设计和调整你的组织结构吗？
+
+当你在设计系统架构的同时，把组织架构的设计也考虑进去，很多问题也就迎刃而解了。比如说你开发团队30个人，要使用微服务的架构，那么拆成3～5个微服务是比较合适的。因为每个小组10个人左右，每个小组维护1～3个微服务，是相对比较合适的配比。
+
+然后你再看那些应用微服务失败的案例，比如说一个小开发团队，做出100多个微服务的架构，那团队维护这些服务的成本一定是相当高的，最终会难以维持。就像这篇文章：《[再见微服务，从100多个问题儿童到一个超级明星](http://mp.weixin.qq.com/s?__biz=MzIxMzEzMjM5NQ==&amp;mid=2651032374&amp;idx=1&amp;sn=b9a44cc1fd143e8d958587ff05f1acf5&amp;chksm=8c4c5e32bb3bd7246ad28bee556649dde1ffeaae086c8bdfc27c054b32042a89c456aed4cbe5&amp;scene=27#wechat_redirect)》，虽然文章里面没有提到团队的组织结构，但是可以想象，这140多个微服务背后一定没有140个小团队，哪怕每个团队只有10个微服务，对团队来说也是有极大维护成本的。
+
+还有一些传统大型企业，团队构成是按工种划分成不同团队的，开发一个团队、测试一个团队、运维一个团队，那么推行微服务阻力会非常大，因为这样的组织结构和微服务的组织结构是不兼容的。
+
+对于微服务的组织结构，需要按服务划分团队，团队成员有开发、测试和运维，一起组成一个小团队，围绕着服务不断迭代，这样效率是最高的。
+
+<img src="https://static001.geekbang.org/resource/image/c4/22/c4198108e8c26a3b97b4718d3d413822.png" alt=""><br>
+（图片来源：[微服务写的最全的一篇文章](https://mp.weixin.qq.com/s/CGZmR5aFYHyEDdp5keGa1A?)）
+
+如果以后又出来什么新的概念和技术，你不妨从软件工程的角度，去看看它和组织结构的关系。比如说这些天网上开始流传一个新的概念叫：[微前端（Micro Frontends）](http://mp.weixin.qq.com/s/CGZmR5aFYHyEDdp5keGa1A?)，在我看来，这说明现在开发的重心在往前端倾斜，前端团队越来越庞大，需要分拆了。
+
+<img src="https://static001.geekbang.org/resource/image/8d/50/8ddb3e1f4b3417dc99bf7ec9f3685350.png" alt=""><br>
+(图片来源：[Micro Frontends](https://martinfowler.com/articles/micro-frontends.html))
+
+## 新技术改变了软件工程中的分工协作
+
+我们再来看看像云计算和人工智能这类技术，也许你会觉得它们代表了很多激动人心的高端技术，比如虚拟化、自动化、智能化等等。但这些新技术不仅是技术上有突破，更是对软件工程的开发过程，对分工协作都产生了深远的影响。云计算通过标准化的服务简化了开发的难度，人工智能和自动化在逐步替代项目中的一些手工操作。
+
+在我大学上软件工程课的时候，老师跟我们说：“在建筑工程，用一些标准的模块，比如各种建筑材料组合在一起，就可以完成复杂的结构。这种标准化的结构可以极大地降低建造成本。希望未来软件工程也能像建筑工程一样，用一些标准的模块和组件，也可以构建出复杂的软件。”然而在十多年前，这个目标还是挺遥远的。
+
+十多年前我办过网站，自己写程序，程序写完后要自己去买服务器放到机房托管，每年要给机房交托管费，还要定期数据备份，给服务器杀毒，装防火墙防止DDos攻击这种事情。万一服务器宕机了，需要给机房打电话，会有人帮忙重启一下，如果不行就得自己去机房了。
+
+那时候的网络访问还有南北隔离的问题，也就是说你服务器放在南方电信，而用户是北方网通的，那么访问速度就特别慢，想要速度快就要用CDN（Content Delivery Network，即内容分发网络），以保证访问速度。但当时CDN的价钱不是普通用户能承受得了的。
+
+可以说我办个网站是操碎了心。这也是很多中小企业早些年自己开发运行软件系统的写照：需要兼顾开发、测试和线上运维，什么事情都需要自己做。
+
+但是现在，如果我再要去办一个网站，我不会再自己去买服务器托管，而会选一家云计算服务商，将我的程序放在云服务商运行，出问题了就重新部署或者再新开一个虚拟服务器。数据库我也不会自己去安装维护，直接用云数据库，这样省去了数据备份的烦恼。
+
+就算是程序开发，我也不会所有功能自己实现，比如文件存储我会直接用七牛云之类的云存储服务，还能使用CDN服务。网站内容的搜索我也会考虑阿里云的文档检索服务，如果有手机App消息推送，直接用云厂商的推送服务。
+
+早些年像语音识别、图像识别、地图导航这些高精尖的技术，普通中小公司是没有机会去使用的，或者要付出昂贵的成本。而现在这些高端技术，都有服务提供。如果你有一个好的想法，不用担心技术会限制你的想象力，借助这些服务，你可以实现你的想法。
+
+早些年的开发团队，服务端比前端人数要多，因为那时候界面简单，而后端需要实现很多数据库增删改查的逻辑。现在的趋势是，界面越来越复杂，而后端服务越来越强大，借助一些云服务甚至不需要去写程序，就能实现服务端API供前端调用。比如我曾开发过一个微信小程序，后端用的[LeanCloud](https://leancloud.cn)的服务，不需要写后端代码就有一个不错的后端API服务。
+
+如果你从软件工程的角度去看云计算，它本质上是在将那些与业务无关的，而又很重要的基础设施、技术，作为一种标准服务提供，让你在软件开发时，只需要专注于业务所独有的部分，从而可以极大地减少开发工作，提升开发效率。
+
+随着云计算的普及，软件工程的标准化、模块化也慢慢出现了一线曙光，希望未来构建软件系统，也能像盖房子一样，通过标准化降低开发成本和难度。
+
+人工智能是另一个现在很火的技术，Alpha Go在围棋上战胜了人类，无人驾驶也有了突破。另外，人工智能在软件工程领域，也有了一些应用和尝试，比如说微软开源了一个人工智能的项目叫[Sketch2Code](https://github.com/Microsoft/ailab/tree/master/Sketch2Code)，可以把UI设计草图转成 HTML 代码，也就是一部分开发工作未来也许可以被人工智能替代了。
+
+阿里巴巴在尝试智能化运维：《[阿里智能运维平台的演进：从自动化到无人化](https://dbaplus.cn/news-134-2072-1.html)》，也就是将人工智能应用在运维领域，从而让人工智能去替代人工的很多操作。在测试领域，虽然还没有见到有成功的用人工智能替代人工测试的案例，但是自动化测试替代了大量手工测试是一个可见的趋势。
+
+现阶段，这些应用只是一个开始，但不会是结束，未来会有更多云服务、人工智能在软件工程领域的应用，会对软件开发的分工协作产生更多影响。
+
+但云服务、人工智能再强大，也难以替代那些创造性的劳动，也就是那些你业务和项目所独有的东西，比如说你对业务的抽象和设计，测试用例的设计，对整个项目过程的组织。
+
+## 在软件工程中，技术是工具
+
+对于像微服务、云计算、人工智能这些新技术，如果站在技术角度看，技术人员永远有两种态度：拥抱新技术和抵触新技术。
+
+但如果你站在软件工程的角度去看技术：**技术服务于架构设计，架构设计服务于业务，业务服务于商业。**也就是本质上来说，技术是为项目服务的工具。
+
+做一个项目，首先是要去解决一个商业问题，比如说你要网上卖东西。然后基于这个商业问题，你要设计一个业务，比如做一个在线商城系统。当你确定了你的业务，你再去设计出适合这个业务的架构，比如设计一个三层架构。最后架构设计好了，你再去选择适合这个架构的技术，比如PHP+MySQL。
+
+但现实中常常不是这样的，开发人员学会了微服务的技术，就像有了一个锤子满世界找钉子，所以当你需要一个在线商城系统，他会给你按照微服务搭一个架构出来，也许你只要一个简单的PHP+MySQL系统就足够了。
+
+或者说最开始你的架构就是简单的三层架构，能很好地满足当时的需求，然后业务不断壮大，于是服务越来越大，团队也越来越大，沟通成本非常高，非常有必要对团队进行分拆。那么这时候微服务就是适合你的架构，而你的技术负责人不懂微服务，也很抵触微服务，就不太可能推动这样的转变。
+
+对于这些新技术，如果只是从技术角度去看，就会更多考虑这个技术喜不喜欢，酷不酷，难不难学，而不容易考虑到如何更好地去为架构服务。
+
+但要是从软件工程的角度，就会把技术当作工具，去学习了解这些新技术，然后进一步思考：这个技术能解决什么问题？应用在项目中有什么样的优缺点？
+
+当你不仅仅是从技术角度去看这些新技术，而是能同时站在软件工程角度看这些新技术时，就能真正的让技术去为架构服务，让架构去为业务服务，从而帮助业务产生好商业价值。
+
+## 总结
+
+不管是现在还是将来，你总是免不了要去面对新技术。从技术角度去看新技术，也许你会兴奋，也许你会抵触，但是如果你跳出技术角度之外，站在软件工程的角度去看新兴技术，你会有不一样的收获。
+
+技术架构等同于组织架构，当你在设计系统架构，你同时也在设计你的组织架构，反之亦然。当你纠结微服务的拆分粒度，不妨看看你的组织架构是不是能和微服务架构匹配。
+
+云计算、人工智能这些新兴技术也逐步改变了分工协作，云计算这样的基础服务，可以降低开发成本，让你可以专注于业务开发；人工智能和自动化技术的发展，也逐步替代了原有的像手工测试、手工运维的工作。但对于创造性的劳动，例如业务的设计和抽象，测试用例的设计和项目过程的组织，是不太可能会被替代的。
+
+最后，技术是工具。技术服务于架构设计，架构设计服务于业务，业务服务于商业。对新技术，保持学习和了解，知道新技术能为你解决项目中什么问题，就像工具一样，选择合适的技术，让技术为架构服务。
+
+## 课后思考
+
+你是怎么看这些新技术的？你有没有应用这些技术在你的项目中？有没有经验教训可以分享的？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/经典案例解析篇/“一问一答”第5期（内含彩蛋） | 22个软件开发常见问题解决策略.md

@@ -0,0 +1,303 @@
+<audio id="audio" title="“一问一答”第5期（内含彩蛋） | 22个软件开发常见问题解决策略" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0b/63/0bd6aca575e031b6af8a877b7d427363.mp3"></audio>
+
+你好，我是宝玉。恭喜你完成了经典案例解析篇的学习，这也意味着你坚持到最后，完成了我们专栏所有内容的学习。
+
+学习软件工程的知识，最终还是为了要能去应用学到的知识。案例解析就是帮助你结合日常生活中一些常见的现象，去站在软件工程的角度思考和分析。
+
+也许你所在的是一个小团队，日常并没有注意对软件工程的应用，但团队小不是拒绝应用软件工程的借口，小团队一样要做好团队的建设，基于软件工程做好流程建设。
+
+也许你团队的软件工程已经很好了，但你做个人业余项目却总是失败告终，不妨用学到的软件工程知识去分析一下，看问题在什么地方，又该如何去改进，才能做出成功的项目。
+
+也许你也经常在网上关注一些软件开发的信息，当你再看到一些失败的软件项目案例时，不仅仅是当作一个有趣的故事，不妨去站在软件工程的角度，看看它失败的原因是什么，从别人的失败案例中吸取经验教训。
+
+也许你日常也关注开源项目，但只是关注技术层面，以后不妨也站在软件工程的角度去看看这些开源项目是怎么运作的？有哪些可以学习借鉴的地方？
+
+也许你身在大厂或者关注大厂的开发实践，那么不妨多学习和观察大厂的软件工程实践。因为大厂之所以成为大厂，对软件工程的应用自然是有其独到之处，学习大厂能帮助你拓宽视野，提升软件工程知识水平。
+
+也许你为微服务、云计算、人工智能这些新技术兴奋或者焦虑，跳出技术角度之外，站在软件工程的角度去看新兴技术，你能有不一样的收获。
+
+我对这些案例的分析，都只是为你提供一种不同的视角，帮助你从软件工程的角度看工作中遇到的问题。相信你在学习之后，也可以利用学到的知识，自己去观察软件工程实践，去应用软件工程知识，发现软件工程之美。
+
+今天加餐，继续分享我们专栏的精彩问答和留言，这些问答和同学们的分享都是对专栏内容的最好补充，希望可以帮助你更好地学习和理解软件工程知识。
+
+## 一问一答
+
+No.1<br>
+**hua168：**小团队比较乱的话，最好是规范哪些关键流程？比如我们小团队开发，首先看这个功能有没有开发过，如果是开发过，就直接基于以前开发过的代码改。这就导致运维有问题，有些路径没有替换完，手工输入命令可以运行，用shell脚本监控发现程序异常，就重启，结果就报错了，用脚本死活启动不起来。然后发现没有路径及文件，叫开发改，要一拖再拖，都不愿意改。
+
+**宝玉：**流程规范的建立是一个逐步的过程，发现单个的问题，首先解决问题，解决完后就需要思考一下：是不是可以通过流程规范规避类似问题。
+
+就拿你这个例子来说，可以先把CI持续集成环境搭起来，然后在发现这个问题后，就针对这个路径的问题，提一个Ticket，要求补上这部分的自动化测试代码。这样以后每次提交代码，CI都会自动运行这个测试，出问题了就能及时发现，不至于到了生产环境再发现。
+
+开发人员任务多可以理解，但是你需要把这些任务通过任务跟踪系统统一管理起来，写一个Ticket给他，排上优先级。等其他任务忙完，就该把这个任务给做了。
+
+所以小团队乱，任务跟踪管理、开发规范，这都是需要优先建立的流程规范。
+
+No.2<br>
+**Joey：**研发过程文档，是否有必要进行统一模版，比如方案设计文档、功能测试报告等。如果不设置模版，大家写的五花八门，别人不好检查；如果设置模版，研发人员又说限制他们的想象力。
+
+**宝玉：**我倒是觉得有模板的文档好写一点，填空就好了。对于文档模板，我没有什么建议，毕竟每个公司情况不一样。我经历过的公司没有强制规定要模板的，但会提供两种模板，一种是风格样式的，字体颜色等都采用公司品牌的风格；一种是基于内容的模板，把大标题小标题都列出来，写的时候填内容就好了。**文档审查重点是检查内容，而不是格式。**
+
+No.3<br>
+**Charles：**小团队可能就10来个人，每个岗位可能就1～2个人，这种情况下做内部分享，希望大家都来参与，那么分享内容不好把控；如果太局限于本岗位知识，其他岗位人员参与度不高，效果也不明显。如果只是本岗位的知识分享，那么就2、3个人讨论下就行了，有什么好办法解决这个问题？
+
+**宝玉：**可以设定一些学习的课题分享，比如说最近有什么新技术很火，但是大家都不知道具体是什么，也很想了解，可以让一个人去学习研究，然后跟大家一起分享。分享的过程其实以讨论为主，分享的人也不需要太多压力，自己也能学到东西，其他听的人在讨论的过程中也能学到东西，共同学习提高。你可以从中做好主持的作用，最好提前也学习准备一些。
+
+No.4<br>
+**yellowcloud：**我们目前项目使用的管理工具是TFS，它好像也自带CI和CD功能，我想请问一下，它和文中介绍的Azure DevOps，哪个好用呢？
+
+**宝玉：**Azure DevOps应该是TFS的升级版，如果在线托管的话，你应该考虑用Azure DevOps。
+
+No.5<br>
+**乐爽：**详细的需求分析是放在迭代内进行的，但此时的需求是一个很小的点，所以不会占据整个迭代太多的时间，是吗？如果在迭代内发现需求方案不合理，放入到下一个迭代，这是否合理呢？
+
+**宝玉：**是的，因为一个迭代内的需求不多，所以需求分析相对时间较短。如果一个需求在一个迭代内做不完，可以延到下一个迭代。如果一个需求不合理，那么需要重新讨论，讨论清楚了再决定是放当前迭代还是后续迭代。
+
+No.6<br>
+**hua168：**小公司复盘，是这个弄好了，那个又变差了，也不想着怎么改进，强制执行大家都很抵触，怎么办？
+
+**宝玉：**如果是解决一个问题又导致了新的问题，按下葫芦起了瓢这种情况，需要多在整体思考一下原因，尤其是项目的整体流程和开发计划方面。推广开发流程导致大家反感，觉得时间紧还搞其他事情，解决这个问题，需要两方面入手：
+
+<li>
+首先要反省项目计划，如果只是加要求而不给相应时间计划，比如说要求写自动化测试，而不留出写自动化测试时间，那当然会抵触。所以相应要制定出更好的项目计划，避免为了砍时间而砍时间，给开发留出时间去设计、去写测试代码，不然就算你制定一个很紧的计划，还是要花很多时间修Bug，最终花的其实时间差不多。
+</li>
+<li>
+提升大家的认知，不仅是团队内部，还包括团队外部，你的老板和业务部门，获得他们的支持。让大家知道磨刀不误砍柴工：前期投入时间在开发质量上面，后期会节约大量修改Bug的时间。
+</li>
+
+No.7<br>
+**浮生：**目前执行过程中发现，如果不是自己负责的功能，团队成员在审查其他人代码的积极性并不高，再加上各自任务都很紧，即使审查也是匆匆过去，有时并未起到应有的效果，请问在流程机制中有方法可以提高审查的效果吗？
+
+**宝玉：**很抱歉我暂时没有好的建议。可以尝试的是：
+
+1. 首先强制Review才能合并是必须的；
+1. 让PR小一点，减少Review的难度；
+1. 时间进度上，考虑上代码审查的时间，毕竟代码审查是磨刀不误砍柴工；
+1. 鼓励资深的程序员做好带头作用，可以把Review代码参与度和Review代码质量作为绩效的一部分；
+1. 你可以每天检查一遍审查通过的代码，对于明显有问题的，私下找可以找相关人谈一谈。
+
+No.8<br>
+**胡鹏：**我现在遇到一些情况，需求出来了，估时的时候，通常有两种心理。第一种， 尽量压缩自己的时间，当然领导也会压缩时间， 这时心里想的是要好好表现，把时间压短一点；第二种，尽量多一点充裕时间，当出现问题能有足够的时间来解决，不至于延期。对于估时，取一还是取二还是在一和二之间平衡？
+
+**宝玉：**太紧和太松的时间估算都不可取，应该是尽可能准确地选择接近实际情况的时间，并且留有一点富裕应对意外情况。时间太紧了要加班加点还要被质疑能力；时间太松了会影响以后估算时间的真实性。
+
+准确地估算时间是程序员能力的一种，做好不容易，一些建议供参考：
+
+1. 充分理解清楚需求，知道要做什么，这是基本前提，不然做着做着发现需求没搞清楚，那一定是要多出很多额外时间。
+1. 非功能性的需求，比如说写自动化测试、搭环境、重构代码这些任务也应该作为计划的一部分，要把时间算进去。
+1. 拿到任务后，将任务要分解到尽可能细，越小的任务力度估算越准确，而且在跟领导说时间进度的时候也有理有据，底气足扛得住。
+1. 综合考虑任务并行的情况，给线上版本修Bug、开会这些时间也要算进去，想想每天真正有效的工作时间是多少。
+1. 计划保持及时更新，当出现延迟或者有延迟风险的时候，或者进度提前，需要及时和项目负责人沟通，作出调整，避免影响整体项目进度。
+1. 留一点余量，应对突发情况。
+
+反过来，如果你是领导，在下属估算时间的时候，也要参考上面的一些建议，让计划尽可能地接近真实情况，而不是下属给一个很紧的时间就按照这个时间执行，最后得加班加点，加班是为了应对突发情况的，而不是正常情况。
+
+No.9<br>
+**Joey：**1.如何更好地推广SonarLint白盒扫描工具？2.如何要求各开发团队更好地，有效地做代码走查，而不流于形式？（我们现在使用Gerrit）3.如何要求开发人员有效实施单元测试？
+
+**宝玉：**这种开发流程问题肯定还是要自上而下推才能推得动。我觉得首先应该先找一两个小项目组试点，摸索出一套适合你们的最佳实践，形成流程规范，比如说基于Github Flow，把CI（持续集成）环境搭建起来（如果没有的话），把你说的SonarLint、自动化测试加入到CI流程中。再就是逐步扩大范围，在更多项目组推行最佳实践和流程规范，并且改进流程规范。最后就必须要借助行政手段强制推行了。
+
+No.10<br>
+**Liber：**我们专栏之前的文章中，以本文注册用户为例，分别写了小、中、大型测试用例，但实际开发过程中，如何权衡对一个场景，是该小、中、大测试都写，还是只写部分？
+
+**宝玉：**实际开发中，理论上来说，是一个场景大中小测试都要写的。通常情况，开发写小型测试和中型测试，测试写大型测试，或者开发帮助写大型测试。小型测试：中型测试：大型测试比例大约为 7:2:1。小型测试尽可能多覆盖，不要求100%，谷歌是85%。中型测试覆盖大部分用户使用场景，小型测试覆盖主要用户场景。
+
+No.11<br>
+**OnRoad：**客户需求频繁变更，大领导迫于客户压力全盘答应，导致开发节奏被打乱，除了量化风险上报之外，还有什么好办法？
+
+**宝玉：**需要和你的领导私下协商，需要在他的帮助下一起作出一些调整：
+
+1. 要设立流程提高客户变更需求的成本，可以需求变更，但不能太过于频繁随意；
+1. 缩短开发周期，采用迭代模型或者敏捷开发，2～4周发布一个版本，每个版本实现当前已经确定的最重要的需求，在一个版本内不接受需求变化，变化的需求放在下一个迭代中实现。
+
+No.12<br>
+**探索无止境：**对于专栏中提到的“测试验收通过后，预部署分支的代码会部署到生产环境。”我的理解是，部署的分支的代码，上线测试没问题之后，再把这个代码合并回主分支，这样理解对不对？
+
+**宝玉：**这里有两种策略：
+
+1. 每次线上Bug，修复后只合并到预部署分支，最后统一把预部署分支合并回主分支。优点是简单，缺点是合并时可能会有很多冲突；
+1. 每次线上Bug，修复后同时合并预部署分支和主分支。优点是以后就不用再合并回去，还有可以及时同步Bug修复，缺点是麻烦，每次要cherry pick。
+
+我们项目中选的是后一种策略，因为能及时同步Bug修复到主干，这一点对我们很重要。
+
+No.13<br>
+**maomaostyle：**在敏捷开发中，如何结合标准的项目管理方法呢？比如wbs任务拆解，风险识别，因为这两点相对于项目的整体情况已经应该拿到了足够多的输入，但是在敏捷的背景下需求等细节都是不清晰的。另外比如最小化原型产品更难以结合大而全的项目管理方法了吧？
+
+**宝玉：**敏捷开发中，wbs一样可以帮助分解任务，然后把任务拆分到Sprint，还可以设置里程碑。风险识别应该和用什么开发模型没太大关系，关键还是识别和确定应对策略。最小化原型法可以是小瀑布开发模型也可以是敏捷开发，**关键在于需求要定义清楚，要小。**
+
+No.14<br>
+**宝宝太喜欢极客时间了：**方法论、方法、模型这些名词具体怎么理解？敏捷开发属于哪一种？实施敏捷软件架构设计等文档都可以省略吗？如果文档都省略了，那开发人员离职后新接手人员怎么快速熟悉项目呢？公司的知识积累怎么体现？
+
+**宝玉：**敏捷宣言说的：“工作的软件 高于 详尽的文档。尽管右项有其价值，我们更重视左项的价值。”没有否认文档的价值，也不代表实施敏捷软件架构设计可以省略文档，只是没有必要写过多繁重的、没有价值的文档。
+
+另一个角度来说，也不要过分夸大文档的作用，离职交接，光文档还不够，还离不开人和人之间的互动，交流；公司的知识积累更多靠的是人、代码、文档、流程规范、文化等多方面因素综合的结果，而不光是文档。
+
+No.15<br>
+**Tiger：**我们做的项目外包，项目组的人数是固定的，每次都是项目组要离职一个才会再招一个人进来补充，这种情况无法培养技术后备，人员风险怎么把控？
+
+**宝玉：**这种确实有点困难，有两种策略你可以考虑：
+
+1. 减少对人的依赖，让人来了跟流水线工人一样可以马上上手。如果你的项目类型比较类似，其实可以考虑将相同部分通过架构简化，通过配置或者定制化适用于不同项目。
+1. 培养现有的人，提升现有人的能力，提升归属感，都不容易做到，但都可以试试，或者你也可以想到更好的办法。
+
+No.16<br>
+**ailei：**除了《人月神话》《人件》，还有哪些偏管理的软件工程的书？
+
+**宝玉：**有几本项目管理的书可以看看：<br>
+《项目管理修炼之道》<br>
+《项目管理-计划、进度和控制的系统方法》<br>
+《软件项目成功之道》<br>
+《做项目，就得这么干!》
+
+No.17<br>
+**成：**如果一周开发，一周测试，测试的时候，开发人员开始下个迭代，那Bug啥时候修改呢？如果下一个迭代期间也要修改Bug，那本次迭代工作也进度也难以保证一样，不是很理解如何操作？
+
+**宝玉：**是这样的，开发当前Sprint新功能的时候，同时要修改上个Sprint的Bug。比如说这周是Sprint 1.2，那么同时要修改Sprint1.1的Bug。而且Sprint 1.1的Bug的优先级要高于Sprint 1.2新功能的开发。
+
+其实改Bug通常不需要花太多时间，所以一般影响不大。如果偶尔Bug修改时间过长，不能如期完成的，需要推迟上线。如果团队不适应这种节奏，那么应该延长Sprint周期，例如两周一个Sprint。
+
+文章的例子只是一个参考，并不是说一定要这样做。
+
+No.18<br>
+**E：**软件开发的过程和方法之间的关系是什么？
+
+**宝玉：**软件开发过程就是指开发软件时整个过程的开发模式，比如说瀑布模型还是敏捷开发。选择了开发过程，你就需要有具体方法来执行。
+
+比如你选择了瀑布模型，整个软件开发过程就是按照瀑布模型的分阶段来进行，对应的方法就是瀑布模型中的方法，例如需求分析、架构设计；如果你选择了敏捷开发，则整个开发过程就是一种敏捷迭代方式，后面的方法对应的就是敏捷开发的一套方法体系，例如Scrum、用户故事、持续集成等。
+
+No.19<br>
+**刘晓林：**关于Ticket工期估算我有个疑问。团队中一般都是一两个人负责一个小模块，之所以这样做是为了提高工作效率，避免同一段代码每次迭代都由不同的人去修改，因为大家对自己的小模块很熟悉，所以工作效率很高。但这样带来的问题是，团队成员对其他人负责的模块不熟，所以工期估算只能由模块负责人自己完成，别人很难帮上忙。这种情况怎么解决？
+
+**宝玉：**这是个好问题。我的建议是模块要换着做，宁可慢一点，不然的话，不仅仅是其他人不能帮忙不能估算，万一有人离开团队了，会更麻烦的。如果团队不大，做的时候分工都不要太细，都不要太局限前端后端，这样其实对整个团队来讲是最好的，互相能替换。当然，也不要着急，慢慢来，不要一下子改变很大。
+
+No.20<br>
+**谢禾急文：**我想到一个想法，就是通过用一个工具记录我自己开发过程中遇到的所有Bug，通过记录、分析、反思这些Bug，能够有助于提升我的编程能力，有助于避免犯同样的错误。我觉得你上面说的那些工具，能够满足我的需求。如果有一个网站，能够提供Bug记录、分享、解答的功能，是不是能够满足某些用户的需求？(好像stackoverflow就是这样的工具)
+
+**宝玉：**我觉得是有帮助，但这个问题的关键在于分析反思Bug。自己对自己Bug的反思才是价值最大的，其他人看过之后不一定能有那么大的共鸣，因为一个Bug都有复杂的业务背景，是很难被记录，缺少上下文也很难理解。StackOverflow是很有价值的，因为它是从问题切入，而问题是有很多共性的，很容易引起共鸣。
+
+No.21<br>
+**纯洁的憎恶：**我很早就知道知识体系的重要性，我也比较重视构建知识体系，但并没有什么亲测有效的方法，且对知识体系是个什么样的存在缺乏体感认识。可能还是学得太浅，用的太少？
+
+**宝玉：**方法不是最主要的，最多让你学习提升一点速度。关键还是坚持，多练习多实践。
+
+从知识转变成技能，一定需要通过反复的刻意的练习，才能形成条件反射，最终掌握。没有任何学习方法能替代练习，最多有催化剂，可以加速练习效果的学习方法。
+
+还有就是对技术的学习，不能太依赖于工作上的输入，工作上如果项目好用户多，那还是很有挑战的，但大多数时候没有那么多挑战，可能就是个增删改查，那么几年的工作经验可能只是简单的重复，不能达到刻意练习的效果。那还是要在工作之外寻找一些练习的途径，比如上次我建议的：自己做一点项目、参与一些开源项目。
+
+要想对知识体系有体感认识，还是建议先在一个领域有深度，有一棵树了才能想像出来森林是什么样子的，不然只能看到一片灌木丛。这过程难免要踩很多的坑，经历很多次的失败和挫折，反复的思考、总结和重试。
+
+No.22<br>
+**titan：**敏捷开发在一些小公司落地是比较难的，原因我认为主要是人的综合素质达不到，敏捷的一些思想和原则不能落地，比如团队成员人人平等的价值观，在小公司，牛人比较少，大部分都是比较弱的人，你让牛人跟他们强调平等，似乎是不太可能的事情。
+
+**宝玉：**平等和牛人，这其实不矛盾的。就像蜘蛛侠的叔叔说的：能力越大责任越大。牛人担负的责任会更大，贡献多，收入也多。
+
+一个健康的开发团队，无论大小，都应该是有梯队的，有资深的，有新人，资深的（牛人）负责架构、模块划分、实现核心模块，新手则基于架构实现具体模块。不然单靠个别牛人完成功能也是不现实的。敏捷开发在小公司落地，最根本还是真的懂敏捷，能应用好敏捷的原则和实践，不要追求形式化，不要走捷径。
+
+## 精选留言
+
+alva_xu ：<br>
+就“选择适合你的软件开发模型”，这一点，我谈谈想法。软件开发模型是瀑布还是敏捷对于软件开发管理来说有很大的不同；但即使采用瀑布模型，对于团队管理来说，我们是可以借鉴敏捷模型的。
+
+比如，我们可以采用看板管理来提高任务管理的效率和透明度，可以通过站会来加快问题的沟通，对于“建立外部提交需求和任务的流程”，我们也可以借助敏捷管理的思路，通过每天站会或者周例会的时候，一起做个新需求评估。对于技术交流，也可以像敏捷团队里说的培养T型技能的人员为目的来开展。
+
+而且，先通过团队管理方式的转变，培养大家的敏捷文化，然后再切到敏捷开发模式，就会更加顺畅。我觉得，小团队管理，一定要培养自主自治合作分享的文化和能力，通过用轮值Scrum master 的办法，一点点提高这方面的文化和能力。
+
+相关阅读：[40 | 最佳实践：小团队如何应用软件工程？](http://time.geekbang.org/column/article/98985)
+
+纯洁的憎恶：<br>
+抛弃妄念，脚踏实地。切忌追求过于宏大的目标、过于新奇的技术，而最终难以落地。做事要有边界和约束，向死而生才有效率。专业短板可以尝试自行补齐，也可以求助他人取长补短。
+
+相关阅读：[41 | 为什么程序员的业余项目大多都死了？](http://time.geekbang.org/column/article/99298)
+
+## 思辨时刻
+
+幻想：<br>
+我觉得两周为一个发布周期，很有可能导致代码质量低下。例如：两周一迭代里，我们可能没有时间在上个迭代里就做好下个迭代需求的分析，只能遗留到当前迭代，这个时候，需求分析、代码设计、接口设计就要花好几天。好了，由于限制死了两周要发布一次，导致测试人员死盯着发布日期，进行倒推，让开发人员尽量在某个时间点提测，不然迭代上线就风险很大，这样就导致了开发这边压力很大很大，开发时间短，代码质量低，提测后，又有各种Bug，也进而阻碍测试进度，整条线都非常疲惫紧张。
+
+最惨的是，由于测试人员急着测试，也未能做到详细测试，就上线了。又是各种线上Bug。因此这种两周一上线，会容易让人死盯着上线日期，给全部人员带来很大的压力，相当于是给自己挖坑和约束了，很不应该的。
+
+我觉得软件工程里，开发阶段是最关键的阶段，得给到合理的时间，不然这个阶段被动了，乱了之后，就会产生一系列的不好级联反应。因此，我觉得应该有开发人员来把控节奏，给出工作量，给出哪些可以优先测试。
+
+宝玉：<br>
+好问题！你说的担忧完全合理，也确实可能会出现这样的情况。
+
+我来解释一下为什么2～4周是可行的。我们假设你现在的项目是三个月周期，一共是12周，然后你大约2～3周在需求，2～3周架构设计，4周左右在编码，2～3周测试。
+
+那也就是说需求分析期间，其实开发、测试做不了啥事，架构设计的时候，主要是架构师在忙，编码的时候，主要是程序员在忙，测试的时候，开发和测试在忙。
+
+再假设你大概要完成10个功能，也就是这10个功能从设计到开发预计花了10周时间，平均每周一个功能。
+
+如果换成2周一个迭代，那么我们可以考虑每个迭代只选取2个功能，但是在这2周，整个团队的运作可能是这样的：
+
+迭代v1.1（2周）<br>
+产品设计，准备下一个迭代v1.2的产品设计；<br>
+开发，设计和开发这个迭代v1.1的功能，同步修复发现的v1.0的Bug；<br>
+测试，测试上一个迭代v1.0开发好的功能；<br>
+开发完成后，部署开发完成的v1.1到测试环境；<br>
+发布测试验收完的迭代v1.0。
+
+迭代v1.2（2周）<br>
+产品设计，准备下一个迭代v1.3的产品设计；<br>
+开发，设计和开发这个迭代v1.2的功能，同步修复发现的v1.1的Bug；<br>
+测试，测试上一个迭代v1.0开发好的功能；<br>
+开发完成后，部署开发完成的v1.2到测试环境；<br>
+发布测试验收完的迭代v1.1。
+
+也就是你差不多还是有两周时间开发新功能，两周时间测试，但是每两周可以发布一个小版本，而且整体节奏比较平缓。如果到时间内完不成所有功能，那么就发布完成的，没完成的放到下一个迭代，这样可以保证每周都可以发布。配合代码审查和自动化测试以及基于分支开发的流程，可以保证合并后代码质量相对是可靠的。
+
+如果这样操作有难度的，那么采用4周一个迭代，但是每个迭代功能减少，还是一样可行的。还有每个迭代结束后的上线发布，可以有两种类型，小迭代可以不发布生产环境，只是测试环境，几个小迭代后再发布生产环境。也就是说，方法其实是有的，观念上可以先调整，因为这样的迭代周期肯定是可行的。
+
+相关阅读：[40 | 最佳实践：小团队如何应用软件工程？](http://time.geekbang.org/column/article/98985)
+
+纯洁的憎恶 ：<br>
+深深地感受到，软件工程不是为了创造最伟大的软件项目而存在，却是为了保障每一个项目的成本、质量、工期、目标等等可控而存在的。
+
+果然如此：<br>
+软件工程是过程控制的方法论，而产品设计才是保证伟大的产品，两者应该结合。
+
+相关阅读： [42 | 反面案例：盘点那些失败的软件项目](http://time.geekbang.org/column/article/99775)
+
+kirogiyi ：<br>
+软件工程方式的使用，或多或少会受到最高领导层管理理念的影响，这从各大公司的组织架构图可以看出一些端倪，比如：Amzon的组织架构图，领导力准则得以全面体现，精确而清晰；Facebook的组织架构图，更利于信息的快速传递和响应，管理方式相对其他公司更加扁平；Google的组织架构图，上层倾向于层级管理，下层倾向于扁平管理，适合于公司指令的上传下达，也适合于不同层级之间的工程师进行沟通交流进步成长。
+
+如果领导层倾向于规范化流程化，那么采用Amazon的开发方式，明确的分工，明确的目标，这使得贝佐斯的领导力、执行力、远见力得以全面实施。
+
+如果领导层倾向于激进和冒险，那么采用Facebook的开发方式，只要你够积极，不断创新，即使犯错也是一种进步，不得不说这种方式在小公司开发团队中实施起来更可行，毕竟小公司需要快速响应，快速迭代，快速决策，不可预料的事情比较多。
+
+如果领导层倾向于人性的发挥，那么采用Google的开发方式（个人认为适合资金比较雄厚的公司），它能让工程师在舒适的环境中充分发挥所长，并去尝试开拓自己感兴趣的新的技术领域，各自都对自己的领域精雕细琢，质量无形中就得到了一定程度上的保证。
+
+从上面来看，我算是一个激进和冒险的人，更喜欢Facebook的开发方式，使我能够在不断的创新和错误中成长。
+
+宝玉：你这个角度也很新颖！一个公司的文化和创始人的性格是有很大关系的，这些文化都没有绝对的好坏，都成就了伟大的公司，合适的就是最好的
+
+相关阅读：  [44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的？](http://time.geekbang.org/column/article/100716)
+
+传说中的胖子：<br>
+我以前学习技术，就是看怎么实现，或者说是怎么用；现在学习技术，是学习技术在什么情况下产生的，适合解决什么场景下的问题，需要的资源是什么。多学习一些技术以及使用场景、然后在出现问题的时候可以结合实际情况做多种选择，根据其他因素选择一个比较合适的方案，方案确定了，技术实现就会方便很多。因为在IT行业边缘化的三线城市，也不知道这种想法有没有什么遗漏，希望老师帮着补充。
+
+宝玉：<br>
+我觉得从思路上是没问题的，我从实践的角度提一点建议：技术只有通过实践才能真正清楚其优缺点和使用场景。建议有些新的流行的技术，哪怕项目中不使用，业余时间也可以自己去试试，这样能给你未来的项目实践有更好的指导。当然也不要走偏，学了一个新技术就要应用到实际项目中，如你所说：学技术的目的是为了帮助你更好的选择，选择了合适的之后才是应用。
+
+相关阅读：  [45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术](http://time.geekbang.org/column/article/101256)
+
+## 文末彩蛋
+
+至此，我们专栏的全部加餐内容已经更新完毕。非常感谢为“一问一答”专题贡献精彩留言的同学们，是你们为专栏提供了精彩的问答、新鲜的案例、行之有效的学习方法，感谢你们将自己的获得分享给大家。
+
+在此，极客时间团队为入选专题“精选留言”和“思辨时刻”的同学给予奖励。
+
+留言贡献率最高前3名：
+
+- alva_xu
+- 纯洁的憎恶
+-  kirogiyi 
+
+以上3位同学，每人将获得极客时间“Hello，World，超大防水鼠标垫”一个，极客时间团队将在一周内发货。
+
+热心留言贡献者：
+
+阿杜（javaadu）、老张、阿银、hyeebeen、起而行、西西弗与卡夫卡、Felix、MiracleWong、青石、刘晓林、一路向北、果然如此、dancer 、陈珙、Y024、nigel、_CountingStars、bearlu、Charles、林云、邢爱明、成、毅、yasuoyuhao、幻想、传说中的胖子。
+
+以上26位同学，每人将获得极客时间**15元电子优惠券**一张，优惠券将于6月18日18点前发放到以上同学的极客时间账户，优惠券有效期截止为**7月15日**。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。