这是一个创建于 386 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司新出制度，每月统计提交代码行数来判断工作饱和度，这真的合理吗？
 |
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
没东西写就写单元测试啊
|
Select Language