郑晔老的10x程序员工作法学习笔记

10x程序员工作法

by:郑晔老师

问题

忙碌原因

• 本质复杂度(Essential Complexity)

  • 问题本身复杂

• 偶然复杂度(Accident Complexity)

  • 选用方法不当, 导致复杂度上升

事实

• 大部分程序员忙碌解决的问题，都不是程序问题，而是由偶然复杂度导致的问题

解决

• 减少偶然复杂度引发的问题, 让软件开发工作有序、高效地进行; 优秀程序员的开发效率是普通程序员的 10 倍

如何思考

思考框架

• 要诀

  • 1、现状

    • where are we?

  • 2、目标

    • where are we going?

  • 3、实现路径

    • how can we get there?

• 需求开发思考

  • 为什么要做这个特性，他给用户带来怎样的价值
  • 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
  • 达成这个目的是否有其它手段？是不是一定要开发一个系统？
  • 这个特性上线之后，怎么衡量它的有效性？

• 原则步骤

  • 1、以终为始: 工作的一开始确定好真实目标
  • 2、任务分解: 找到实施路径
  • 3、沟通反馈: 解决与人打交道出现的问题,保证信息对称
  • 4、自动化: 解决与机器打交道出现的问题

10x工作法原则

1、已终为始

• 1、已终为始:如何让努力不白费？

  • 以结果导向思考模式

    • 遇到事情，倒着想，先想结果是什么样子; 反直觉思维

  • 想象的共同体

    • 任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）

      • 其实工作中很多问题, 是第一次创造没有做好,就进入第二次创造。第二次创造成本很高, 所以需要如第一次创造上花功夫。如图纸上构思各种细节, 做产品先做原型文档再交付, 先定义接口样子再进行开发。

  • 对做软件的人来说，我们应该把“终”定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来

• 2、完成了工作, 为什么还不满意？

  • 案例

    • 程序员小李的开发工作完成经常让项目经理老张不满意

    • 为什么?

      • 理解的鸿沟:对"终"理解存在分歧

    • 怎么办？

      • 弥合差异,“完成” 标准定义(DoD)

  • 完成的定义(DoD: definition of done): 什么叫完成?

    • DoD 是一个的思维模式，是一种尽可能消除不确定性，达成共识的方式

  • DoD怎么用

    • 1、DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况，确保你不遗漏任何事情

    • 2、DoD 的检查项应该是实际可检查的

    • 3、DoD 是团队成员间彼此汇报的一种机制

      • 当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”

  • 在做任何事之前，先定义完成的标准， 杜绝理解鸿沟

• 3、接到需求， 要先做哪些事情

  • 案例

    • 程序员小李开发完登录演示小王认为还需要增加验证码功能

    • 原因

      • 不同的需求描述方式,影响对需求的理解，信息的传递会衰减，你不可能把你理解的信息 100% 传递给另外一个人，而这中间，如何传递，也就是如何描述将直接决定衰减的比例
      • 很多软件开发基于功能列表, 列表规定程序员要做功能,程序员"照单抓药"写代码, 不理解功能背景和使用场景, 这样导致不能理解全局。
      • 这种功能列表式的需求描述方式，将一个完整的需求敲成了碎片。 只有所有功能全部开发完成，对接在一起的时候，才是“破镜重圆”的时刻。但此时会有很多意料之外的事情
      • 根据这种基于功能列表的需求描述，每个组在安排工作的时候，都会按照自己的理解进行功能排列。如果多团队协同, 可以想象由多糟糕

  • 解决

    • "用户故事"的方式描述需求

      • 站在用户的角度完全描述出使用场景

      • 故事样子

        • 标题: 故事要干什么

        • 概述: 简述这个故事主要内容

        • 详述:详细地描述这个用户故事的完整流程，包括操作流程、用户界面等信息。

        • 验收标准: 正常使用的流程是怎样的，以及各种异常流程系统是如何给出响应的，这是程序员常常会欠缺的思考。即:正常场景,异常场景

          • 验收标准非常重要的一环是异常流程的描述
          • 验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量

  • 角色转变

    • 理想状况:pm用户故事方式完全描述出业务需求, 程序员专注在业务技术实现上
    • 现状: pm不能完全描述, 环节缺失,
    • 因此需要,扮演不同角色的时候，我们的思考模式是不同的
    • 先扮演好产品经理的角色，多花点时间把验收标准制定好，再回到开发人员的角色上去写代码。毕竟，最好维护的代码是没有写出来的代码。

  • 用验收的标准看需求是否明确

