3-4 月份我们干了些什么？

本文作者：Klesh Wong

GitHub 地址：https://github.com/klesh

引述

自去年7月份 DevLake kicked off 以来，项目一直处于被各种 demo / event 追赶的状态，为此，我们放弃了很多，比如代码风格，单元测试，代码注释，文档的维护，issue的维护，用户的友好性等。

当然，也不是说完全一点没有，只是在大面上，项目总体呈一种野蛮生长的状态。大家对项目的期望也一直是能“跑起来就行”，“主流程正常就OK”，至于一些稳定性，对异常情况的忍耐度，嗯，大抵只用重启大法解决。

这说明了，项目整体代码质量存在着基础不稳的情况，需要夯实，架构上也需要演进，帮助插件最大程度地解决一些共性的问题。

没有一种架构，或者具体到设计，是万能的，可以解决一切的问题。不基于实际情况，凭空去猜想，再做出设计，其结果容易过度优化，甚至更糟。比如，由于现实与理想差距过大，导致整个设计要推倒重来。从这个角度来看，野蛮生长也并不完全是一件坏事，早期我们有很多要怎么怎么做，处理哪些哪些场景的讨论，怎么满足用户画像一的前提下，同时兼顾画像二的情景等等。

要考虑的情况太多了，要不要队列？要不要多级队列？任务编排怎么做？要不要做DAG？结果是谁也说服不了谁，因为A提出的方案，随即就会有B提出一种或多种情况是该方案无法解决的，而大家又不能确定A方案要解决的问题到底有多严重，或者B提出的情况会不会出现？

幸运的是，我们最后放弃了各种高大上的架构，选择在框架级只做了一个简单的任务执行逻辑，把具体的处理逻辑都交由插件自行解决，自由发挥。

经过半年多的发展，我们慢慢地发现了一些共通的模式，最终在 3-4 月份实现大爆发。

我们发现了什么？

1.数据流的模式

所有的数据源插件，都需要从 api 读取数据 (collection)，然后提取(extraction)，再转换(conversion)到统一的实体层(Domain Layer Data，比如 jira 的 issue 和 github 的 issue 得统一到 issue 这张表里面)，在此之前可能还会有一些维护转换的任务要做，比如基于 jira issue changelog 的信息，归结出 i