关于工作中考核代码量的一些思考

不知道是不是因为现在大环境不太好的原因，现在公司开始考核代码量了。

考核方式也挺简单，有一个叫思码逸的平台（链接不贴了，不想推广这种产品），可以统计代码行数，代码的复杂度等情况，然后根据一定的规则，得到一定的分数，最后根据这个分数排名，然后和绩效挂钩。

理论上，这个平台想对代码情况做到一个量化，但真的做得到吗？

写代码理论上作为一个脑力劳动，代码写出来也是不可见的，除非人工复检，不然很难评估某一段代码的价值高低。

比如：

• 写核心逻辑引擎的部分，肯定比写接口层的代码量要少，但接口层的代码可能一年就废掉了，而核心逻辑引擎的代码可能要运行七八年，而且核心代码付出的脑力思考更是要多得多。
• 修bug这种事该怎么量化呢？查了半天bug，结果是一个配置导致的问题，一行代码量也没有。
• 而且不同地方的bug，修复难度也不一样，有的时候一行代码就是比别人几十行代码管用。
• 现在有很多模板引擎可以生成代码，这里又是怎么考核呢？
• 前端、后端、运维不同工种，不同语言的的代码，效果也是完全不一样的，有的人全栈，他归在哪一类考核呢？
• 等等

既然现在机器考核代码量， 还要这么多的问题难以解决，为什么公司还要推行这个考核呢？

我觉得最大的问题，就是公司领导层对于底层的一种不信任的心理在作怪。

也就是说，老板们花钱雇员工来是干活的，不是来摸鱼的，可能老板们在网上看到员工摸鱼的段子多了，就不自然的带入到了自己身上，自己的员工在不在摸鱼呢？

可是高管们又不能天天盯着员工干活，还不相信自己的员工在认真的干活，就只能拿出所谓的“管理大法”来“科学”的管理员工了。

而现代的管理工具，说到底就两件事：量化，绩效。

绩效：就是把本来应该发给员工的钱分成两部分，一部分是必发底薪，一部分是浮动绩效，看你的表现而给钱。
量化：辅助绩效的评估办法，给一个员工发多少绩效，总要有个依据吧，这就要对员工的工作进行量化了，也就是员工做的工作都要能够用数字体现出来。

你看，从设计上看，都是很好的工具，既能激发员工的能动性，又能保证绩效发放的公平性。

但无论什么工具都能被中国的老板把经给念歪了。

老板不想多出钱搞继续，就把继续强制比例分布，比如2：7：1，相当于把底层1成的员工的绩效来补贴给上部的2成的员工，而对于公司，没有多花任何成本。而且这种行为还有一个很好听的名字：“不断奔跑”，“选择合适的人”。

在量化上，就是万物皆可量化，不能量化的东西就是管理不科学、创新不到位。量化最终演化成了公司监视员工的工具，而失去了其本来公平考核的本面目。

而且，最重要的，量化和绩效评定都是非公开的，“薪酬保密制度”最终成了高管们暗箱操作的保护衣。

所以，对于程序员这个产出只有代码的脑力劳动群体，代码量考核，就成了老板们的“科学考核”下的一个必然选择。

然后我说一下，代码量化考核后的现状：

• 大家更倾向于写CURD这种容易产生代码量的部分，而不是核心业务，有那种代码生成工具的更好
• 代码越复杂越好，能10行解决的事，坚决不一行搞定
• 为了增加代码量，可能会有一些根本用不上的代码被提交上去，导致后面除了当事人，谁也不敢删这段逻辑
• 在明知有bug的情况下，仍然提交代码，为的就是后面修改bug的代码量（不用找bug，耗时很短）。
• 大量的代码复制粘贴的现场出现，完全背离了代码复用的初衷。但也有个好处，降低了代码耦合度。
• 重复造轮子现象出现，尽管有一些开源成熟方案。
• 等等我一些没发现的坑。

本来多个人维护一个项目，就容易导致“代码屎山”的产生，如何维护就是业界的一个大难题，现在“屎山”的产生速度指数倍的增长。

只能说，上有政策，下有对策。反正过几年就被裁员了，没必要为了代码的质量而跟工资过不去。

回到问题，为什么会要有代码量考核呢？更深一层，为什么会存在所谓的“管理大法”呢？

本质上是公司老板对员工天然的不信任感导致的：既想马儿跑，又不相信马儿会真的跑，还不舍得给马儿吃草。

今年，有一个问题在网络上很火：为什么大公司没有搞出deepseek这样的产品呢？

我觉得看到今天的文章，可能会有一些思考吧。