• 4、从持续集成角度看开发

  • 集成本是写代码的一个环节

• 5、产品经理不靠谱, 你该怎么办?

  • 用精益创业的视角衡量产品特性的有效性

  • 办法

    • 我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数
    • 以终为始。我们是要做产品，那就需要倒着思考，这个产品会给谁用，在什么场景下怎么用呢？
    • 软件开发的主流由面向确定性问题，逐渐变成了面向不确定性问题。

  • 精益创业

    • 解决

      • 面向不确定性创造新事物
      • 让人们开始理解价值创造与浪费之间的关系

    • 总结

      • 创造价值是每个人都能理解的，但减少浪费却是很多人忽略的

      • 精益创业就是在尽可能少浪费的前提下，面向不确定性创造新事物

        • 既然是不确定的，那你唯一能做的事情就是“试”

        • “开发（build）- 测量（measure）- 认知（learn）”这样一个反馈循环

        • 当你有了一个新的想法（idea）时，就把想法开发成产品（code）投入市场，然后，收集数据（data）获取反馈，看看前面的想法是不是靠谱

          • 得到的结果无非是两种：好想法继续加强，不靠谱的想法丢掉算了。不管是哪种结果，你都会产生新的想法，再进入到下一个循环里。在这个反馈循环中，你所获得的认知是最重要的，因为它是经过验证的。在精益创业中，这也是一个很重要的概念：经过验证的认知（Validated Learning）

      • 精益创业提出一个非常重要的概念，最小可行产品，也就是许多人口中的 MVP（Minimum Viable Product）。简言之，少花钱，多办事

      • 默认所有需求都不做，直到弄清楚为什么要做这件事。

• 6、解决了很多技术问题，为什么依然在"坑"里？

  • 更大范围内寻找"终"

  • 程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。

  • 不同角色工作真正的差异在于上下文的差异。在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化，很难达到最优的效果

  • 角色的差异

    • 不同角色工作上真正的差异是上下文的不同

      • 虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考
      • 我并不是靠技术能力解决了问题，而是凭借对需求的理解把这个问题绕过去了
      • 而能想到问这样的问题，前提就是要跳出程序员角色思维，扩大自己工作的上下文
      • 当你对软件开发的全生命周期都有了认识之后，你看到的就不再是一个点了，而是一条线

    • 工作的上下文不同，看到的维度差异很大

      • 单一维度的思考，在多维度思考者的眼里几乎就是漏洞百出的

  • 扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上

• 7、为什么说做事情之前先要进行推演

  • 沙盘推演, 从军事指挥室里学来的大学问
  • 即便已经确定了自己的工作目标，我们依然要在具体动手之前，把实施步骤推演一番，完成一次头脑中的创造，也就是第一次创造或智力上的创造。这种思想在军事上称之为沙盘推演，在很多领域都有广泛地应用
  • 通向结果的路径才是更重要的
  • 在动手做一件事之前，先推演一番。

• 8、工作可以用数字衡量吗？

  • 数字化: 一种衡量"终"的方式
  • 一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据
  • 设计好测量工作有效性的指标，那么就可以更有目的性地去工作了

• 9、启动开发之前, 要准备什么?

  • 迭代0： 请在开发前准备好

  • 迭代前的清单

    • 需求方面

      • 1. 细化过的迭代1需求
      • 2. 用户界面和用户交互

    • 技术方面

      • 1. 基本技术准备

        • 基础架构选型

        • 数据库表结构设计

        • 2. 持续集成
          • 构建脚本, 代码风格检查，常见的bug模式检查，测试覆盖率
        • 3. 测试
          • 把测试当作规范确定下来的办法就是把测试覆盖率加入构建脚本

      • 2、发布准备

        • 数据库迁移

          • flyway变更版本控制工具

        • 发布脚本

• 总结

  • 行业最佳实践

    • DoD，确定好完成的定义，减少团队内部的理解不一致
    • 用户故事，细化出有价值的需求
    • 持续集成，通过尽早集成，减少改动量，降低集成的难度
    • 精益创业，减少过度开发不确定性产品带来的浪费
    • 迭代 0，在项目开始之前，做好一些基础准备

  • 思维转变

    • 任何事物都要经过两次创造

      • 一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）

    • 在更大的上下文内发现自己的“终”

    • 通过推演，找到通往“终”的路径

    • 用可度量的“数字”定义自己的“终”

  • 如何管理上级

    • 第一，管理上级的预期

      • 相当于我把自己看到的问题暴露给上级，让他选择

    • 第二，帮助上级丰富知识

    • 第三，说出你的想法

      • 会哭的孩子有奶吃

