我们已经在Trampoline:一种消除StackOverflow的技术中介绍了Trampoline技术，在写的过程中我就觉得它和我们生活中的做事方法很类似，在这篇博客中我就试着把我的一些思考分享出来。

这里我们可以把工作划分成两类

• 简单工作

  有很多种方法可以定义一个工作是否简单，这里我们用一天中的连续工作时间来衡量。简单工作是指你能在一段不受干扰的连续时间内完成的工作。如果你每天都可以找到1个小时不受干扰的工作，那么在1个小时内完成的工作对你来说就是简单工作。如果你只能找到15分钟不受干扰的工作，那么15分钟内完成的事对你才是简单工作。在程序中就是这个函数不用调用任何其他函数就可以完成它的逻辑。

• 复杂工作

  不是简单工作的工作都是复杂工作，因为我们需要把他们分配到不同的时间段去完成，也就是这项工作依赖很多其他工作的完成。在程序中就是这个函数需要调用很多其他函数才能完成它的逻辑。当然组成复杂工作的工作也可以是另一个复杂工作，就像当前函数调用的函数也可以调用其他函数。最终所有的复杂工作都由简单工作组成。

简单工作对于我们来说可以不受打扰的一口气做完，我们就不再赘述。和Trampoline一样，我们将主要关注复杂工作，对复杂工作不同的处理方法也就产生了不同的做事方法。

最简单直接的做事方法就是碰到了什么就立马做什么，做完了再想这个工作下面要做什么事情，当然也可能已经忘记原来的工作是什么了。

短期来说，人们只能在同一时间记住7件左右的事情，小孩子能记住的会更少。比如我让我的孩子去拿笤帚，中间他看到了一个垃圾，就把垃圾放扔到垃圾桶里，然后又在垃圾桶旁边发现一个彩色石头，就玩了一会石头，最后跑到我跟前说他的猪被被在哪里，我问他刚才让你干什么去了？他说不知道。这里人的短时记忆能力就像是虚拟机中的栈，当我们试图记住太多东西时，大脑虽然不会宕机，但也会让我们忘记最初想要做的事情。

长期来说，根据遗忘曲线，一个月后79%的事情就会被忘掉。如果我们在碰到一个复杂工作的子工作时只是试图在脑子里记住做完子工作后继续这个复杂工作，一个月后8成我们已经想不起来原来要做什么了。这里人的长期记忆能力就是虚拟机中的栈，如果我们在不采取任何手段的情况下试图长时间记住某件事情，大概率是记不住的。

这里想起一句俗话好记性不如烂笔头，Trampoline就是对这句话最好的诠释。如果把Trampoline映射到生活中，这种做事的方法就是先计划，再执行，必记录。先计划是指对目标工作进行计划，计划的产出就是一系列复杂工作的内容，完成标准以及他们之间的执行顺序。计划可以发生很多次，直到产出的是一系列简单工作时，再开始执行。不管是计划还是执行，当完成时我们必须进行记录，记录的内容是当前计划的状态，这样才能不依赖于大脑记忆，只专注于当前工作，这也是Trampoline的重点。

上面提到的复杂工作内容，完成标准，执行顺序正好对应了Trampoline中的三种类

• Done 代表的是工作完成，它也包括了工作完成后需要输出的材料，例如代码，文档等。

• More 代表的是对复杂工作的计划或简单工作的执行，它的输出可以是对当前工作的计划（FlatMap），或者是再做一次计划（More），当然也可以是工作完成（Done），输出工作完成时说明More代表的就是一项简单工作。

• FlatMap 代表的是工作之间的执行顺序和衔接方式。

下面我们看看这个模型是如何匹配到我们的日常开发工作中的

就拿日常做卡来说吧，卡片就代表着一项复杂工作，也就是一个More，我们需要先找BA进行kick off进行简单的分析，然后根据当前架构给出做这张卡的计划，也就是一个FlatMap，整个计划可能是下面的结构

• kick off

• 内容分析，进行tasking

  • stub数据库，实现xxRepository，进行数据存取

  • stub xxRepository，实现xxService，进行逻辑实现

  • stub xxService, 实现xxControler，实现请求的接收处理

  • 功能测试

这个计划中每项工作都是简单工作，最后的功能测试预示着功能完成，也就是满足了AC的要求，在模型中是Done。

这里最重要的是要把生成的计划记录下来，每完成一项工作就标记状态和对应的代码(commit)，这样即便我们中途休息或第二天实现都可以轻易的继续工作。这里的计划和工作输出是由代码管理工具和卡片管理工具共同完成的。

让我们回到更高层面，当这张卡完成后，我们会拖到待测试，一个版本会被生成，QA可以根据卡的状态对相关版本进行测试，测试完成后就将卡片拖到待部署，然后根据产品计划进行部署上线。这里又涉及到了两种计划，产品计划和迭代计划，由产品管理工具，卡片管理工具以及包管理工具共同完成。

从上面可以看到，我们大部分时间就是在做计划，依次为产品计划，Epic拆分，任务拆分，迭代计划，卡片Tasking，最后进行每个简单工作的开发。

当然我们开发工作中会遇到各种异常情况，例如产品变更，需求变更，人员变更等。在Trampoline模型中，我们会对每一步进行记录，那么我们就可以在执行每一步时对后续工作进行审查变更。但我们无法对已完成的工作进行变更，只能用新的工作来纠正。这也是我们在日常工作中会有迭代，showcase， desk check这些活动的原因，他们其实都是对后续计划的审查变更。

以上，说的比较乱，思考还不深入，希望不管是从日常生活理解Trampoline还是从Trampoline理解日常生活，这篇文章都能对你有所帮助。