编程界的劣驱良现象有哪些？
2020年的时候，我知道的某个公司的某个别团队搞研发效能提升，其中按OKR的搞法搞了很多可量化的研发指标。 照理来说，搞指标是没什么问题的，但是问题就在这个指标在绩效考核中占了很大的权重（跟年终奖直接挂钩），于是很多人就动起了歪脑筋。 比如考核每千行bug率，然后有的人就开始不使用包管理，往仓库里提交大量第三方代码（可能是所谓的大仓模式雏形，笑了），用海量分母去稀释分子，还串通了几个跟他相熟的人互相CR互刷，最后果然每千行bug率大降。 还有考核代码单元测试覆盖率的，业务代码也要求达到70%覆盖率，业务代码变更快，每个迭代都有大量单测跑不起来需要重写。于是就有很多人去GitHub下载大量有完善单测的三方库往自己仓库里提交。没有用这些小聪明的也是只写主流程分支的测试用例，因为异常分支对单测覆盖率的贡献太低，投入产出比太低，更有甚者是尽量少写异常处理分支从而导致程序鲁棒性降低。于是单测测试的原则，从“对没把握的部分写单测”变成了“对有把握的主流程写单测”，并且这种考核也降低了代码的健壮性。 考核需求完成时间，下面的人就心照不宣地把需求一个拆好个，拆得稀碎，于是需求完成时间骤减，需求吞吐量暴增，仿佛研发效能暴涨。 最神奇的是考核持续集成通过率，本来持续集成是用于提交代码的快速检查的，现在要求检查必须通过，于是持续集成就不允许被使用了，必须自己在本地利用各种持续集成里的数种工具检查完备才能提交。 最傻的时候还有隐形考核代码提交行数、限制每次CR不能超过200行的，每个函数不能超过80行…… 然后最后老板发现，怎么量化考核，考核目标总能顺利高效完成，但是下面骂研发效能下降，却越骂越凶？老板像个穿着新衣的皇帝，手底下的研发一个比一个门清，但是没有一个敢说出真相。 一些没有大公司大型项目实际编程经验的人，很多时候会靠自己读其他人书籍后异想天开的臆想，要用量化指标来考核程序员，但是到最后就会走歪。 程序员的研发产出和质量，到底能不能被可量化的指标评估呢？目前看来好像还没公司走通过这条路，反而是越想评估，研发产出和质量就越低。大家认为能被量化评估吗？