2、任务分解

• 1、任务分解：按部就班的前提

  • 软件开发的任务分解

    • 1、一个大问题，我们都很难给出答案，但回答小问题却是我们擅长的

    • 2、任务分解的粒度: 可执行

      • 不同的可执行定义差别在于，你是否能清楚地知道这个问题该如何解决

  • 大师级程序员工作的秘笈

    • 将任务拆小，越小越好

  • 将大问题拆解成能够解决的小问题

• 2、测试也是程序员的一部分

  • 开发者也需测试

    • 对于每个程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码

  • 测试驱动开发(TDD)，一种设计挑战

  • 测试的属性：A-TRIP

  • 测试种类

    • 人工测试

    • 自动化测试

      • 测试框架最大的价值，是把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来

    • 单元测试

    • 集成测试

    • 系统测试

    • 验收测试

  • 测试模型

    • 冰淇淋蛋卷模型

      • 有些情景高层的测试不容易覆盖到的，所以，还要有一些底层的测试，比如单元测试。在这种情况下，底层的测试只是作为高层测试的补充，而主力就是高层测试

      • 冰淇淋蛋卷测试模型的人并不多，它是一种费时费力的模型，要准备高层测试实在是太麻烦了， 使用较少

    • 金字塔测试模型

      • 重点就是越底层的测试应该写得越多
      • 越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广
      • 小事反馈周期短，而大事反馈周期长
      • 当测试金字塔遇到持续集成

    • 虽然冰淇淋蛋卷更符合直觉，但测试金字塔才是行业的最佳实践

  • 测试实践

    • 测试先行开发(Test First Development)

      • 先写测试后写代码

    • 测试驱动开发TDD（Test Driven Development）

      • 开发节凑

        • 红 - 绿 - 重构

          • 红，表示写了一个新的测试，测试还没有通过的状态；绿，表示写了功能代码，测试通过的状态；而重构，就是再完成基本功能之后，调整代码的过程

          • 重构与测试是相辅相成的：没有测试，你只能是提心吊胆地重构；没有重构，代码的混乱程度是逐步增加的，测试也会变得越来越不好写

            • 因为重构和测试的互相配合，它会驱动着你把代码写得越来越好。这是对“驱动”一词最粗浅的理解

    • 测试驱动设计

      • 编写可测试的代码
      • 我的代码怎么写才是能测试的，也就是说，我们要编写具有可测试性的代码

    • 瀑布开发方法

• 3、需求的拆分:用户故事

  • 问题

    • 基本上，闯入你脑海的需求描述是主题（epic），在敏捷开发中，有人称之为主用户故事（master story)
    • 绝大多数问题都是由于分解的粒度太大造成的，少有因为粒度太小而出问题的
    • 用户故事，它将是我们这里讨论需求管理的基本单位

  • 需求要分解

    • 用户故事原则

      • 1、Independent，独立的
      • 2、Negotiable，可协商的
      • 3、Valuable，有价值的
      • 4、Estimatable，可估算的
      • 5、Small，小
      • 6、Testable，可测试的

  • 需求的估算

    • 估算的结果是相对的，不是绝对精确的，我们不必像做科研一样，只要给出一个相对估算就好
    • 一般来说，估算的过程也是大家加深对需求理解的过程

• 4、优先级管理：做最重要的事情

  • 需求分解之后，最重要的是，排列需求的优先级。优先级的排列方式有很多，我们可以借鉴时间管理的方法，把事情按照重要和紧急的维度进行划分，得到了四个象限。我们要尽可能把精力放在重要的事情上，而不是把紧急的事情当成优先级排序的方式

  • 确定事情的重要程度, 一种方式就是找回丢失的上下文，如果无法判断好的办法, 那就引入外部更大的上下文

