# 任务 1：Tasking 任务分解

## Tasking 的方法论

接下来我们会系统地讲解 Tasking 的方法论。

### Tasking - 任务描述

![](https://2897586075-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LquCgGNObzQ8HY5Og1P%2F-LqvN8fjJNwcmDOlf1kK%2F-LqvN9WYt51shJPorFtg%2Ftasking-1.png?generation=1570806765735124\&alt=media)

完成任务没有思路首先是因为我们对问题描述得不够清晰。很多人在思考问题的时候是用蛮力的，想不出来就使劲想，憋着不干别的，等着大脑里蹦出一个答案。这种做法是非常不可取的，尽管我们大脑的潜意识具有仅次于阿尔法 Go 的思考力，你也不能这么虐待它，好钢要用在刀刃上。 正如上图所示，很多人思考任务也就是一句话的任务描述，而一句话根本是不够清晰的，我们需要一些思维框架让问题更加清晰。

#### 清晰的思维是第一步，不能看到就不能思考

### 抽象：输入 & 输出

![](https://2897586075-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LquCgGNObzQ8HY5Og1P%2F-LqvN8fjJNwcmDOlf1kK%2F-LqvN9W_tkHGvezwFTnk%2Ftasking-2.png?generation=1570806765664136\&alt=media)

计算机程序可以简单的抽象为输入，处理和输出。所谓的处理，是处理过程的简称，也就是代码，它既可以是左边的结构化的代码块，也可以是右边封装好的函数。无论哪一种，都有输入输出。 这个思维框架就是很好的思维框架，既然程序是要考虑输入和输出的，而我们的任务就是写程序，那么自然也要考虑输入输出

### 使用 输入/输出 描述 Task

![](https://2897586075-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LquCgGNObzQ8HY5Og1P%2F-LqvN8fjJNwcmDOlf1kK%2F-LqvN9WbrLb2V58w5Fvc%2Ftasking-3.png?generation=1570806765955669\&alt=media)

回到之前的图，把输入输出加上，就变成了上面这个样子。 每个输入输出都有名字和数据结构。 就输入来说，如果是代码块，那么就是另一块代码创建某个变量，如果是函数，那可能就是参数。 就输出来说，如果是代码块，那么就是创建出来给别的代码块使用的变量，如果是函数，那可能就是返回值。 而不管哪一个，都是有名字和数据结构的。 往往输入的数据结构可以从前面的输出中找到，所以可以省略掉就不想了。

如果是面向对象的话，输出的 name 就不太重要了，重点是数据结构的类名。

### 一个典型的示例

请看如下示例，我们有 3 个函数，这也是描述我们任务的一种方式。

```bash
#1 函数a
输入：
    paramX: TypeX
输出：
    aValue: TypeA

#2 函数b
输入：
    paramY: TypeY
输出：
    bValue: TypeB

#3 函数c
输入：
    paramZ: TypeZ
输出：
    cValue: TypeC
```

![](https://2897586075-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LquCgGNObzQ8HY5Og1P%2F-LqvN8fjJNwcmDOlf1kK%2F-LqvN9Wdhy2932zTEEE_%2Ffunction.png?generation=1570806766684513\&alt=media)

唯一需要强调的就是穷尽了，我们思考问题的时候，需要把输入输出穷尽。在实际工作中需要和业务和产品尽可能地沟通了解清楚。 如果不把输入输出穷尽，和  森林里谁没有参加会议的问题一样，我们是无法想清楚问题的。

## 练习一

#### 使用任务的方法论分解来描述制作西红柿炒鸡蛋

* 拿一张白纸
* 进行粗粒度的任务拆分
* 对其中复杂一些的步骤进行进一步分解
* 检查和梳理所有任务的输入输出，确保穷举
* 检查所有任务，确保输入输出明确的情况下，任务独立

#### 使用任务的方法论分解来描述伊隆·马斯克的远大计划

* 对火星移民计划进行上述操作