Whosbug开源规划

whosbug经手了多个团队的近20人，历史团队中：大家分别负责插件和数据流转的设计实现和优化、责任归属算法的设计实现与优化、antlr语法AST分析的多语言适配实现以及项目协同的管理；当前主要由kevineluo和kevinmatthe负责维护以及开源相关的规划，同时也有这个开源小组的其它几位同学一起协作共建whosbug的开源版本

规划

短期内优先支持完成whosbug内网版本的落地，同步进行一些架构上的调整，对齐开源标准等；长期来看则是对whosbug的其它落地场景的探索、Keyman算法的进一步优化等

定期会议

根据收集到的问卷统计，暂定每周五的17:00-17:30，视情况调整

时间投入

根据收集到的问卷统计来看，大部分同学除了周末都没有太多时间，这里我们初步设定每人每周发放约8小时的工作

需要解决的技术问题

1. python等语言解析的支持

   Antlr-Golang语法解析框架目前部分缺失解析python文件的处理库，无法进行语法解析

2. 多种语言都存在的库文件(如*.h文件)、混合编译的源码的解析标准

3. 部分语言中存在类似import xx as yy的情况，需要额外分析import语句才能得到有效的调用链

4. 同一项目下有多个可执行子项目

   一个仓库中有多个子项目，不同目录下存在同名的方法：如目录src/main和test/main下均有方法/类MainActivity，存在该方法调用的函数calling中无法准确定位调用来源，且会存在无法唯一标识的现象

5. 部分语言(如c++)不能保证方法调用准确解析

   导致语法树不完整，Keyman算法无法得到较为可信的结果

6. 调用链关系存储方式效率低下

   目前仍采用传统的DBMS数据库进行存储，更新操作较为繁琐，效率低下

7. 系统测试

   由于测试数据的收集难度较高，whosbug一直缺少一些系统测试；一个得不到验证的系统是没有说服力的

   whosbug在内网这边正在进行完整的更新和发布，这里或许可以在一些项目上得到验证，收取到一些认可度；但同时我们也可以主动的设计一些测试方案来“自圆其说”一下

需要解决的架构问题

1. config从模块解耦

2. 拆分whosbug-ASTtracker(名称暂定)解析模块作为go module开源发布（未来可作为其他用途复用）

3. whosbug-webservice接口标准化重构(目前和RESTFUL的标准还有距离)

4. Whosbug-webservice没有为多个请求适配，同时只能处理一个请求

功能 / 算法预研

1. 后台的解密client

   用于观察数据库内的加密数据，（要做好鉴权，不然加密全部木大）

2. Grafana Dashboard

   用于宏观数据的观察（各接口请求量，耗时等）、告警配置以及SRE标准化的建设(监控插件接入数量、对流水线机器的性能消耗等)

3. Keyman算法优化

   目前的算法在先验 / 后验概率维度上有改进的空间，可以与rebucket算法 / TraceSim算法联动

   超参数训练模块还有待开发（可以参考kevineluo写的rebucket超参数训练模块进行改进 / 使用灵活性较高的开源框架）

关于neo4j图数据库的调研

存在的问题

1. 使用的查询语言Cypher不进行强类型约束

2. 除类似主键的唯一性约束外，其他的唯一性约束(如复合主键、同类字段存在性约束、字段非空约束)均只对企业版提供支持

3. 不能通过创建多标签的节点来建立关系

   创建一个新的commit节点时，不能通过[new_commit:Commit:Release:Project]来继承关系，只能手动创建与Release的关系

4. 关系的单位为节点，不能对标签标识的一类节点直接建立关系，每次插入一条子表节点时都要附带创建关系

   例如：已创建节点Project、Release和关系Project-[:CONTAINS]->Release，每次有新的Release插入都需要一同创建一个关系。

可能的方案

• 参考AOF+RDB增量存储语法树

• AST与webservice接口需要区分方法的变动和移除

• 假设：单行变动且不在任意一个方法内

• 保底存储方案：对每个Release维护一个语法树