• 5、最小可行产品:找到一条可行路径

  • 产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。最小可行产品就是“刚刚好”满足客户需求的产品

    • 最小

      • 想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。最小的代价就是能不做的事就不做，能简化的事情就简化

      • 我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。

      • 例子

        • 做产品文档验证方向性想法正确性
        • 原型工具做出了相对完整的用户界面, 验证使用性
        • 经过多轮测试下来，团队有了一大堆的用户反馈，而且是来自真实用户的反馈。接下来，就是整理这些用户反馈，决定哪些可以真正的开发出来，这时候，团队才真正进入到开发阶段
        • 迄今为止，这个团队验证了一大堆的想法，而代码却是一行都没有写，所有花费的工作量都是有针对性的验证

    • 可行

      • 但从产品可行的角度，我们需要转换一下思路，不是一个模块做得有多完整，而一条用户路径是否通畅
      • 当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡

  • 程序员经常愿意用自己的代码解决问题，而写代码通常是代价非常高的解决方案，它应该成为最后的产品解决方案

  • 可行的路径，是一条完整的用户体验路径，至少在用户眼中是这样的。我们常常会想给客户一个完整的系统，但在时间有限的情况下，我们必须学会分解

    • 但从产品可行的角度，我们需要转换一下思路，不是一个模块做得有多完整，而一条用户路径是否通畅

  • 做好产品开发，最可行的方式是采用 MVP(Minimum Viable Product，MVP)

  • 总结: 小步快跑。搞清楚业务方需要什么, 最小代价(产品文档+原型工具)验证, 找到可行性路径, 进行开发

3、沟通反馈

• 1、信息论的视角看沟通反馈

  • 人生不如意，十之八九！

  • 我们努力地学习各种知识，为的就是更好地理解这个世界的运作方式，而沟通反馈，就是我们与真实世界互动的最好方式

  • 信息论视角的解释

    • 因为每个人经历见识的差异，造成了各自编解码器的差异，形成了理解的偏差

  • 改善编解码

    • 分别是：编码器，让信息能输出更准确；解码器，减少信号过滤，改善解码能力；还有编解码算法，也就是各种来自行业的“最佳实践”，协调沟通的双方

• 2、用业务的语言写代码

  • 推荐书籍

    • 《程序设计实践》（The Practice of Programming）

  • 编写可维护的代码境界

  • 计算机科学中只有两大难题：缓存失效和命名

    • 命名难题

      • 名字起得是否够好，一个简单的评判标准是，拿着代码给人讲，你需要额外解释多少东西

      • 代码到底是给谁写的？

        • 任何人都能写出计算机能够理解的代码，只有好程序员才能写出人能够理解的代码。
        • 我们写代码的目的是与人沟通，因为我们要在一个团队里与人协同工作
        • 人要负责将业务问题和机器执行连接起来，缺少了业务背景是不可能写出好代码的。
        • 好的命名修改，但从理解上，这是一步巨大的跨越，缩短了其他人理解这段代码所需填补的鸿沟，工作效率自然会得到提高

      • 命名，是写程序中最基础，也是一个程序员从业余走向专业的门槛。我以命名为基础，给你解释了写好代码的提升路径。最初的层次是编写可以运行的代码，然后是编写符合代码规范的代码

  • 用业务语言编写代码

    • 了解领域驱动设计（Domain Driven Design，DDD），你可能已经分辨出来了，我在这里说的实际上就是领域驱动设计。把不同的概念分解出来，这其实是限界上下文（Bounded Context）的作用，而在代码里尽可能使用业务语言，这是通用语言（Ubiquitous Language）的作用

    • 推荐书籍

      • 代码整洁之道

• 3、团队的沟通：轻量级沟通

  • 头疼的开会

    • 程序员白天都在开会, 晚上才能静心写代码

    • 开会是为了解决问题，但真实情况却是开了会又没有解决多少问题，这真是一个奇特的矛盾。

    • 凡是效果特别好的会议，基本上都是用来做信息同步的。

      • 例如: 领导宣布一个事情，大家收到消息， 结束。

    • 会议是一项重量级的沟通

  • 轻量级沟通

    • 改善会议的第一个行动项是，减少参与讨论的人数。

    • 第二个行动项是，如果你要讨论，找人面对面沟通

    • 如果和大家沟通结果达成一致, 再进行开会

      • 开会的目的不再是讨论，而是信息同步：我准备这么干了，相关各方已经同意了，知会大家一下，结束。

  • 站立会议

    • 实践叫站会（Standup）

    • 站会人主题

      • 1、我昨天做了什么。

        • 是为了与其他人同步进展，看事情是否在计划上。一旦偏离计划，请主动把它提出，这样，项目经理可以过问，因为这会涉及到是否要调整项目计划

      • 2、我今天打算做什么。

        • 是同步你接下来的工作安排。如果涉及到与其他人协作，也就是告诉大家，让他们有个配合的心理准备

      • 3、问题和求助

        • 我在过程中遇到什么问题, 需要请求帮助。
        • 就是与其他人的协作，表示：我遇到不懂的问题，你们有信息的话，可以给我提供一下

    • 注意事项

      • 控制时长(不超过10分钟)

      • 晨会规模

        • 5-12人是一个恰当的规模

      • 避免做成汇报会

      • 问题复杂,会后讨论,不要在会上讨论

      • 保持参与人集中精力

        • 毛绒娃娃随机令牌发言

  • 一些思索

    • 每次会议要有会邀, 讨论主题, 相关文档, 会后同步会议记录结论
    • 同步沟通(如:开会)，人越少越好。异步沟通的时候，涉及的听众越多越好(如:E-mail)

