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

不合理～

这样的话千万别写 python 太吃亏

严格执行 review 的话，没问题

那建新项目的可太舒服了或者放项目里塞几个 css 文件，下个 commit 再删掉

拿生产线的办法管软件，迟早完蛋，外行领导

那代码质量不就爆炸了嘛 跟工资挂钩 谁敢好好 review

有助于重复造轮子

前端项目把 node_modules 给他上传上去

挺好的，import 都别要了，全部源代码伺候，美滋滋

那你们代码库很快就将成为 github 的镜像站

@www5070504 java 开发

哈哈哈哈哈，那不用面向对象，不用封装，各种用到用不到的工具类搞起来

那这样的话前端别用组件库了，自己封装，从组件库里面抄过去，别用 npm 包了，全部引入 js ，样式全部隔离，每个页面写一份，别封装工具类了，哪个页面要就 cv 一下

flutter dart 程序员狂喜

移除 .gitignore 中的 node_modules 项
定期升级 npm 包

对了，忘了一点了，你还可以在自己的分支上多用 rebase 指令，时不时就 rebase master 并 push ，有奇效

不合理，但改变不了规则就适应规则，可以用 gpt 反向润色代码

先把 `.gitignore` 删了

老板都认定了，你就不要挑战了，以后工具类都从新写个自己用的，开源框架用把源码复制出来，不要一次性复制太多，慢慢增加一点一点

我们最新也是，看代码量，BUG 数、工时、还检测代码重复率，杜绝重复刷代码的几率，只能参考回字的众多写法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Pony69 #26 这个漫画有意思

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

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

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

水代码和注释

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

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

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

@nothingistrue 这是大公司和小公司的区别，大公司允许使用一堆庸人，如果你只是优秀一点点，那么另宁用制度把你变成庸人（平均水平），这样便于管理，简单来说，5 个人你搞这套制度就是傻逼，20 个人的团队，你不这么干也能凑合，100 人的团队，不这么干就可能出事情。
另外大公司的流程是配套进行的，根本不可能只有一套判定逻辑，拿遥遥领先公司的制度举例：
遥遥领先不仅使用代码量作为 KPI 的一部分，还有如下：
1. 代码严格 reivew ，每个 team 都有负责人，不可能让你随便造个轮子刷数据；
2. 项目严格工期控制，文档多久写完，写完文档要评估项目节点，包括 ut st 的时间节点也算上，每个点有没有按时达标，都是考量；
3. 一堆代码分析静态检查的工具（这个听起来烦人，实际也确实没啥用，但这个部分占比并不多）这个的处理也要算到 2 的工期里的，甚至函数长度太长，函数调用关系过于复杂，层数太多都是要被打回来的，当然不一定改，但要有合理解释；
4. 质量控制，如果代码合入之后发布了有问题的版本，直接小黑心，今年不可评优；

大公司很需要制度来运转，否则摸鱼的太多，付出再多的成本也是没办法的。

@besto 有同感 大公司里每个人搬好自己的砖 整个公司就能正常运转 想想其实也挺神奇

@www5070504 写单元测试就行了，
assert value[0] == value[1]
......
写个 20 行

想起这个了
怎么能不教训一下管理层呢？

https://mp.weixin.qq.com/s/9nh67iTgT2EeLKEwkeZF4Q
https://mp.weixin.qq.com/s/q05WjqoylktZjoshKycxdg

跟我一开始在华为的时候一样
写了多少行代码，处理了几个问题单，开发了多少个需求

多来点代码生成，grpc ，thrift 啥的，上就完了

@besto #41 所以华为的 KPI 有用吗？或者说代码量有参与 KPI 吗？但凡你真在华为干过，你不会说华为 KPI 做得好。

@scorpion91 老板，领导不是写代码的，谁管你这些。我们老板只要看到我们手没在敲键盘就觉得你在偷懒

