SQL审核中的打分模块设计

这是学习笔记的第 1740 篇文章

如果你花了一些时间和精力来对SQL审核做一些改进，对于审核的规则和定义已经炉火纯青，里面肯定包含了很多的细节，也包含了很多的技巧，一条SQL语句我们可以给出20条甚至更多的建议，从技术上来说是成功的，但是从业务的使用来说，可能是一种不大友好的方式。 

第一，业务还不大了解审核的建议，有些术语或者描述可能看得不是很明白和理解 。

第二，对于使用者来说，定制的逻辑和细节太多，导致给出的建议太多，无从下手。

第三，很多建议可能因为现实情况没法一一改正，但是对于一些硬性要求来说，需要改正，这是自助审核的意义所在。

而对于开发者来说，定制的规则和逻辑太多，导致定制的难度极高。

所以我们对于审核规则可以做到一些定制，这个定制就意味着，从审核工具返回时就约定一个code，通过code来做应用后端做审核规则的定制和管理，在这个地方，我们设置了三个层面，必须改进，潜在问题和建议改进，必须改进就是硬性的要求，比如表要有主键，字符集，大小写等等，这些是没商量的，违反了就要更正，潜在问题就是哪些看起来不直接违法规范，但是使用中会有一些潜在问题，比如使用了enum类型，建议使用tinyint，比如使用了timestamp，则提示timestamp的范围可能会比较受限，建议再斟酌下，而建议改进，则是哪些满足基本规范和标准的前提下，建议业务同学改进的一种方式，比如字段的注释，比如我们几乎没法要求每个同学都对字段有一个标注。

    所以我们从后端把规则都沉淀出来，做成元数据管理起来，我们可以改变规则的类别，比如初期的时候，大家违反的“必须改进”类问题多一些，改进之后，我们就可以适当的调整这些规则的类别，反向来促进应用的使用习惯。

这个时候你做完之后会发现，原来看起来比较松散的规则一下子梳理整齐了。

比如有20个建议，可能必须要改正的建议有3个，那么这3个就是重中之重，可能建议的改进有10个，我们可以逐步的完善。

这样就带来了第二个问题，怎么让应用对自己的SQL有一个更直观的认识呢。我们可以考虑打分机制。

打分其实是可视化的一种方式，通过分数能够直观的看到一个结果的好坏程度。通过分数有几个意思，一个是对结果的可视化，另外一个则是激励机制。如果一个人看到分数很低，必然会有改进的欲望。

打分机制是在审核规则基本稳定的情况下需要考虑的，对此我设置了如下的积分规则。

1.分为“必须改进”，“潜在问题”，“建议改进”三类，权重值分别为10,5,2  

2.三种类型的权重值分数比例为40,30,30

3.“必须改进”类型个数如果超过3个，则直接扣除40分  

4.“潜在问题”类型个数如果超过5个，则直接扣除30分  

5.“建议改进”类型个数如果超过8个则，直接扣除30分  

6. 如果为满分100，则扣除1分， 提示“满分会怕你骄傲，继续保持” 

7. 如果分数低于50，最低置为50 

我们看一个基本的小例子，可以看到给了4个建议，其中一个建议是比较重要的，另外的改进建议则可以根据实际情况来考虑。

相关链接：