发现我们公司技术人员考核按代码量来的

[Chaconne]

我不是技术哈，但进入了总部一个极可能是技术组长、负责人的电脑，发觉电脑上保存了很多日常的文件，其中有一些就是导出、统计各技术开发人员每日写的代码量的文档。

我不禁会想，技术人员被按写的代码量考核真的合理吗？我们公司平台 bug 也还是不少，会不会——以 bug 出现的数量多寡来考核不是更好一些？按代码数量考核会不会劝退了一部分技术优秀的人？

[darkengine]

以 bug 出现的数量多寡来考核不是更好一些？
--------
并不好，我少写点儿代码，负责的模块少点儿，是不是 bug 更少？

要不参考下 OKR 吧，不要再搞简答的 KPI 了。

[darkengine]

@darkengine 简答 -> 简单

[eason1874]

按 bug 考核的话，那程序员会选择保守策略，尽量不去动原有的，加东西就堆屎山

[xuanbg]

我司要是也按代码量考核就好了。。。我先把代码仓库干爆，然后，没个半小时你休想把代码 clone 下来。打一次包至少 3 小时起步，不然我不要工资！

[Chaconne]

@xuanbg 狠人

[xuanbg]

@Chaconne 这算啥，真狠起来我能做到打个包就要半个月呢。。。就我那小破电脑，半个月能把包打出来算快的啦。

[majula]

前东家的一项重要考核标准就是 bug 数。这个 bug 数有两个来源，一个是线上故障，另外一个是 QA 团队的测试用例反馈结果

再加上我们部门 QA 团队人力有限，对于非核心项目，可以由各个项目小组自行选择是否接入 QA 。结果就是几乎没人选择接入 QA ，都选择自测。。

[edis0n0]

这个简单，引用包都不要用包管理器，手动把包的代码下载下来集成进去，纳入版本管理，kpi 绝对第一名

[hdp5252]

怪不得微信越来越大，找到原因了。
以后我看谁再说安装包大。

[Jooooooooo]

用线上事故考察其实是比较合理的. 至少是因素之一.

[SunsetShimmer]

听起来像是某个著名的笑话...

[nanjingwuyanzu]

我们公司也是的 普通开发千行代码 bug 不能超过 3 个，开发组长千行代码 bug 不能超过 2.5 个，考核 KPI

[hellodigua]

有没有一种可能，有些部门的技术人员写的就是纯粹的业务代码，后端一堆增删改查，前端表格表单，对于这部分业务，真的有可能从代码量看出来工作效率的

[Aurt]

@Jooooooooo 我带过一个组，线上从没出问题，还是要和出问题的组一样把组内的员工分成 369 等。领导会认为你这个组不出问题，不是你带的好，不是架构容错率高，不是组员优秀，是你们的的业务简单。

[Danswerme]

笑死，那不就是这个： https://www.sohu.com/a/116249643_465979

[Danswerme]

@nanjingwuyanzu 我要在你们公司，我感觉我干不到第二天

[Kiriya]

@Danswerme #15 这漫画就差指名道姓了

[James369]

像 for i in 100 这样的代码要拆成 100 行来写。

[nanjingwuyanzu]

@James369 对对对的

[mwVYYA6]

@Kiriya 抢答：哈姆林藕丝