质量度量记实

聚合维度：从目标上来看因为要看部门、应用、人的质量，所以数据就要以这三个维度来聚合。

评价方式：数据有了怎么看是好，还是差呢？这就用到数据的评价方式：横向与别人比、纵向与自己比、达成率、质量分。

改进建议：质量不好，怎么给改进建议呢？这是很复杂的问题，因为这涉及到数据的质量，数据全面性，数据相关性等一系列问题。目前只是做了一些关键数据趋势对比结果输出及纵向比较的结果提示，更多的事情还需要人来做。

部门：1）与人相关的数据，通过"人"所在的部门来聚合，如测试bug数据。2）与应用相关的数据，通过应用与部门的对应关系来聚合，如单测覆盖率数据。

应用：有些数据和应用没有关系，比如测试 bug，在创建时并没有选择应用，我们想过强制要求选择，发现成本很高，后面就放弃了。

横向与别人比：看数据top，平均水平等，举例：8月份，初级 bug 率top3的部门。

纵向与自己比：看数据趋势，举例：最近半年，A部门的月初级 bug 率趋势。

达成率：设定一个指标的目标，各个部门的标准可以一致，也可以根据自己的实际做设定。举例：如单测覆盖达成率，设定目标为应用单测覆盖率要达到80%，如果营销部门一共有10个应用，5个应用达到80%，那么营销部门单测覆盖达成率就是50%。

质量分，计算指标维度分数是一种综合的方式，展现的方式也最直观。算分要求要事先设定好目标阈值，然后计算实际值与阈值的差别，根据一定的算法，得出具体分数。如果给用户的是一个总分，那么通常会设定子维度的权重百分比，加总子维度乘以权重后的得分算出总分。

什么是指标项？在这里是指数据的数量或百分比，如有效 bug 数量、初级 bug 率等。

到底选哪些呢？我们先是列了一些能想到的指标项，再根据数据的成熟度、用户关心程度、实现成本等方面做了反复讨论，定下具体做哪些指标，优先级是怎样。

具体在哪些，如何定义？因为在我们对外的白皮书里有详细介绍，这里就不重复了。

首先数据图表的展示速度很快，因为数据结果基本是预先计算好的，只需要简单的查询与加总就可以返回了。

其次是灵活性比较高，因为需求经常会调整（特别是前期，很多东西都是需要摸索，不断试错的），而数据处理是通过 HIVE 实现，更改后可很快生效，不用走繁琐的系统发布过程。

当然这样的设计另一方面也舍弃数据实效性，但大多数情况下，这些数据实时性要求没有那么高，为了弥补我们也提供了可以手工数据更新的能力。

可以导入数据仓库的数据，这样我们只配置导入或者直接依赖就可以；

提供方式只有是接口的数据，对于这类我们用系统定时任务同步到数据库中，再导入数据仓库。

首先是数据统计粒度问题：我们这里最细的时间粒度是天，如果数据的聚合维度是部门，那就是计算每个部门每天的数据，而周、月的数据，可以基于天的数据再计算，我们考虑如果进一步计算会产生过多的结果表，并且数据量并不太大，就放到页面查询时由系统接口来计算。

其次是全量与增量计算的问题：所谓全量计算就是每次都把全部的数据重新计算一遍，而增量计算就是指只对新增的数据做计算，增量计算数据量小，处理速度快，是最倾向使用的方式，但现实情况要根据数据的实际情况来选择，如果数据产生后会经常变化的，比如 bug 数据，bug 可以从打开到关闭，也可过一段再被打开，这样的数据只能用全量计算。而发布的数据就可以用增量计算，因为每天的发布数据产生之后就不会再变化了。

指标项多，连表过多。
有的数据指标项有十几个，每个指标都需要聚合之后，再与其它指标进行全表连接。开始时我们是根据每个指标去实现的，每个指标产生了一个子表，分别完成之后，发现子表数据根本合不到一起。为了减少子表，我们将聚合条件一致的做了合并，然后再对子表进行了分类，比较相近的子表先两两相连，逐层向上，直到最后合成一张。

有效 bug 是按创建时间还是解决时间算。
一个 bug 是不是有效 bug 是在这个 bug 解决后决定的，当它的创建时间与解决时间不同时，它应归为创建那一天的，还是解决那一天的呢？后来总结发现这两种其实都行，对比来看，以创建时间来算，同一天的数据，不同时间查会不同，而以解决时间来算就会很稳定，显示时能标明当天创建的有效 bug 或者当天解决的有效 bug会比较清楚。