可以参考吧，一行代码都不写的混子就现形了

这个漫画很棒
https://mp.weixin.qq.com/s/9nh67iTgT2EeLKEwkeZF4Q
https://mp.weixin.qq.com/s/q05WjqoylktZjoshKycxdg

@libook 难不成我们的终极方案是粘贴 spring 源码吗 [狗头]

interface A { func A()}
interface B { func B()}
interface C { A B }
套呗，别问，问就是充分抽象，灵活组织，充分解耦合
一个实现类能实现几百个 interface ，你服不服

ChatGPT：请润色一下我今天的代码

哈哈哈。

多写点 if err!=nill {}

接入 gitlab-ci 多调试流水线如何

这个真的是一天 5 ～ 10 个 commit 搞定，feat fix fix

前端的话 直接就本来 npm 引入的包，直接拿下来放项目里完事了

我们只会作辅助参考，这个本来就只能作为辅助。
要是作为 kpi 真的不敢想象。

无论什么工具类，用的时候，自己造一个

无脑堆设计模式，一个 new 可以写 10 个类出来，这种考核完全没意义，属于不写代码的领导 yy 出来的考核指标，用什么考察最后就会得到什么。
楼上也有说辅助参考的，我觉得参考价值都没有，如果一个人不写代码也能完成任务，我觉得也没有任何问题

把用到的包自己复制修改一下

第一次听到这个的时候，作为程序员第一反应是不好，这岂不是会朝着代码灌水的方向发展。但后来领导问，那如果不用这个，你有其他可量化、可考核的指标来衡量程序员的产出么。想了好一会，只能承认这种方式也不能说是完全不合理，只是需要一些补充信息来尽量完善这种考核吧，比如楼上提到的需要代码走查、解决 bug 时的代码行数可引入 bug 难度来综合考虑等

以后不用注解了
每个 bean 多写点字段

可能快黄了，公司领导已经没事干了

我们就在用。老板不懂可以原谅，技术负责人不跟老板解释清楚统计这玩意没有用，不可原谅

@besto 华为那代码质量做案例也太不合适了。

至于这个做 kpi 基本是蠢的没边了。一是想把代码写短是很难的，想把代码写的清晰漂亮更难，但是这些基本都和这个 kpi 背道而驰。二是 test 想写几百行几千行真的和玩一样，你 reviewer 难道还能让我少写几个 test case ？

我这也有，但是是偷偷搞得，统计脚本是我写的（）

我有一个简单的办法，以遵循 Google 代码风格指南为理由，每周把一行字数限制逐渐下调，直到 80 为止。逐渐调整的理由是可以减少每次影响的行数，避免影响其他同事工作。也可以和同事分工，每周换个人调。

到了 80 以后，找个同事说说 80 换行太频繁了，影响代码阅读，再逐渐上调至 200 。

到了 200 再说行太宽了，并排 code review 屏幕放不下，还是 Google 有先见之明，再逐渐改到 80 。

希望这个时候傻逼政策已经取消了。

想起一个好玩的事情。早些年玩花指令的时候，把一行汇编代码扩充成几十几百甚至无数条汇编代码。

gcc -E

利好前端呀

多封装些用不到两三次次的函数，问就是层次结构清晰。
下班前查查今天的行数，不够就抄几个工具类

感觉你们公司要黄了……

这是冲着倒闭踩死油门。。

挺合理的，我可以一个月写几万行垃圾代码

现在就去一个一个把 lambda 拆了

请像一个大四实习生一样装出懵懂无知，不要使用框架了，自己手搓，不要使用装饰器这些简洁高效的东西，要手搓每一个功能的数据库、缓存、内存的连接和释放，自己想办法写一个废话文学版本的代码生成器，慢慢地放弃使用中间件这些东西，重写每一个第三方依赖包，问就是在审核依赖包安全，自己手搓这代码量不是质的飞跃？

没东西写就写单元测试啊