课后感
只有经过思考，才能真正将知识转化为自己的所得。
所以加长“课后感”篇幅，而且位置置顶。
关于工作效率
提升效率的方法有很多，课程中引用到了“高效能人士的七个习惯”。特意把中英文摘录下来。
- 高效能人士的七个习惯 (7 Habits of Highly Effective Executives)
1. Be proactive（主动积极）
2. Begin with the end in mind（以终为始）
3. Put first thing fisrt （要事第一）
4. Think Win/Win （双赢思维）
5. Seek first to understand then to be understood （知彼解己）
6. Synergize（统合综效）
7. Sharppen the saw（不断更新）
- 老马的话。"if it hurts, do it more often."
我的一个理解是，只有放大痛点，我们才会认真的考虑解决问题的方法。课程中的问题是CI，CD。生活中有更多的问题。每个人都有自己的智慧，不逃避问题，反复的做，使用PDCA，事情总会趋向好的一面。"Practice makes perfect."的另一层解析。
"Fail Fast"的中文解析。直接从字面翻译，"让失败来得更快"，似乎没说到点上且容易误解。课程的另一个说法更贴合观点。”尽早暴露问题。“
工作方法，番茄工作法和吃青蛙
紧急/重要的四象限法其实并不是一个好的排序方法。基于现有的信息做决策，减少并行任务，FIFO，优先完成有明确Deadline的事项，先完成一天中最难的事项”Eat the Frog！“，使用番茄工作法，每个番茄钟进入心流状态，番茄钟之间进行事项调整。和Agile一样，Time-boxed，Retrospective。
25 | 有哪些方法可以提高开发效率？
原则：主动积极、以终为始、要事第一
积极主动，行动起来改变自己
减少关注圈，扩大影响圈。
不要总盯着自己无法改变的部分，你需要要多花时间精力在影响圈上。
接受不能改变的，改变能改变的，尽量扩大可改变项的范围。
以终为始，想清楚再开工
要做到“以终为始”，就是在做事情的时候注意三点：目标、原则和计划。
经常停下来想想目标。
制定原则
先运行再优化 (Make it Work, Make it Right, Make it Fast)
不复制粘贴代码 (Don’t repeat yourself)
每个 Pull Request 要尽可能小
公开自己的计划
要事第一，把时间用在刀刃上
重要紧急的事情马上处理。
重要不紧急的要事，要花最多的时间在上面。
紧急不重要的事凑一起集中做。
不重要不紧急的事情能不做就不做。
要事第一，就是要保证你有限的时间用在最有价值的事情上。
26 | 持续交付：如何做到随时发布新版本到生产环境？
持续交付细分分成持续集成、持续交付和持续部署三个概念。
持续集成，就是持续频繁地将代码从分支集成到主干，并且要保证在合并到主干之前，必须要通过所有的自动化测试。
持续交付，则是基于持续集成，在自动化测试完成后，同时构建生成各个环境的发布包，部署到测试环境，但生产环境的部署需要手动确认。
持续部署，是在持续交付的基础上，对生产环境的部署也采用自动化。
集成、部署和交付的发展史
集成，指的就是每个人把自己开发的分支代码，合并到主干上，以便测试打包。
瀑布开发年代，在开发阶段一般不集成。各自开发，在开发阶段差不多快结束了，再一起提交代码到源代码管理工具，让代码集成在一起，再编译、部署发布到测试环境。
问题：由于长时间都是在各自的开发环境运行，每次集成都是很痛苦的过程，会遇到各种问题，比如说编译无法通过、hard code 了开发环境地址、类库版本不一致、API 格式不一致等，通常要持续几天甚至几周才能逐步有一个相对稳定的版本。
持续集成的做法，则是每次有代码合并入主干之前，都进行集成。。代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。
持续集成好处
配合自动化测试，保证主干的代码是稳定的。
频繁集成可以让开发人员总能从主干及时获得最新的代码，不至于像类库、API 不一致等问题到最后测试的阶段才暴露出来。
持续集成难点
搭建持续集成环境。
配合流程规范辅助执行。
一定的自动化测试代码覆盖率，测试通过才能合并到主干。
部署和交付
部署指的是将代码发布到各种环境。
交付则指的是软件产品在测试验收通过后，具备发布到生产环境交付给客户使用的条件。
部署交付的4个阶段
1. 原始阶段
2. 脚本自动化部署
3. 持续交付
4. 持续部署
原始阶段
早些年，部署是一件很麻烦的事情。需要手动获取最新源代码、编译、再需要针对环境修改很多配置。
随着分工的进一步细化，逐步发展成有专门的运维岗位，由运维人员负责部署。而开发人员上线前要写专门的部署文档和检查表，运维人员按照部署文档和检查表一步步部署生产环境。
为了避免部署出问题，会尽量避免进行生产环境部署，几周甚至几个月才会部署一次。
脚本自动化部署
Martin Fowler “如果一件事很痛苦，那么就更频繁的做（if it hurts, do it more often. ）”
每日构建程序自动从源代码管理器下载最新代码，编译、部署程序到测试环境。这样第二天测试人员就可以拿到最新的程序，对前一天修复的 Bug 进行测试。
问题1：开发人员提交的代码有问题，可能会导致当天的编译或部署失败，那么第二天开发人员上班后，还需要手动解决。
问题2：无法解决发布版本的质量问题，还是可能会因为配置错误导致失败，测试环境正常的功能到生产环境就不工作了。
持续交付
持续交付，就是在持续集成的基础上，再进一步，在功能合并到主干后，不仅会进行自动化测试，还会打包，并部署到测试环境中。理论上来说也可以直接部署到生产环境，但是这个环节需要人工确认。持续交付本质上也是把部署和交付这件让人痛苦的事情，更加频繁地去做，从而让部署和发布变得不但不痛苦，反而越来越简单。
持续部署
持续交付，对于生产环境的部署，依然需要有手动确认的环节。而持续部署，和持续交付唯一的不同，就是手动确认的环节都没有了，每次代码从分支合并到主干，在自动化测试通过后，会直接自动部署生产环境，不需要人工确认。这对自动化测试的覆盖率和稳定性要求非常高。对于新功能可能导致的不稳定问题可以对新功能使用功能开关（Feature flag）
该不该应用持续交付？
无论使用何种开发模型，应该尽快将持续集成的环境和相应的开发流程搭建起来。
持续集成/交付/部署的好处：
尽快暴露问题：Martin Fowler 说过，“持续交付并不能消除 Bug，而是让它们非常容易发现和改正。”自动化测试，保证问题在合并到分支之前就被发现；每次合并后就部署到测试环境，让测试人员尽早介入，及时发现问题。
极大提升效率：持续交付让开发过程中从代码合并一直到最终部署，都实现了自动化，极大程度提高效率。
提升质量：每次合并之前都需要通过自动化测试，减少大量错误。
降低项目成本：最初搭建持续交付环境的时候，需要投入一定成本，但从长远看，提升开发效率，提高代码质量，有助于降低项目的整体成本。
虽然现在持续交付还不够普及，但未来就像源代码管理一样，成为开发团队的标配。
如何搭建持续交付环境？
准备工作
持续集成基础
1. 源码管理工具
2. 自动化测试代码
持续交付项目条件
1. 代码构建过程可以反复进行，并且每次构建的结果是一致的、稳定的；
2. 所有环境的配置都存在于源代码管理工具中，不仅仅是代码；
3. 需要自动创建针对于不同环境的发布包；
4. 所有环境的部署发布步骤都必须是自动化的。
选择合适的持续集成工具
27 | 软件工程师的核心竞争力是什么？（上）
28 | 软件工程师的核心竞争力是什么？（下）
软件工程师核心竞争力金字塔
软件工程师的核心竞争力，不是单一能力的体现，而是几种能力和价值的合集。学习能力、解决问题能力和影响力构成了软件工程师的核心竞争力。
学习能力
How 如何提升
首先需要在一个技术领域深耕。只有一个领域的知识你真正吃透，才能有效地共享到其他领域，构成一个知识领域的森林。如果知识浅尝即止，收获的只能是一个灌木丛。
然后往相近的领域逐步横向拓展。
解决问题能力
发现问题、分析问题、解决问题
1. 明确问题，目标是什么，有的放矢，透过现象看本质。
拆分和定位问题，分治思维。
提出解决方案并总结。解决完后，提出预防措施，并考虑其他可能发生问题的地方。
4. 对问题复盘总结。
影响力
How 如何提升影响力
在某个领域做出了足够牛的成绩
做事情超出预期
帮助其他人就是在帮助自己
分享就是学习和打造影响力
总结
软件工程师的核心竞争力，体现在学习能力、解决问题能力和影响力三个方面。
要提升学习能力，要构建好自己的知识体系，首先需要在一个技术领域深耕然后往相近的领域逐步横向拓展。
要提升解决问题的能力，要形成自己的方法论，去发现问题，分析问题和解决问题。
要提升自己的影响力，可以在一个领域深入打造自己独特的有价值的能力，让自己做事情能超出别人的预期，同时乐于分享和帮助他人。
不仅是把事情做成，还要把事情做好；不仅是自己成长，还要帮助其他人成长；最大化的利用好所在平台和行业的经历，转变成你的经验和影响力。工作之外，也多分享，打造自己的品牌。
29 | 自动化测试：如何把Bug杀死在摇篮里？
为什么自动化测试能保障质量？
自动化，代替手工。
覆盖面广，防止修复一个 Bug 而产生新 Bug。
穿刺程序内部，直接对类、函数进行测试。
自动、重复、频繁运行。
有哪些类型的自动化测试？
小型测试，主要针对函数或者类进行验证，不调用外部服务，执行速度快。
中型测试，主要验证两个或多个模块应用之间的交互，可能会调用外部服务，尽可能让所有测试能在本机即可完成，执行速度比较快。
大型测试，对服务整体进行验证，执行速度慢。
契约测试，针对微服务的测试。
怎么写好自动化测试代码？
完整的自动化测试要包括三个部分的测试
验证功能是不是正确：例如说输入正确的用户名和密码，要能正常注册账号；
覆盖边界条件： 比如说如果用户名或密码为空，应该不允许注册成功；
异常和错误处理：比如说使用一个已经用过的用户名，应该提示用户名被使用。
如何为你的项目实施自动化测试？
选择好自动化测试框架
在持续集成环境上跑你的自动化测试（让自动化测试在持续集成上运行非常重要，只有这样才能最大化地发挥自动化测试的作用）
自动测试配合持续集成标准流程
提交代码前，本地跑单元测试，失败则继续修改；
单元测试成功后提交到源代码管理中心，提交后，持续集成服务自动运行完整的自动化测试（包括小型测试，还有中型测试）；
通过所有的测试后，合并到主分支，如果失败，需要本地修改后再次提交，直至通过所有的测试为止。
新项目和老项目的不同策略
新项目，可以在一开始就保持一定的自动化测试代码的覆盖率，可以尝试测试驱动（TDD）的开发模式。
老项目，短期内要让自动化测试代码有覆盖是有难度的，可以先把主要的功能场景的中型测试写起来。
如果时间紧任务重，来不及写自动化测试怎么办？
优先保证中型测试代码的覆盖，把来不及完成的部分，创建一个 Ticket，放到任务跟踪系统里面，后面补上。
30 | 用好源代码管理工具，让你的协作更高效
源代码管理工具发展简史
没有源代码管理工具的时代，在 1972 年之前都没有任何工具可以帮助我们做源代码管理。
本地版本管理，最早的版本控制系统是 SCCS（Source Code Control System），诞生于 1972 年。
集中式版本管理，1986 年问世的 CVS（Concurrent Versions System）是第一个采用集中式的服务器来进行版本库的管理工作。再后来的 SVN（Subversion）则对 CVS 进行了很多优化。
分布式版本管理，分布式版本管理工具的典型代表就是 Git，分布式版本控制系统的整个代码库的副本都可以存储在用户的本地系统上。
如何选择合适的源代码管理系统
网上托管的或者自己搭建。
自己搭建，Git，Gitlab，Gerrit
网上托管，GitHub，Gitlab，Coding（国内），码云、阿里云 Code、百度效率云、腾讯 Git 代码托管、华为云 CodeHub。
如何用好源代码管理工具？
原则一：要频繁的提交。频繁提交，不意味着提交不完整的内容，而是将要提交的内容分拆，并且保证完整性。
原则二：每次提交后要跑自动化测试。
原则三：提交的代码要有人审查。
GitHub 开发流程
GitHub 开发流程的关键在于两点：
有一个稳定的分支，例如 master；
每次创建新功能或者修复 Bug，必须创建一个分支。最后通过代码审查和自动化测试后，才能合并回稳定分支。
Github flow
1. 创建一个分支
2. 提交更新
3. 创建一个 Pull Request
4. 讨论和代码审查
5. 部署测试
6. 合并