• 4、可视化：一种更为直观的沟通方式

  • 关注技术新知识途径

    • InfoQ

    • ThoughtWorks 技术雷达

      • 技术雷达就是一种将技术信息组织起来的方式。它通过将技术按照“象限”和“圆环”两个维度进行分类，让人可以直观地看到并理解不同的技术所处的发展阶段

  • 可视化

    • 在我看来，雷达图不仅仅适用于组织，也可以适用于团队

      • 雷达图是一种很好的形式，不仅可以用在组织技术，还可以用来组织其它信息，比如，读书雷达。每个公司都可以利用雷达图的形式组织自己所有的技术，每个团队也可以利用雷达图的形式组织自己团队用到的技术，这样，方便团队成员结构化地理解用到技术，也方便新人的学习。

    • 可视化的优势

      • 因为人的大脑更擅长处理图像
      • 处理图像的速度远远快于处理文字

    • 项目管理

      • 看板

• 5、持续集成的关键点: 快速反馈

  • 目标: 怎样快速地得到反馈，以及什么样的反馈是有效的。

  • 做好快速反馈，要把本地能做好的事情，在本地做好；也要通过小步提交的方式，加快代码开发的节奏。什么是有效的反馈？一是即时的反馈，二是引人注目的反馈。有很多种持续集成相关的工具可以帮助我们达成有效的反馈

  • 想要做好持续集成，还要有一些纪律要遵循

    • 只有 CI 服务器处于绿色的状态才能提交代码
    • CI 服务器一旦检查出错，要立即修复

• 6、回顾会议：复盘与改善

  • 安全性检查，是回顾会议的前提条件

  • 在软件研发中，许多问题是反复出现的，很多开发团队会因此陷入无限“救火”中，解决这种问题一个好的办法就是复盘

    • 把过程还原，进行研讨与分析的方式，就是复盘

  • 复盘，就是过程还原，进行研讨与分析，找到自我改进方法的一个方式。这种方式使我们拥有了客体化的视角，能够更客观地看待曾经发生过的一切。这种方法在很多领域中都得到了广泛的应用，比如股市和企业管理

    • 用别人的视角看问题，这就是客体化

  • 复盘实践

    • 回顾会议

      • 定期回顾是一个团队自我改善的前提
      • 做得好的、做得欠佳的、问题或建议
      • 目的: 改善和提升

  • 无论哪种做法，分析问题，找到根因是一个重要的环节。“5 个为什么”就是一个常用的找到根因的方式

  • 定期复盘，找准问题根因，不断改善

  • 枚举关注点，选出重点，深入讨论，列出行动项，找到负责人

• 7、用户思维，聆听赖在用户的声音

  • 用户视角，你需要来自真实世界的反馈

    • 而作为一个程序员，欠缺用户视角，在与产品经理的交流中，你是不可能有机会的，因为他很容易用一句话就把你打败：“这就是用户需求。”
    • 由听产品经理的话，扩大成倾听用户的声音

  • 倾听用户声音。这是开发团队普遍欠缺的一种能力，更准确地说，是忽略的一种能力。所以，“吃自家的狗粮”这种听上去本来是理所当然的事情，才被反复强调，成为 IT 行业的经典

  • 无论是自己做用户，还是找机会接触已有用户，亦或是没有用户创造用户。只有多多听取来自真实用户的声音，我们才不致于盲目自信或是偏颇地相信产品经理。谁离用户近，谁就有发言权，无论你的角色是什么。

