Whosbug项目日志1

前言

从八月份的企业实训到现在，关于whosbug断断续续也开发了一个多月了（实际开发时间），

在正式上线前小小总结一下吧

开发初期

过程

刚从腾讯那里拿到这个需求（或者说idea吧）的时候，还觉得挺简单的，基于Git不就可以很快找到是谁的问题了嘛但仔细想了想，这个需求是需要从项目报错的日志出发，最终找到责任人，这就涉及源码结构了（或者说语法分析、源码分析），还是…比较复杂的

作为开发小组组长，当时决定先花半周到一周的时间确定下来项目架构以及数据库设计等（作为软件工程专业学生，还是要明白需求分析以及系统设计的重要性的）

几天过后确定了初步的架构：

架构图

并完成了数据库的设计（这里就不po出来了）

分工后就开始正式的开发流程了，使用的协作平台是coding，每天联调任务的感觉还是挺新奇的（毕竟之前基本上都是单人开发或者双人开发，而且基本都不用任务协同）

难点

项目初期的架构设计还是有一定难度的，尤其是对基于git以及源码的分析结果的数据结构设计等

个人对docker、CICD以及Django不是很熟悉（docker只有一点点了解，Django之前没有用过，只用过flask），导致在win下使用ctags容器分析源码时连续踩坑，卡了比较久的时间

开发中期

过程

经过大约一周的马不停蹄的开发，项目各个模块在解决一系列问题后，基本上完成了各自的功能实现

源码分析模块能够输出分析结果的json文件，webservice完成本地部署，CI流水线方面也有了初步的设计

随后又花了一周时间在单元测试以及集成测试上，最后的部署方案是在腾讯云的k8s集群上部署，初次接触k8s自然是比较懵逼的，光速学了一天之后直接上手部署，调试两天配置文件后总算是部署完成了

最后准备了两天ppt，完成了实训答辩（2020.8.14）

DONE

难点

语法分析

语法分析方面，通过建立源码文件后缀与对应语言的映射关系，能基本完成大部分主流语言的语法分析，但ctags对部分语言的支持性不够好，当时采用的解决方案是支持性不好的语言通过正则表达式进行支持，如swift, kotlin等；ctags支持的正则表达式居然需要使用POSIX字符集，之前没有接触过，写起来还是比较不习惯的

功能缺陷

针对git更新中只更改方法名的特殊情况，我们讨论后得出了以下解决方案：每次diff分析前进行函数更名的检测，并维护新旧对象名的映射关系

针对内部类的情况，我们讨论后得出了以下解决方案：在找到变更函数后，基于ctags的分析结果，通过递归搜索找寻方法的外层类，同时在对象的存储数据结构上，借鉴链表的思想，在变更方法属性增加parent_name一项，记录完整的语法结构（这部分信息也为数据分析提供了更多的信息，以定位更准确的责任人）

项目部署

初学k8s，对k8s的各种概念不熟悉，写配置文件的时候比较懵，经常被很低级的错误卡住，不过最后还是一一解决了，新技能get

开发后期

过程

再次接触whosbug这个项目已经是九月下旬了(2020.9.24)，正式开始腾讯实习

第一个需求就是把whosbug迁移到内网，并完成最后的改进、showcase、最后内部上线使用

蓝盾流水线插件

由于最后实现的形式是一个CI流水线插件的形式（蓝盾平台），所以在熟悉工作环境后花了两三天时间开发了whosbug的蓝盾流水线插件，并又花了两天时间单元测试，解决了一系列环境问题后， DONE（2020.10.13）

加密模块的开发和使用

由于whosbug使用的数据库在外网，而其数据又涉及源码信息以及用户信息等敏感信息，所以和腾讯的前辈讨论后认为数据需要加密，小组内经过讨论和设计并与前辈确认后，花了一天时间进行开发和单元测试，并投入使用

灰度环境部署

虽然实训期间也基于k8s部署过，但环境完全不一样了，而且标准也不一样，与实训时的简单部署相比，配置文件中多了许多其它当时没有见过的字段；我参考了QAPM项目的其它很多部署项目的配置文件，边学边改边实践部署，一周半左右过后终于完成了部署

showcase准备

showcase的方式是投入生产环境中的真实项目来测试使用，被测项目是QAPM内的一个app项目
—— LeafPic_qapm_newmonkey（ LeafPic 原项目地址）
本身是一个在Github上面的知名相册app，里面埋入了卡顿、ANR、Crash等问题，便于测试
测试流程还需要与腾讯的NewMonkey项目对接进行，在与NewMonkey的一位负责人进行了几天的加班调试对接后，完整走了整个showcase流程，最终能够输出责任人以及对应缺陷到TAPD的缺陷页面（这个过程中遇到了许多问题，果然再完善的项目一旦投入生产环境使用，一定是会遇到各种各样的问题的，更何况是稚嫩的whosbug了hh）

接入TPS鉴权以及加入反馈模块

询问前辈后接入了CSIG的TPS鉴权模块
加入了对责任人结果正确与否的反馈模块

难点

CI流水线插件开发

由于CI流水线的高自由度，其环境复杂多变，而且whosbug插件是基于python开发的，那就一定离不开python2 / python3兼容性的问题，我参考了很多python项目的解决方案，发现大多数项目都是直接分为python2版本和python3版本，于是我也按这个想法走，基于python的setuptools开发了两套whosbug插件

加密模块

由于whosbug的某些设计，我们对加密方式有一定的要求，即保证密文的有序性（使用流加密方法），个人对密码学一窍不通，只会调包，与组内成员交流测试并解决一些编码问题后，终于能正常投入使用了

项目部署

跟我预想的一样，在腾讯内网的正式环境部署的标准与以前在学校打比赛随手部署的标准完全不一样
首先就是k8s的调度问题，相关的配置之前我从来没有接触过，还好可以参考其它项目的配置文件配合学习，这部分很快就照猫画虎地写好了，但实际部署时还是会出问题，通过kubectl命令行工具仔细排查后发现在连接数据库容器时出现了一些问题，与组内前辈交流后处理了一系列问题，并更正了健康检查（livenessProbe）的相关配置后，部署成功

语法分析工具的缺陷

在准备showcase与负责人对接的过程中发现了ctags对java的语法分析能力十分有限，导致很多堆栈没法找到对应的owner，最终换了被测项目才终于能正常找到责任人

TODO

语法分析能力

在后期投入生产环境使用的过程中发现ctags的语法分析能力严重不足，目前花了一周左右的时间研究了下其它的一些语法分析工具，主要看了下针对java的语法分析工具：

antlr4
javac-parser
javaparser
javalang
astgen
plyj

一圈试用下来，要么就是不支持对具有不完整语法结构的代码的分析，要么是对一些细节上兼容性不好，最后还是选择了antlr4，虽然它的target language为python的文档不多，但我还是慢慢摸索写出了一个能完整分析AllInOneJava7和AllInOneJava8（含有Java7和Java8所有语法结构的源码）的模块，而且antlr本身是一个框架，只需要编写各个语言对应的.g4（语法树）文件，就可以分析各种语言了，后续可以基于antlr4优化我们的语法分析能力