公司通过统计 gitlab 提交代码行数来判断工作饱和度

[sky31802]

公司新出制度，每月统计提交代码行数来判断工作饱和度，这真的合理吗？

[besto]

@Leviathann
@fredweili
@HXHL
如果严格执行 review 制度，且以这个算 KPI 是最好的，因为程序员的 KPI 并没有那么好确定。
这里一定要强调编码规范，严格 review 。
以上两点华为做的很好。
不过这里有两个引申话题：
1. 一个好的公司，要允许有闲人，特别是大牛更是有工作不饱和的表象；
2. 如果有些人觉得自己吃亏了，比如技术牛叉，一个 bug 别人解了半个月，你 5 分钟解决，就改了一行 code ，那么只能说明，你们的职位并不是单纯的 coder ，更像是 arch 或是 system debugger 。这个时候要引入另一种 KPI 计算机制，比如，以 bug 的难度来算，把解掉的 bug * 难度系数（严重级别）相加，诸如此类。

[c2const]

不合理，用 chatGPT 帮你多造些轮子，扩展代码，还不容易出错，最后自己审查一下就行 :)

--------------

可以准备投简历/面试了 :)

[yolee599]

直接把编译生成的中间文件 push 上去，代码行数直接爆炸

[codeself]

@clue rebase 这个可太刑了，同事问到了就装傻，说自己装的 git 工具出问题了

[sky31802]

@besto 认同你的观点 程序员的 KPI 确实没那么好界定 跟销售不一样有业绩衡量
@meiyiliya 我们也差不多 每月统计代码行数新提出来的规则

现在比较难受的是大家写代码的时候潜意识里都想多写点代码，可能本来两行搞定，会想着能不能三行或者五行，我是觉得这种统计方式极度不合理

[Pony69]

如何评价领导要用代码行数衡量每个人的工作量？ - PegasusWang 的回答 - 知乎
https://www.zhihu.com/question/295181406/answer/513197860

[c6h6benzene]

写了 Unit Test 之后才发现，如果要 mock response 的话，每个 class 也是落落长。

[scorpion91]

其实大多数程序员都是 70%的时间思考，30%的时间编码，所以这样不合理

[vem]

@Pony69 哈哈 我刚想贴这组漫画来着

[cyrbuzz]

yarn lock npm lock pnpm lock,每天升级一轮小版本，升到头了再降回去。

[Techzero]

我司也是最近开始统计 gitlab 代码量了，而且要求组长每周抽查一个组员，要求上报发现的问题，经理抽查组长的

[worldqiuzhi]

如果去除为了 kpi 故意灌水，大多数情况下是挺合理的。 大多数人的工作又不是发射火箭上天，就是垒砖头，代码行数能决定八成工作量了。

但这玩意，只能作为领导私下的参考，不能拿到明面上。 你说出来，代码想灌水可太容易了，把成熟的库，全部换成不成熟的 csdn 复制，然后故意写的啰嗦一点，太容易了

[hokori]

@Pony69 #26 这个漫画有意思

[ooee2016]

需求分析, 代码编写, 功能测试, 系统维护
敲代码只是很少的一部分

[x7DnVcd9bA706oWp]

上有政策 下有对策；他不仁 你不义

[fredweili]

@besto 简单的道理就是牛人不屑于搞这种八股的，有本事就换家，所谓难度系数也很难量化

[duluosheng]

水代码和注释

[nothingistrue]

@besto #21 严格 review 消耗的成本，是要远大于 KPI 逼出来的工作收益的，这还没算严格 review 本身所需的「编码规范自身的持续改善，和旧编码的持续改善」成本。你这就是说得一本正经，一深入分析就是胡说。

[silentsky]

屎山代码看来是避免不了了

[aweim]

那不很好吗；多写写无用的代码。。。
公司有这样的决策，说明不懂，那你们岂不是更好玩了。