多次事故触发对项目质量保障体系全面反思的疑问？

本文共计2423个文字，预计阅读时间需要10分钟。

近期发生了几起事件，首先是某设备被非法禁止的事件。后台有一个界面，只需输入指定设备的编号，就能禁止在该手机上登录。问题出在输入框，因为没有填写内容，所以点击按钮无反应。

　　近期发生了几件事故，第一件是封禁设备的事故，在后台有张页面，只要输入指定的设备号，就能禁止在该手机上登录。

　　问题就出在这个输入框，因为这个输入框什么也不填，点击按钮，也能发起禁用的接口。

　　有些用户记录中，设备号是空的，那么这些记录就会被命中，从而导致这些用户的账号被莫名禁用。

　　这么敏感的操作，居然没有加任何验证限制，轻轻松松就将几十万的用户封禁了，让人甚是意外，把人家产品都吓坏了，因为她点的这个按钮。

　　第二个事故是一张榜单活动的事故，页面没有真实数据，而是一堆假数据。又把产品吓坏了，一查就发现调用的接口居然是预发环境的。

　　当时是硬编码在代码中，QA也发现不了，因为确实可以读取到线上的数据。但是最近预发环境https的域名到期了，导致无法访问，从而就发生了假数据事故。

　　硬编码域名，遗留的假数据，这些都是比较细节的代码问题，在我看来，都是可以避免的。

　　这些问题虽然低级，但造成的危害可不小，如何有效的进行规避，是我近期一直在思考的事情。

一、Code Review

　　我首先想到的是Code Review，QA并不能帮忙验证代码的问题，但是Code Review可以。

　　大家坐下来，一起检查下代码的写法，一起判断业务逻辑是否合理，很容易就能发现上述两个事故中的问题。

　　其实从去年开始，我就着手组织过屈指可数的几次Code Review，是能发现些问题，但是忙碌的业务压得我们没有时间来做Code Review。