流程程序设计

onPostProcess生命周期

doSomeThingB

if xxx

doSomeThingC

onPreProcess生命周期

开始

关于刚开始说的Context，用过koa2的同学都知道有多好，设计都是相通的

yes

 Context类模板

onPreAllProcess生命周期

en。。。。感觉没必要？的确简单的流程中有没有都无所谓，但是如果考虑后续的维护性，或者整个流程整体比较复杂还是加一下生命周期比较好把流程循环起来看看

onPostProcess(ctx: Context)

onPreAllProcess(ctx: Context)

doSomeThingE

有生命周期

en。。。。觉得还好？，其实也还好，代码不多的时候还是挺清晰的，但我有点强迫症，就想给它加一个生命周期

doSomeThingA

最近在做一个插件，一个关于游戏资源发布相关的插件，这个插件就是对资源的一系列处理最终输出到游戏工程目录中，接手的时候的版本主要是按面向过程设计的，之前一直觉得面向过程挺适合这种流程处理的，后来随着深入看代码发现就算是流程面向过程的写法虽然很易懂，但是会存在一定的问题，就是参数传递，前期定好了参数，后面新需求进来了要不断地修改参数，我觉得这种设计是很麻烦的，很反人类的。刚好这时想起了koa2的Context对象，这个对象始终贯穿整个流程，极大程度减少了方法参数的改动，增加了代码的维护性。所以我重写的流程插件借了这种设计思维为插件写了一个Context来记录整个流程常用的数据 。其实重写并不是因为维护性问题，维护性问题只是一个附加，主要是流程中使用了两套环境，一个是pureTs一个是nodejs，插件中大量使用了nodejs的child_process导致性能很差（一个child_process在我的办公电脑上启动需要两秒左右），所以两套环境的时候尽量不要使用child_process（就算是守护进程也需要谨慎，2s时间不算短了），最终的解决方案是统一了环境，都使用purets来编写。最后我觉得最重要的，设计这种流程插件的时候设计流程的生命周期十分必要，为什么这样说？（没有生命周期的插件不是好插件，哈哈哈。。。。）没有生命周期其实也没什么的，只能说代码能跑起来，流程能跑通，就是后面维护的人需要一个一个地看你的代码，有了生命周期的代码一目了然。有生命周期的插件可以在生命周期中添加功能逻辑，没有生命周期的插件只用使用if else来添加功能逻辑，无论在可读性和可维护性上都是有生命周期的插件更胜一筹。不明白？举个例子吧

onPostAllProcess(ctx: Context)

没有生命周期

doSomeThingD

onProcess(ctx: Context)

结束

onProcess生命周期

onPreProcess(ctx: Context)

有生命周期并循环