公司新出制度,每月统计提交代码行数来判断工作饱和度,这真的合理吗?
1
xieshaohu 2023-11-03 09:47:19 +08:00
不合理~
|
2
www5070504 2023-11-03 09:54:51 +08:00
这样的话千万别写 python 太吃亏
|
3
Leviathann 2023-11-03 09:57:33 +08:00
严格执行 review 的话,没问题
|
4
HXHL 2023-11-03 09:58:14 +08:00
那建新项目的可太舒服了👀或者放项目里塞几个 css 文件,下个 commit 再删掉
|
5
fredweili 2023-11-03 10:03:13 +08:00
拿生产线的办法管软件,迟早完蛋,外行领导
|
6
mingwiki 2023-11-03 10:04:48 +08:00 1
那代码质量不就爆炸了嘛 跟工资挂钩 谁敢好好 review
|
7
Weedy152 2023-11-03 10:05:01 +08:00
|
8
tsja 2023-11-03 10:05:36 +08:00 4
前端项目把 node_modules 给他上传上去
|
9
Smilencer 2023-11-03 10:05:44 +08:00 1
挺好的,import 都别要了,全部源代码伺候,美滋滋
|
10
sadfQED2 2023-11-03 10:05:51 +08:00 via Android 19
那你们代码库很快就将成为 github 的镜像站
|
11
sky31802 OP @www5070504 java 开发
|
12
fengqi 2023-11-03 10:10:01 +08:00
哈哈哈哈哈,那不用面向对象,不用封装,各种用到用不到的工具类搞起来
|
13
54xavier 2023-11-03 10:10:33 +08:00
那这样的话前端别用组件库了,自己封装,从组件库里面抄过去,别用 npm 包了,全部引入 js ,样式全部隔离,每个页面写一份,别封装工具类了,哪个页面要就 cv 一下
|
14
joyhub2140 2023-11-03 10:13:52 +08:00 1
flutter dart 程序员狂喜
|
15
clue 2023-11-03 10:19:55 +08:00
移除 .gitignore 中的 node_modules 项
定期升级 npm 包 |
16
clue 2023-11-03 10:21:08 +08:00
对了,忘了一点了,你还可以在自己的分支上多用 rebase 指令,时不时就 rebase master 并 push ,有奇效
|
17
Plutooo 2023-11-03 10:21:32 +08:00
不合理,但改变不了规则就适应规则,可以用 gpt 反向润色代码
|
18
noyidoit 2023-11-03 10:22:25 +08:00 12
先把 `.gitignore` 删了
|
19
whp1473 2023-11-03 10:23:08 +08:00
老板都认定了,你就不要挑战了,以后工具类都从新写个自己用的,开源框架用把源码复制出来,不要一次性复制太多,慢慢增加一点一点
|
20
meiyiliya 2023-11-03 10:25:41 +08:00
我们最新也是,看代码量,BUG 数、工时、还检测代码重复率,杜绝重复刷代码的几率,只能参考回字的众多写法。
|
21
besto 2023-11-03 10:25:47 +08:00 1
@Leviathann
@fredweili @HXHL 如果严格执行 review 制度,且以这个算 KPI 是最好的,因为程序员的 KPI 并没有那么好确定。 这里一定要强调编码规范,严格 review 。 以上两点华为做的很好。 不过这里有两个引申话题: 1. 一个好的公司,要允许有闲人,特别是大牛更是有工作不饱和的表象; 2. 如果有些人觉得自己吃亏了,比如技术牛叉,一个 bug 别人解了半个月,你 5 分钟解决,就改了一行 code ,那么只能说明,你们的职位并不是单纯的 coder ,更像是 arch 或是 system debugger 。这个时候要引入另一种 KPI 计算机制,比如,以 bug 的难度来算,把解掉的 bug * 难度系数(严重级别)相加,诸如此类。 |
22
c2const 2023-11-03 10:35:25 +08:00
不合理,用 chatGPT 帮你多造些轮子,扩展代码,还不容易出错,最后自己审查一下就行 :)
-------------- 可以准备投简历/面试了 :) |
23
yolee599 2023-11-03 10:39:10 +08:00
直接把编译生成的中间文件 push 上去,代码行数直接爆炸
|
25
sky31802 OP |
26
Pony69 2023-11-03 10:46:09 +08:00 2
如何评价领导要用代码行数衡量每个人的工作量? - PegasusWang 的回答 - 知乎
https://www.zhihu.com/question/295181406/answer/513197860 |
27
c6h6benzene 2023-11-03 10:49:30 +08:00 via iPhone
写了 Unit Test 之后才发现,如果要 mock response 的话,每个 class 也是落落长。
|
28
scorpion91 2023-11-03 10:56:23 +08:00
其实大多数程序员都是 70%的时间思考,30%的时间编码,所以这样不合理
|
30
cyrbuzz 2023-11-03 11:04:39 +08:00
yarn lock npm lock pnpm lock,每天升级一轮小版本,升到头了再降回去。
|
31
Techzero 2023-11-03 11:06:03 +08:00
我司也是最近开始统计 gitlab 代码量了,而且要求组长每周抽查一个组员,要求上报发现的问题,经理抽查组长的
|
32
worldqiuzhi 2023-11-03 11:09:00 +08:00
如果去除为了 kpi 故意灌水,大多数情况下是挺合理的。 大多数人的工作又不是发射火箭上天,就是垒砖头,代码行数能决定八成工作量了。
但这玩意,只能作为领导私下的参考,不能拿到明面上。 你说出来,代码想灌水可太容易了,把成熟的库,全部换成不成熟的 csdn 复制,然后故意写的啰嗦一点,太容易了 |
34
ooee2016 2023-11-03 11:10:40 +08:00
需求分析, 代码编写, 功能测试, 系统维护
敲代码只是很少的一部分 |
35
x7DnVcd9bA706oWp 2023-11-03 11:38:36 +08:00
上有政策 下有对策;他不仁 你不义
|
37
duluosheng 2023-11-03 12:31:45 +08:00
水代码和注释
|
38
nothingistrue 2023-11-03 12:42:50 +08:00
@besto #21 严格 review 消耗的成本,是要远大于 KPI 逼出来的工作收益的,这还没算严格 review 本身所需的「编码规范自身的持续改善,和旧编码的持续改善」成本。你这就是说得一本正经,一深入分析就是胡说。
|
39
silentsky 2023-11-03 12:47:02 +08:00 via Android
屎山代码看来是避免不了了
|
40
aweim 2023-11-03 12:47:17 +08:00
那不很好吗;多写写无用的代码。。。
公司有这样的决策,说明不懂,那你们岂不是更好玩了。 |
41
besto 2023-11-03 13:04:33 +08:00
@nothingistrue 这是大公司和小公司的区别,大公司允许使用一堆庸人,如果你只是优秀一点点,那么另宁用制度把你变成庸人(平均水平),这样便于管理,简单来说,5 个人你搞这套制度就是傻逼,20 个人的团队,你不这么干也能凑合,100 人的团队,不这么干就可能出事情。
另外大公司的流程是配套进行的,根本不可能只有一套判定逻辑,拿遥遥领先公司的制度举例: 遥遥领先不仅使用代码量作为 KPI 的一部分,还有如下: 1. 代码严格 reivew ,每个 team 都有负责人,不可能让你随便造个轮子刷数据; 2. 项目严格工期控制,文档多久写完,写完文档要评估项目节点,包括 ut st 的时间节点也算上,每个点有没有按时达标,都是考量; 3. 一堆代码分析静态检查的工具(这个听起来烦人,实际也确实没啥用,但这个部分占比并不多)这个的处理也要算到 2 的工期里的,甚至函数长度太长,函数调用关系过于复杂,层数太多都是要被打回来的,当然不一定改,但要有合理解释; 4. 质量控制,如果代码合入之后发布了有问题的版本,直接小黑心,今年不可评优; 大公司很需要制度来运转,否则摸鱼的太多,付出再多的成本也是没办法的。 |
43
zhangqilin 2023-11-03 13:25:55 +08:00
|
44
jim9606 2023-11-03 13:27:18 +08:00 via Android 1
|
45
drich 2023-11-03 13:30:39 +08:00
跟我一开始在华为的时候一样
写了多少行代码,处理了几个问题单,开发了多少个需求 |
46
kirito41dd 2023-11-03 13:40:10 +08:00
多来点代码生成,grpc ,thrift 啥的,上就完了
|
47
nothingistrue 2023-11-03 14:18:53 +08:00
@besto #41 所以华为的 KPI 有用吗?或者说代码量有参与 KPI 吗?但凡你真在华为干过,你不会说华为 KPI 做得好。
|
48
snowlyg 2023-11-03 14:32:40 +08:00
@scorpion91 老板,领导不是写代码的,谁管你这些。我们老板只要看到我们手没在敲键盘就觉得你在偷懒
|
49
horizon 2023-11-03 14:40:30 +08:00
可以参考吧,一行代码都不写的混子就现形了
|
50
libook 2023-11-03 15:03:00 +08:00
|
52
pkoukk 2023-11-03 15:25:25 +08:00
interface A { func A()}
interface B { func B()} interface C { A B } 套呗,别问,问就是充分抽象,灵活组织,充分解耦合 一个实现类能实现几百个 interface ,你服不服 |
53
pengtdyd 2023-11-03 15:31:35 +08:00
ChatGPT:请润色一下我今天的代码
哈哈哈。 |
54
hancai 2023-11-03 15:31:36 +08:00
多写点 if err!=nill {}
|
55
Lee2019 2023-11-03 16:10:34 +08:00
接入 gitlab-ci 多调试流水线如何
|
56
flyv2x 2023-11-03 16:21:10 +08:00
这个真的是一天 5 ~ 10 个 commit 搞定,feat fix fix
|
57
lifesimple 2023-11-03 16:27:06 +08:00
前端的话 直接就本来 npm 引入的包,直接拿下来放项目里完事了
|
58
pikko 2023-11-03 16:31:48 +08:00
我们只会作辅助参考,这个本来就只能作为辅助。
要是作为 kpi 真的不敢想象。 |
59
TAFMT 2023-11-03 17:14:28 +08:00
|
60
litchinn 2023-11-03 17:23:20 +08:00
无脑堆设计模式,一个 new 可以写 10 个类出来,这种考核完全没意义,属于不写代码的领导 yy 出来的考核指标,用什么考察最后就会得到什么。
楼上也有说辅助参考的,我觉得参考价值都没有,如果一个人不写代码也能完成任务,我觉得也没有任何问题 |
61
ddkk1112 2023-11-03 17:30:37 +08:00
把用到的包自己复制修改一下
|
62
AnnaXia 2023-11-03 17:34:39 +08:00
第一次听到这个的时候,作为程序员第一反应是不好,这岂不是会朝着代码灌水的方向发展。但后来领导问,那如果不用这个,你有其他可量化、可考核的指标来衡量程序员的产出么。想了好一会,只能承认这种方式也不能说是完全不合理,只是需要一些补充信息来尽量完善这种考核吧,比如楼上提到的需要代码走查、解决 bug 时的代码行数可引入 bug 难度来综合考虑等
|
63
Excepti0n 2023-11-03 17:48:47 +08:00
以后不用注解了
每个 bean 多写点字段 |
64
ly529 2023-11-03 18:06:35 +08:00
可能快黄了,公司领导已经没事干了
|
65
franktopplus 2023-11-03 18:18:04 +08:00 via Android
我们就在用。老板不懂可以原谅,技术负责人不跟老板解释清楚统计这玩意没有用,不可原谅
|
66
nbndco 2023-11-03 18:32:09 +08:00 via iPhone
@besto 华为那代码质量做案例也太不合适了。
至于这个做 kpi 基本是蠢的没边了。一是想把代码写短是很难的,想把代码写的清晰漂亮更难,但是这些基本都和这个 kpi 背道而驰。二是 test 想写几百行几千行真的和玩一样,你 reviewer 难道还能让我少写几个 test case ? |
67
SteinsGate 2023-11-03 18:36:55 +08:00 via Android
我这也有,但是是偷偷搞得,统计脚本是我写的(🐶)
|
68
billccn 2023-11-03 20:25:09 +08:00
我有一个简单的办法,以遵循 Google 代码风格指南为理由,每周把一行字数限制逐渐下调,直到 80 为止。逐渐调整的理由是可以减少每次影响的行数,避免影响其他同事工作。也可以和同事分工,每周换个人调。
到了 80 以后,找个同事说说 80 换行太频繁了,影响代码阅读,再逐渐上调至 200 。 到了 200 再说行太宽了,并排 code review 屏幕放不下,还是 Google 有先见之明,再逐渐改到 80 。 希望这个时候傻逼政策已经取消了。 |
69
akira 2023-11-03 20:59:38 +08:00
想起一个好玩的事情。早些年玩花指令的时候,把一行汇编代码扩充成几十几百甚至无数条汇编代码。
|
70
mingl0280 2023-11-03 22:23:42 +08:00 via Android
gcc -E
|
71
x86 2023-11-03 22:25:52 +08:00 via iPhone
利好前端呀
|
72
mkoijnbhu 2023-11-04 00:21:03 +08:00 via Android
多封装些用不到两三次次的函数,问就是层次结构清晰。
下班前查查今天的行数,不够就抄几个工具类🎉 |
73
fyq 2023-11-04 01:02:51 +08:00
感觉你们公司要黄了……
|
74
someonedeng 2023-11-04 01:06:37 +08:00
这是冲着倒闭踩死油门。。
|
75
dangyuluo 2023-11-04 01:35:31 +08:00
挺合理的,我可以一个月写几万行垃圾代码
|
76
AS4694lAS4808 2023-11-04 06:53:12 +08:00 via Android 1
现在就去一个一个把 lambda 拆了
|
77
jackOff 2023-11-04 18:43:53 +08:00
请像一个大四实习生一样装出懵懂无知,不要使用框架了,自己手搓,不要使用装饰器这些简洁高效的东西,要手搓每一个功能的数据库、缓存、内存的连接和释放,自己想办法写一个废话文学版本的代码生成器,慢慢地放弃使用中间件这些东西,重写每一个第三方依赖包,问就是在审核依赖包安全,自己手搓这代码量不是质的飞跃?
|
78
realJamespond 2023-11-05 22:43:33 +08:00
没东西写就写单元测试啊
|