V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
sky31802
V2EX  ›  职场话题

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

  •  
  •   sky31802 · 113 天前 · 6002 次点击
    这是一个创建于 113 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    78 条回复    2023-11-05 22:43:33 +08:00
    xieshaohu
        1
    xieshaohu  
       113 天前
    不合理~
    www5070504
        2
    www5070504  
       113 天前
    这样的话千万别写 python 太吃亏
    Leviathann
        3
    Leviathann  
       113 天前
    严格执行 review 的话,没问题
    HXHL
        4
    HXHL  
       113 天前
    那建新项目的可太舒服了👀或者放项目里塞几个 css 文件,下个 commit 再删掉
    fredweili
        5
    fredweili  
       113 天前
    拿生产线的办法管软件,迟早完蛋,外行领导
    mingwiki
        6
    mingwiki  
       113 天前   ❤️ 1
    那代码质量不就爆炸了嘛 跟工资挂钩 谁敢好好 review
    Weedy152
        7
    Weedy152  
       113 天前
    有助于重复造轮子
    tsja
        8
    tsja  
       113 天前   ❤️ 4
    前端项目把 node_modules 给他上传上去
    Smilencer
        9
    Smilencer  
       113 天前   ❤️ 1
    挺好的,import 都别要了,全部源代码伺候,美滋滋
    sadfQED2
        10
    sadfQED2  
       113 天前 via Android   ❤️ 19
    那你们代码库很快就将成为 github 的镜像站
    sky31802
        11
    sky31802  
    OP
       113 天前
    @www5070504 java 开发
    fengqi
        12
    fengqi  
       113 天前
    哈哈哈哈哈,那不用面向对象,不用封装,各种用到用不到的工具类搞起来
    54xavier
        13
    54xavier  
       113 天前
    那这样的话前端别用组件库了,自己封装,从组件库里面抄过去,别用 npm 包了,全部引入 js ,样式全部隔离,每个页面写一份,别封装工具类了,哪个页面要就 cv 一下
    joyhub2140
        14
    joyhub2140  
       113 天前   ❤️ 1
    flutter dart 程序员狂喜
    clue
        15
    clue  
       113 天前
    移除 .gitignore 中的 node_modules 项
    定期升级 npm 包
    clue
        16
    clue  
       113 天前
    对了,忘了一点了,你还可以在自己的分支上多用 rebase 指令,时不时就 rebase master 并 push ,有奇效
    Plutooo
        17
    Plutooo  
       113 天前
    不合理,但改变不了规则就适应规则,可以用 gpt 反向润色代码
    noyidoit
        18
    noyidoit  
       113 天前   ❤️ 12
    先把 `.gitignore` 删了
    whp1473
        19
    whp1473  
       113 天前
    老板都认定了,你就不要挑战了,以后工具类都从新写个自己用的,开源框架用把源码复制出来,不要一次性复制太多,慢慢增加一点一点
    meiyiliya
        20
    meiyiliya  
       113 天前
    我们最新也是,看代码量,BUG 数、工时、还检测代码重复率,杜绝重复刷代码的几率,只能参考回字的众多写法。
    besto
        21
    besto  
       113 天前   ❤️ 1
    @Leviathann
    @fredweili
    @HXHL
    如果严格执行 review 制度,且以这个算 KPI 是最好的,因为程序员的 KPI 并没有那么好确定。
    这里一定要强调编码规范,严格 review 。
    以上两点华为做的很好。
    不过这里有两个引申话题:
    1. 一个好的公司,要允许有闲人,特别是大牛更是有工作不饱和的表象;
    2. 如果有些人觉得自己吃亏了,比如技术牛叉,一个 bug 别人解了半个月,你 5 分钟解决,就改了一行 code ,那么只能说明,你们的职位并不是单纯的 coder ,更像是 arch 或是 system debugger 。这个时候要引入另一种 KPI 计算机制,比如,以 bug 的难度来算,把解掉的 bug * 难度系数(严重级别)相加,诸如此类。
    c2const
        22
    c2const  
       113 天前
    不合理,用 chatGPT 帮你多造些轮子,扩展代码,还不容易出错,最后自己审查一下就行 :)

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

    可以准备投简历/面试了 :)
    yolee599
        23
    yolee599  
       113 天前
    直接把编译生成的中间文件 push 上去,代码行数直接爆炸
    codeself
        24
    codeself  
       113 天前 via iPhone
    @clue rebase 这个可太刑了,同事问到了就装傻,说自己装的 git 工具出问题了
    sky31802
        25
    sky31802  
    OP
       113 天前
    @besto 认同你的观点 程序员的 KPI 确实没那么好界定 跟销售不一样有业绩衡量
    @meiyiliya 我们也差不多 每月统计代码行数新提出来的规则

    现在比较难受的是大家写代码的时候潜意识里都想多写点代码,可能本来两行搞定,会想着能不能三行或者五行,我是觉得这种统计方式极度不合理
    Pony69
        26
    Pony69  
       113 天前   ❤️ 2
    如何评价领导要用代码行数衡量每个人的工作量? - PegasusWang 的回答 - 知乎
    https://www.zhihu.com/question/295181406/answer/513197860
    c6h6benzene
        27
    c6h6benzene  
       113 天前 via iPhone
    写了 Unit Test 之后才发现,如果要 mock response 的话,每个 class 也是落落长。
    scorpion91
        28
    scorpion91  
       113 天前
    其实大多数程序员都是 70%的时间思考,30%的时间编码,所以这样不合理
    vem
        29
    vem  
       113 天前
    @Pony69 哈哈 我刚想贴这组漫画来着
    cyrbuzz
        30
    cyrbuzz  
       113 天前
    yarn lock npm lock pnpm lock,每天升级一轮小版本,升到头了再降回去。
    Techzero
        31
    Techzero  
       113 天前
    我司也是最近开始统计 gitlab 代码量了,而且要求组长每周抽查一个组员,要求上报发现的问题,经理抽查组长的
    worldqiuzhi
        32
    worldqiuzhi  
       113 天前
    如果去除为了 kpi 故意灌水,大多数情况下是挺合理的。 大多数人的工作又不是发射火箭上天,就是垒砖头,代码行数能决定八成工作量了。

    但这玩意,只能作为领导私下的参考,不能拿到明面上。 你说出来,代码想灌水可太容易了,把成熟的库,全部换成不成熟的 csdn 复制,然后故意写的啰嗦一点,太容易了
    hokori
        33
    hokori  
       113 天前
    @Pony69 #26 这个漫画有意思
    ooee2016
        34
    ooee2016  
       113 天前
    需求分析, 代码编写, 功能测试, 系统维护
    敲代码只是很少的一部分
    duange7X24
        35
    duange7X24  
       113 天前
    上有政策 下有对策;他不仁 你不义
    fredweili
        36
    fredweili  
       113 天前
    @besto 简单的道理就是牛人不屑于搞这种八股的,有本事就换家,所谓难度系数也很难量化
    duluosheng
        37
    duluosheng  
       113 天前
    水代码和注释
    nothingistrue
        38
    nothingistrue  
       113 天前
    @besto #21 严格 review 消耗的成本,是要远大于 KPI 逼出来的工作收益的,这还没算严格 review 本身所需的「编码规范自身的持续改善,和旧编码的持续改善」成本。你这就是说得一本正经,一深入分析就是胡说。
    silentsky
        39
    silentsky  
       113 天前 via Android
    屎山代码看来是避免不了了
    aweim
        40
    aweim  
       113 天前
    那不很好吗;多写写无用的代码。。。
    公司有这样的决策,说明不懂,那你们岂不是更好玩了。
    besto
        41
    besto  
       113 天前
    @nothingistrue 这是大公司和小公司的区别,大公司允许使用一堆庸人,如果你只是优秀一点点,那么另宁用制度把你变成庸人(平均水平),这样便于管理,简单来说,5 个人你搞这套制度就是傻逼,20 个人的团队,你不这么干也能凑合,100 人的团队,不这么干就可能出事情。
    另外大公司的流程是配套进行的,根本不可能只有一套判定逻辑,拿遥遥领先公司的制度举例:
    遥遥领先不仅使用代码量作为 KPI 的一部分,还有如下:
    1. 代码严格 reivew ,每个 team 都有负责人,不可能让你随便造个轮子刷数据;
    2. 项目严格工期控制,文档多久写完,写完文档要评估项目节点,包括 ut st 的时间节点也算上,每个点有没有按时达标,都是考量;
    3. 一堆代码分析静态检查的工具(这个听起来烦人,实际也确实没啥用,但这个部分占比并不多)这个的处理也要算到 2 的工期里的,甚至函数长度太长,函数调用关系过于复杂,层数太多都是要被打回来的,当然不一定改,但要有合理解释;
    4. 质量控制,如果代码合入之后发布了有问题的版本,直接小黑心,今年不可评优;

    大公司很需要制度来运转,否则摸鱼的太多,付出再多的成本也是没办法的。
    zhy0216
        42
    zhy0216  
       113 天前 via Android
    @besto 有同感 大公司里每个人搬好自己的砖 整个公司就能正常运转 想想其实也挺神奇
    zhangqilin
        43
    zhangqilin  
       113 天前
    @www5070504 写单元测试就行了,
    assert value[0] == value[1]
    ......
    写个 20 行
    jim9606
        44
    jim9606  
       113 天前 via Android   ❤️ 1
    drich
        45
    drich  
       113 天前
    跟我一开始在华为的时候一样
    写了多少行代码,处理了几个问题单,开发了多少个需求
    kirito41dd
        46
    kirito41dd  
       113 天前
    多来点代码生成,grpc ,thrift 啥的,上就完了
    nothingistrue
        47
    nothingistrue  
       113 天前
    @besto #41 所以华为的 KPI 有用吗?或者说代码量有参与 KPI 吗?但凡你真在华为干过,你不会说华为 KPI 做得好。
    snowlyg
        48
    snowlyg  
       113 天前
    @scorpion91 老板,领导不是写代码的,谁管你这些。我们老板只要看到我们手没在敲键盘就觉得你在偷懒
    horizon
        49
    horizon  
       113 天前
    可以参考吧,一行代码都不写的混子就现形了
    sky31802
        51
    sky31802  
    OP
       112 天前
    @libook 难不成我们的终极方案是粘贴 spring 源码吗 [狗头]
    pkoukk
        52
    pkoukk  
       112 天前
    interface A { func A()}
    interface B { func B()}
    interface C { A B }
    套呗,别问,问就是充分抽象,灵活组织,充分解耦合
    一个实现类能实现几百个 interface ,你服不服
    pengtdyd
        53
    pengtdyd  
       112 天前
    ChatGPT:请润色一下我今天的代码

    哈哈哈。
    hancai
        54
    hancai  
       112 天前
    多写点 if err!=nill {}
    Lee2019
        55
    Lee2019  
       112 天前
    接入 gitlab-ci 多调试流水线如何
    flyv2x
        56
    flyv2x  
       112 天前
    这个真的是一天 5 ~ 10 个 commit 搞定,feat fix fix
    lifesimple
        57
    lifesimple  
       112 天前
    前端的话 直接就本来 npm 引入的包,直接拿下来放项目里完事了
    pikko
        58
    pikko  
       112 天前
    我们只会作辅助参考,这个本来就只能作为辅助。
    要是作为 kpi 真的不敢想象。
    TAFMT
        59
    TAFMT  
       112 天前
    无论什么工具类,用的时候,自己造一个
    litchinn
        60
    litchinn  
       112 天前
    无脑堆设计模式,一个 new 可以写 10 个类出来,这种考核完全没意义,属于不写代码的领导 yy 出来的考核指标,用什么考察最后就会得到什么。
    楼上也有说辅助参考的,我觉得参考价值都没有,如果一个人不写代码也能完成任务,我觉得也没有任何问题
    ddkk1112
        61
    ddkk1112  
       112 天前
    把用到的包自己复制修改一下
    AnnaXia
        62
    AnnaXia  
       112 天前
    第一次听到这个的时候,作为程序员第一反应是不好,这岂不是会朝着代码灌水的方向发展。但后来领导问,那如果不用这个,你有其他可量化、可考核的指标来衡量程序员的产出么。想了好一会,只能承认这种方式也不能说是完全不合理,只是需要一些补充信息来尽量完善这种考核吧,比如楼上提到的需要代码走查、解决 bug 时的代码行数可引入 bug 难度来综合考虑等
    Excepti0n
        63
    Excepti0n  
       112 天前
    以后不用注解了
    每个 bean 多写点字段
    ly529
        64
    ly529  
       112 天前
    可能快黄了,公司领导已经没事干了
    franktopplus
        65
    franktopplus  
       112 天前 via Android
    我们就在用。老板不懂可以原谅,技术负责人不跟老板解释清楚统计这玩意没有用,不可原谅
    nbndco
        66
    nbndco  
       112 天前 via iPhone
    @besto 华为那代码质量做案例也太不合适了。

    至于这个做 kpi 基本是蠢的没边了。一是想把代码写短是很难的,想把代码写的清晰漂亮更难,但是这些基本都和这个 kpi 背道而驰。二是 test 想写几百行几千行真的和玩一样,你 reviewer 难道还能让我少写几个 test case ?
    SteinsGate
        67
    SteinsGate  
       112 天前 via Android
    我这也有,但是是偷偷搞得,统计脚本是我写的(🐶)
    billccn
        68
    billccn  
       112 天前
    我有一个简单的办法,以遵循 Google 代码风格指南为理由,每周把一行字数限制逐渐下调,直到 80 为止。逐渐调整的理由是可以减少每次影响的行数,避免影响其他同事工作。也可以和同事分工,每周换个人调。

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

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

    希望这个时候傻逼政策已经取消了。
    akira
        69
    akira  
       112 天前
    想起一个好玩的事情。早些年玩花指令的时候,把一行汇编代码扩充成几十几百甚至无数条汇编代码。
    mingl0280
        70
    mingl0280  
       112 天前 via Android
    gcc -E
    x86
        71
    x86  
       112 天前 via iPhone
    利好前端呀
    mkoijnbhu
        72
    mkoijnbhu  
       112 天前 via Android
    多封装些用不到两三次次的函数,问就是层次结构清晰。
    下班前查查今天的行数,不够就抄几个工具类🎉
    fyq
        73
    fyq  
       112 天前
    感觉你们公司要黄了……
    someonedeng
        74
    someonedeng  
       112 天前
    这是冲着倒闭踩死油门。。
    dangyuluo
        75
    dangyuluo  
       112 天前
    挺合理的,我可以一个月写几万行垃圾代码
    AS4694lAS4808
        76
    AS4694lAS4808  
       112 天前 via Android   ❤️ 1
    现在就去一个一个把 lambda 拆了
    jackOff
        77
    jackOff  
       111 天前
    请像一个大四实习生一样装出懵懂无知,不要使用框架了,自己手搓,不要使用装饰器这些简洁高效的东西,要手搓每一个功能的数据库、缓存、内存的连接和释放,自己想办法写一个废话文学版本的代码生成器,慢慢地放弃使用中间件这些东西,重写每一个第三方依赖包,问就是在审核依赖包安全,自己手搓这代码量不是质的飞跃?
    realJamespond
        78
    realJamespond  
       110 天前
    没东西写就写单元测试啊
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2676 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 07:09 · PVG 15:09 · LAX 23:09 · JFK 02:09
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.