我们来看这么一个安装app的操作过程：
如果我们将这个操作流程记录下来的话，大致就可以得到这么一幅图：
也就是说，当我们去商店下载安装一个app的时候，它是需要经过这么的一个过程，而编程就是在一步步地实现这么一个过程。产品经理也好，程序员也好，都是在对一个功能或是一个操作流程进行分析然后拆分，再一步步地去实现，最后串联起来去实现出这个功能或是这个流程。
我觉得这应该是逆推法，先知道我们要实现的效果，再反推回去需要什么样的步骤。
这里面有两个主要的流程，一个是下载，一个是安装。我们可以看到，要想“下载结束”，得有个“下载中”的过程，而要有个“下载中”的过程，就需要有个“开始下载”的起点，只有这几个串联起来，才是一个完整的”下载“功能（我们忽略下载失败等意外情况）；安装也是同样的道理。那么我们就可以看到这里面是有个相互依赖的东西。
接下来我们把下载和安装放在一起来看，其实它们是互不干扰的，安装只需要知道下载的结果而已，如果成功就安装，不成功就不安装，它不需要去知道究竟下载这个功能里是怎么操作的，它只关心结果，那么这里我们就看到了一个相互独立的东西。
因此我们把上图做进一步的抽象：
在生活中的生产也是一个这样的道理，福特公司发明了流水线后，把汽车的组装过程进行拆分，在生产车间里每个人都只做自己的那个步骤，车间与车间之间也只关注结果，不需要去知道上一个车间的操作过程，这样让效率有了提升，也降低了干扰。
解耦
那么这里有一个词，叫“解耦”。
“耦”这个字在百度百科上的解释有双数，成对的意思，同“偶”。
“耦合”在物理学上指两个或两个以上的体系或两种运动形式之间通过各种相互作用而彼此影响以至联合起来的现象。
所以“解耦”就是分开这两种东西，降低它们之间互相的作用。
这个词在编程里常常会提到的，主要是让一些功能独立开来，之间不要产生过多的黏性，不然就会导致改动起来麻烦，也就是所谓的“牵一发而动全身”。
所以解耦是一个好的软件架构里的一个标准，在开发的过程中要有这种思想或意识，把各个功能模块都独立开来，需要的话在一个个地放进去，之间通过一些接口进行联系即可。
我们只差一个程序员了
现在我们把两幅图放在一起来看：
可以看出右图抽象后的流程应该是更为容易被大众所接受和理解的。但由于专业和工作性质的问题，程序员是倾向于看到左边的更为细致的流程图，因为知道了一个更加具体的细节（当然实际开发过程中需要知道的细节不止这样，可能还需要更多的一些技术细节等，这里只是一个参考）。
所以这里就引出了一个沟通的问题，像类似的“我们只差一个程序员了”，“做个支付的功能”，“像Google那样的搜索”这样的说法，往往就会带来误会。因为参考上面两图的对比我们可以看出，右图是被屏蔽了众多细节后呈现给大众看到后的结果，而为了实现这个效果是需要前面的分析，设计，开发等一系列的流程才能得到的。