• 8、把事情做在前面：变被动为主动

  • 遇到问题，最好的解决方案是尽早把问题暴露出来

• 9、写文档、做分享， 也是一种学习方式

  • 为什么不喜欢写文档

    • 很多人回避写文档的真正原因是，他掌握的内容不能很好地结构化

  • 将零散的知识结构化，有很多种方式，但输出是非常关键的一环。

  • 输出的过程，本质上就是把知识连接起来的过程

  • 输出过程

4、自动化

• 1、"懒惰"应该是所有程序员的骄傲

  • 不要自动化

    • 哪些东西不要自动化
    • 做有价值的事是重要的，这里面的有价值，不仅仅是“做”了什么，通过“不做”节省时间和成本也是有价值的
    • 说明一件事，写代码之前，先问问自己真的要做吗？能不做就不做，直到你有了足够的理由去做

  • 要自动化

    • 在为别人打造自动化工具的同时，我们自己的工作过程有没有很好地自动化
    • 而如果我们想拥有打造良好的自动化工具，我们需要对软件设计有着充分地理解

  • 软件设计

    • 在软件开发中，其它的东西都是易变的，唯有设计的可变性是你可以控制的

      • 看源码，学习的目的是看背后的软件设计思想，而非软件本身

    • 不要混淆了设计和实现

• 2、构建脚本: 让日常开发变得简单

  • 项目自动化流程

    • 生成IDE工程
    • 编译
    • 打包
    • 运行测试
    • 代码风格检查
    • 测试覆盖率
    • 数据库迁移
    • 运行应用

• 3、思考DevOps框架

• 4、持续交付: 一种延伸的"持续集成"

• 5、如何做好验收测试？

• 6、单一职责:划分界限

  • 逐步腐化的代码

    • 功能堆加

    • 低着头完成了一项任务，而代码却变得更糟糕

    • 一个解决办法

      • 重构

  • 软件设计

    • SOLID

      • 单一职责原则（Single responsibility principle，SRP）
        开放封闭原则（Open–closed principle，OCP）
        Liskov 替换原则（Liskov substitution principle，LSP）
        接口隔离原则（Interface segregation principle，ISP）
        依赖倒置原则（Dependency inversion principle，DIP）

• 7、分成思维, 是计算机的核心思维

• 8、不同量级的东西不是一回事

  • 评估系统当前所处的阶段，采用恰当的技术解决，是我们最应该考虑的问题
  • 作为拥有技术能力的程序员，我们都非常在意个人技术能力的提升，但却对在什么样情形下，什么样的技术更加适用考虑得不够。采用恰当的技术，解决当前的问题，是每个程序员都应该仔细考虑的问题
  • 用简单技术解决问题，直到问题变复杂

• 9、领域驱动设计:限定上下文

综合运用

1、入职新公司, 如何快速进入工作状态？

• 步骤

  • 1、了解业务

  • 2、技术

    • 技术栈
    • 业务架构
    • 内外依赖

  • 3、团队运作

    • 需求, 产品，向谁汇报

    • 内部活动

      • 站会、 回顾会议、周会、代码评审、内部分享等

  • 使用“行话”。在交流的过程中，学习一点”行话“。这会让人觉得你懂行，让你很快得到信任，尽早融入团队

• 找到关键点，迅速下手

• 由大到小， 由内而外

2、面对遗留系统，如何做？

• 用思考框架对遗留系统

• 步骤

  • 1、了解现象和根因

  • 2、确定方案

    • 确定目标
    • 先尝试重构你的代码，尽可能在已有代码上做小步调整，不要走到大规模改造的路上，因为重构的成本是最低的
    • 保证功能一致唯一靠谱的答案是测试
    • 一方面，建立好领域模型，另一方面，寻找行业对于系统构建的最新理解

• 建议

  • 构建测试防护网，保证新老模块功能一致；
    分成小块，逐步替换；
    构建好领域模型；
    寻找行业中关于系统构建的最新理解。

3、如何保证竞争力

• 不断提升自己的核心竞争力
• 焦虑， 对未来不确定性
• 目标: T型人才， 一专多能 有深度有广度
• 有了“一专”，“多能”才是有意义的，否则，就是低水平重复，而这正是很多人职业生涯不见起色的真正原因

总结

少做事,才能更有效的工作

附: 提供md、png、xmind格式笔记地址:
资源地址