1. 是否有推行代码扫描：看团队，有些团队有有些团队没，但总体来说更多团队愿意尝试
2. 开发配合：这个是强要求开发配合的项目，在推广之前就需要和开发从上至下对齐这个事情的重要性和解决问题的方式；除非测试自己有权力和能力去直接改开发的代码，不然扫出问题就是要开发修改，开发如果一开始就不打算配合那测试单方面做是自嗨
3. 测试单方面配置有无必要：同上，我觉得测试单方面是无法开展的
4. 效果：代码扫描分两种，一种是单纯的编码风格扫描，这个一般开发内部自己推广；另一种是我们更关注的代码缺陷扫描，它本身就是一种前置发现潜在问题的手段。从这边的数据简单去看，尤其是一些线上空指针问题，这种工具在发现能力上是相对可以的，但其实也没有说很多线上问题它都能发现，很多时候它是一个治理隐患的手段，发现效果也因工程的复杂度而异，越是复杂的工程越容易有隐患，用这种工具理论上可以更有帮助

在具体开展上，我觉得可以这样去尝试：

1. 先拿到线上问题数据，拿有问题的代码去扫，看能不能通过扫描发现问题 —— 这一步是回答整个代码扫描的实际价值，如果这里发现代码扫描根本没有抓到多少历史线上问题，那就没必要做了
2. 和开发商量好启用什么扫描规则，不同扫描规则扫出来的问题是否提成 bug 去跟进，对应的优先级又是什么
3. 每个版本，甚至开发每一次的代码合入（Merge Request），开始卡口，先卡增量问题，保证每个版本没有新增问题，再慢慢消费存量问题

基本上大家的套路就是这样