如何定义 “私自夹带代码”？
无法定义就无法认定，那还谈什么解决。

就是字面意思，跟本次需求无关的，都属于。
比如开发之前上线任务遗留的 bug 处理，看到别人写的代码不爽就做了优化等等

没觉得这里有问题啊。认定开发做这些跟本次需求是否相关，有标准可依吗？

和本次需求无关的，这个定义其实还是有灰色地带。

比如为了这次需求实现更便利，调整了以前一些代码的实现模式，这种算是私自夹带代码不？

回归正题，从工具角度解决这个问题，思路上我想到 2 个点：
1、类似精准测试，从代码改动点结合用例执行的覆盖率数据，倒推大概影响的用例或者功能。这样通过看影响功能来辅助倒推是不是有影响一些不该影响的功能。
2、在前期技术方案阶段，就细化到预计需要改动的点（到文件和方法级别），工具检查是否有超出范围的改动。

不过说实话，这两个工具解决私自夹带问题，有点杀猪用牛刀，大材小用了。

根据以前的经验，夹带私货只要测试有覆盖，其实风险还是可控的。我们以前针对这类问题的解决方案是：
1、确认预发环境最后一次构建的版本，到线上实际发布的版本，代码是否有不同点（根据之前线上问题经验，夹带私货导致出线上问题，90% 以上是这个时候引入的修改引起的）。当时主要是人工，当然工具也是可以的，比较 commit 历史即可。
2、如果真的出问题，那就需要复盘时强调影响范围的正确同步，同时相应的开发一起背锅，该影响绩效的影响绩效。
3、同时也引导开发要优化代码或者解决遗留 bug，单独提出即可，并尽量影响范围和本次需求范围重合度高一些，这样不增加测试负担，同时开发也能做好代码优化。

如果是测试执行完成，上线前夕加了代码才能定义为私自夹带代码吧？如果送测版本之前就优化了和本次需求无关的代码那么你没测出来应该是你的问题

感谢解答
我们现在也是靠人工管控的，通过 codeDiff 的方式判断影响范围，但是对于代码基础薄弱的同事不适用

统计增量覆盖率，没覆盖到的代码，很容易辨别是不是本次迭代的相关代码~

封版节点，diff 就以此节点为基准版本，之后的不一致只能是修复线上 bug

你们现在是开发提的影响范围都不靠谱，还是夹带的私货都不同步你们，导致你们没测到，所以直接在线上出问题？

夹带私货，不同步。
像代码改动少的情况，通过 codeDiff 很容易看出来，但是需求改动比较多的情况，一次涉及十几个文件，就很难判断了。

问题是开发提测的时候夹带私货还不同步，你说气人不

hmm，这种和开发人员本身习惯有关。来几次线上事故，复盘时明确说开发夹带私货不同步，让开发背下锅，就好了。因为这个夹带私货本身在研发过程就是不好的事情，正常开发领导都不应该允许这种情况在团队里随意发生。

前面 @gyyfifafans 提到的封版也是一种很好且简单的方式。只要测试握有测试环境、生产环境的代码发布版本控制权就好。

我们之前都是由前后端主程序监控，出问题前后端主程序背锅

1. 从开发提交规范上进行管控，每次 commit 只针对某单独问题。参考 google 的代码提交规范，适度简化。
2. 做 code review 和处理 pr 的人按规范做事。
3. 所部署镜像绑定 tag，测试拉取该 tag 对应的 commit，做一次 git icdiff 看看就好。

我的做法是做个自动发版的功能，思路与 14 楼的类似，通过 commitize(提交代码规范) 来控制，然后在发版的时候，自动化为代码仓库打 tag，遍历提交信息与需求管理工具建立关系，生成发布日志。对比一下需求范围，一目了然。
PS：还可以用新的 tag 来构建服务，发布到预发布环境什么的。
在执行过程中，发现一定是以需求驱动才好做，比较合适敏捷开发的团队。

做增量代码识别，保证增量代码测试用例 100% 覆盖~没覆盖到的代码进行人工确认

感谢各位大佬的回答
1、从实施难易程度与预期落地效果来看，14 楼的方案跟我们团队的目前的流程差不多，在流程管控方面，我们做了测试 coder review、开发交叉 review 环节进行卡点
2、技术层面，增量代码扫描，覆盖率统计，实施起来有一定难度，还需要不断学习