V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
whi147
V2EX  ›  程序员

大公司的核心项目代码也不是那么美好(c++)

  •  1
     
  •   whi147 · 59 天前 via iPhone · 9977 次点击
    这是一个创建于 59 天前的主题,其中的信息可能已经有所发展或是发生改变。

    不同的页面,相似的功能,没有抽象全是复制粘贴。想改成模版元编程或者二级指针抽象,发现又不是完全复制,都是把结构体换了个名字复制,二十几个文件顿时丧失优化兴趣。反正能跑就跑算了

    94 条回复    2021-02-22 09:03:48 +08:00
    yamatamain
        1
    yamatamain   59 天前
    大公司的项目,没有几个是从技术层面看起来过得去的。
    毕竟是“大公司”的项目。
    你想通了吗?
    paoqi2048
        2
    paoqi2048   59 天前   ❤️ 1
    又不是不能用.jpg
    DoctorCat
        3
    DoctorCat   59 天前   ❤️ 1
    代码质量堪忧 !== 不能赚钱嘛 😂
    wellsc
        4
    wellsc   59 天前   ❤️ 1
    不要去动屎山
    Mrun
        5
    Mrun   59 天前
    别想不开啊
    bthulu
        6
    bthulu   59 天前   ❤️ 15
    复制粘贴再修改一下难道不是最简单的吗? 万一以后要什么功能, 直接怼代码上去就行了. 你给抽象一下, 万一后面改功能, 你这个抽象不支持怎么办? 别总以为代码简洁就是美, 美则美矣, 却丧失了各种可能, 又有什么用?
    lovecy
        7
    lovecy   59 天前   ❤️ 4
    复制粘贴再修改,付出的是人力成本,请几个应届生搞定。
    抽象封装搞优化,付出的是脑力成本,找个高手费钱费力
    whi147
        8
    whi147   59 天前 via iPhone
    加了一个算法,要修改二十几个文件
    whi147
        9
    whi147   59 天前 via iPhone
    想起以前在小公司两个人干活时,那个轻松啊。花了三个月根据业务逻辑重新开发了客户端。用了十分之一的代码完成了所有功能还增加新的功能。
    nicevar
        10
    nicevar   59 天前
    初次进入大公司的感觉么。。。十几年前我几个同事也是这样评价公司的项目的,隔几年进来的小弟也是这样评论他们的代码的
    whi147
        11
    whi147   59 天前 via iPhone
    @nicevar 哈哈。后浪前浪都死在沙滩上
    mxT52CRuqR6o5
        12
    mxT52CRuqR6o5   59 天前   ❤️ 7
    抽象得好是需要很高的水平的,抽象不足够好有可能还不如复制粘贴呢
    chuckzhou
        13
    chuckzhou   59 天前
    大公司也是从小公司成长起来的,总不能公司大了就把所有代码重构吧,而且代码的稳定性是第一位的。
    sakura1
        14
    sakura1   59 天前
    @wellsc 屎山可太贴切了
    hxndg
        15
    hxndg   59 天前
    这种现象到处都有,很正常
    我现在就在重构原先的代码,只不过我们这个是 C,重构更蛋疼
    northisland
        16
    northisland   59 天前   ❤️ 1
    dont repeat yourself 有时候只是一句放哪儿都对的口号,什么水平的人都可以这么说

    建议从业务初衷去理解一下工程
    laragh
        17
    laragh   59 天前
    @yamatamain 营销号嫌疑
    northisland
        18
    northisland   59 天前   ❤️ 4
    某些概念可以在组内轻易推广时,把概念封装成执行单元,don't repeat,我觉得 ok 。

    为了 don't repeat,而生硬地造处一堆概念,我觉得污染了代码的可读性、可维护性。
    icyalala
        19
    icyalala   59 天前
    不如说越是大公司的核心代码,屎山越高。
    大公司新项目,兴许还能有好一些的代码。
    yamatamain
        20
    yamatamain   59 天前
    @laragh ???三连
    lwch
        21
    lwch   59 天前   ❤️ 1
    曾经见到过一个函数写了 2000 多行
    zhuangzhuang1988
        22
    zhuangzhuang1988   59 天前   ❤️ 3
    别想不开, 我这几天写前端打算抽象页面的, 给 2 个项目用
    尼玛折腾了 2 天还是各种报错,
    直接拷贝修改 2 小时解决
    anthow
        23
    anthow   59 天前
    这是什么代码,改下吧 ×
    算了算了,能跑就完事 √
    RickyC
        24
    RickyC   59 天前
    人类素来远离智慧。
    bojackhorseman
        25
    bojackhorseman   59 天前
    ericgui
        26
    ericgui   59 天前   ❤️ 6
    这是我以前的微博,我再发一次:

    ==============

    虽然轮子哥 @GeniusVczh 非常推崇 DRY 原则,但是,在某些人那里,DRY 就是个灾难,因为他没有足够的抽象能力,DRY 出来的东西就是一堆狗屎,然后每次要加新功能,就彻底重写一次;或者是每次加新功能,都要打一堆补丁,然后你发现,补丁摞补丁,终于又成了一堆屎山。 ​​​​

    ================

    抽象过度是个问题
    抽象不足也是个问题
    抽象能力决定了你的抽象的普适性
    ericgui
        27
    ericgui   59 天前
    @lwch 我们一个 UI 的 container,1300+行
    knightdf
        28
    knightdf   59 天前
    没人会跟钱过不去
    jones2000
        29
    jones2000   59 天前
    抽象意味着, 需要有人维护底层的抽象类, 后期抽象类增加功能或修改, 需要把所有用到这个抽象类的项目或页面都要测试一般。 换成你, 你会干吗? 出来问题还要背锅。
    IsaacYoung
        30
    IsaacYoung   59 天前
    xxx.page 8000 行
    yuzhibopro
        31
    yuzhibopro   59 天前
    写什么模式抽象,业务不需要,理解起来麻烦,还不如堆代码。快速出活,远离 996
    jones2000
        32
    jones2000   59 天前   ❤️ 2
    @ericgui 预算充值,不考核,人手充足,工期充裕(设计,写注释, 重构这些也算入到工期内)。 是可以抽像的。
    抽象这个东西是根据项目的开发中动态调整的。

    ”抽象过度是个问题
    抽象不足也是个问题
    抽象能力决定了你的抽象的普适性” 你说的这个就是没有在开发中动态的去调整抽象设计,前期的抽像设计可能在开发中需要调整, 前期的抽象是基于对项目的理解和过往的经验得到的,谁也不知道在具体在开发中会遇到坑,还要考虑产部隔三差 5 加新需求, 这些都需要根据具体情况和应用调整抽像的设计,这些都可能导致前面的代码都是重写,工作量巨大。 如果没有对项目或编程有极大的爱好的人是不会这么干的。 毕竟大家都是打工的。东西能跑就可以了。
    matrix67
        33
    matrix67   59 天前
    腾讯吃鸡游戏有两个团队在开发,字节 clubhouse 的应用有 5 个团队在开发,你看老大层面的的 don't repeat 也没实现。
    taogen
        34
    taogen   59 天前
    先复制粘贴实现,以后再优化,然而以后就不想优化了。所以,在代码提交之前保证代码是优化过的。但有时候,需求比较急,也就专注于快速实现,没时间去考虑代码质量了。然后,根据破窗理论,代码会有越来越多的屎山。
    Lemeng
        35
    Lemeng   59 天前
    有句俗语怎么说来着,不过也不是绝对的事。企业文化很重要
    levelworm
        36
    levelworm   59 天前 via Android
    其实就是业务繁忙的时候赶业务,想着先做了之后优化。之后就没有时间优化了。再加上几年走一批人,后面来的能把功能顺利跑出来也不错了。这咋听起来还是网络后台程序?
    rodneya
        37
    rodneya   59 天前
    现在的项目 重复代码就有一堆。。。组长说有空重新合并一下。。。
    newmlp
        38
    newmlp   59 天前
    核心就是无数人堆起来的屎山,轻易不敢动的那种
    newmlp
        39
    newmlp   59 天前
    @lwch 我见过 5000 行的,
    php01
        40
    php01   59 天前
    这些楼层太搞笑了。
    我真想知道,如果是一个小公司,这样做,楼上这些人又会怎么说。想想都要笑出猪叫
    sillydaddy
        41
    sillydaddy   59 天前 via Android
    成本大于收益,所以不抽象。

    可能抽象后的代码扩展性不强。
    可能别人理解起来会困难。
    可能抽象所需时间比较长。
    可能这些代码仅仅是局部的,无关全局。

    即使是涉及到架构方面的代码,还有一个权衡利弊,判断是否要重构的过程。何况其他的代码呢!
    TimRChen
        42
    TimRChen   59 天前
    @bthulu 什么都不做肯定是没问题的,敢于尝试的都是错的。doge
    atonku
        43
    atonku   59 天前
    大公司的核心业务又不是优化代码!他们首先定一个高工资,让小公司的社畜不停的骚动,然后制定一堆自己都不执行的乱七八糟的标准,去拖小公司的后退。这就是核心业务
    paradoxs
        44
    paradoxs   59 天前   ❤️ 1
    上次公司来了个新人,写的代码,一些基础的东西封装的挺好的。

    我秒懂了,这人是培训班出来的。

    真的自学科班出身,哪有这样封装的,都是能用就行。
    dwSun
        45
    dwSun   59 天前
    @atonku #43 这就是 google 在干的事情,所以我一直觉得要远离 google 的产品
    beichenhpy
        46
    beichenhpy   59 天前
    不写第三方框架很少用到抽象封装或者设计模式吧。。最近学了一些,感觉都很抽象
    quceng
        48
    quceng   59 天前
    哪个大公司啊?
    lakehylia
        49
    lakehylia   59 天前
    首先完成需求,拿到 KPI 。然后再重构,缩小代码大小,又拿到 KPI 。接着继续完成需求,循环往复。有 KPI 就有重构得动力,没有就没人愿意动。
    firefox12
        50
    firefox12   59 天前
    XML 倒是抽象 复杂,你们怎么都去用 json ?口嫌体正直。

    每一座屎山都是一段历史,没有经历过的人 真的没资格去评论。
    chendl111
        51
    chendl111   59 天前
    能用就行.jpg
    whi147
        52
    whi147   59 天前 via iPhone
    @atonku 厉害
    whi147
        53
    whi147   59 天前 via iPhone
    @quceng 安防行业
    coolesting
        54
    coolesting   59 天前
    能运行就不重构,否则,你会无限地加班 !!
    shm7
        55
    shm7   59 天前
    "没有抽象全是复制粘贴"
    相信我,有时候完全以 DRY 为代码规范来写的,一样有阅读的问题。

    “不同的页面,相似的功能” 假如页面变化较大,一个页面要改一个 小组件来实现,一个不要改怎么搞?

    也许这么写是比较好读又好改的折中方案呢。
    zjl03505
        56
    zjl03505   59 天前
    @whi147 #53 你说到安防行业,行业领头的那两三个确实远远比不上一般的互联网大公司。
    whi147
        57
    whi147   59 天前 via iPhone
    @zjl03505 对啊,写的也不是很舒服
    mapoor
        58
    mapoor   59 天前
    如果核心代码抽象做的不好,那依托以此的产品可想而知,必定没有任何竞争力。
    你说的核心代码真的是核心吗?
    Avedge
        59
    Avedge   59 天前
    毕竟很多历史因素,改改说不定就扯出一堆新问题。
    whi147
        60
    whi147   59 天前 via iPhone
    @mapoor 这个项目是多项目结构,也就是有 100 多个 dll,我就在其中一两个里写,有的代码封装的很好,有些代码不是
    stevenkang
        61
    stevenkang   58 天前
    优化大厂的项目,代码也不算多 14w 行左右,硬是把 sonar 扫描出来的中、高级缺陷都给消灭掉了,剩余低级缺陷不足 20 个,之前有不低于 500 多处不规范代码。

    优化的过程其实对企业产生不了效益,反而增加测试同学的负担,优化的时候都是非常谨慎,生怕影响原来的代码逻辑。

    现在看来,优化代码前,还是得先从单元测试入手,一步一步让屎山变为金山银山吧。
    hxndg
        62
    hxndg   58 天前   ❤️ 1
    @paradoxs
    噗,如果这样子说的话,你像我司是三个人定好标准,只求简洁和清楚:把 OPENSSL 库封装好,然后提供各种级别调用,我们都是培训班出身呗。。。。
    @northisland
    从工程实践的角度有道理,
    但是有的地方还真是追求强行一致性,比方说 linux 内核里面的 list_entry,page_struct 里面的 mapping 还有就是 openssl 里面的一大堆地方都是强行追求一致性

    @ericgui
    实际上都是先有的重复,然后才有的抽象。
    jsjgjbzhang
        63
    jsjgjbzhang   58 天前
    打江山阶段和坐班阶段能一样么
    tailf
        64
    tailf   58 天前
    代码是写给人看的,只是恰好能运行。
    OliverDD
        65
    OliverDD   58 天前   ❤️ 1
    我觉得,这只是工作,你写得再好看优美,客户看不到 boss 看不到,代码除非别人接受不然没人看得到。有那个想法爱好,课余时间去贡献贡献开源代码,那才是该写优美的地方。工作就是工作,目标驱动,何必为难自己为了设计去设计
    xumng123
        66
    xumng123   58 天前 via iPhone
    沟通成本极高,所以能不改就不改,将就能用即可
    owenliang
        67
    owenliang   58 天前
    打江山的代码,收益远大于表面文字
    going2think
        68
    going2think   58 天前 via Android
    .想搭车问一下大家,c++稍微大型点的项目规范文档哪里有呢,最近在写一些 c++项目,总感觉很不规范,想找一些文档参考一下
    imzcc
        69
    imzcc   58 天前 via Android
    我们公司一个 typeapi 有 7.8m ,惊了
    imzcc
        70
    imzcc   58 天前 via Android
    @imzcc Java class
    timsensor
        71
    timsensor   58 天前 via Android
    一切跟业务走,否则谁都不知道你干了什么
    newmlp
        72
    newmlp   58 天前
    @going2think 随便写,有没有规范都一个样 [手动滑稽]
    shayuvpn0001
        73
    shayuvpn0001   58 天前   ❤️ 1
    @going2think 可以参考 Chromium 的文档,我觉得还是不错的。如果本身底子不好,人员水平又参差不齐,建议还是尽量用 Qt 这种框架,给你一个比较好的模式和舞台。

    还有一些项目虽然很有名也很厉害,比如 Linux 内核的,其实不建议参考,一是为了尽可能保证效率各种骚操作多,二是历史包袱也是有点重的。
    jorneyr
        74
    jorneyr   58 天前
    IBM 的 Domino, 其中有一个 cpp 文件超过 10M,Notes 的一个核心函数 1 万多行。
    melkor
        75
    melkor   58 天前 via iPhone
    @whi147 小公司业务和大公司业务的复杂度和历史包袱不可相比吧
    AndyAO
        76
    AndyAO   58 天前
    成熟的思考,极高的可读性,走到极致就应该是文学编程。
    自从这个概念被高德纳提出并且实践以来,当前属于文学编程的低潮阶段,它比任何时候都冷。[^1]
    有很多好东西是被重新发现的,所以这不排除这是未来,毕竟,对项目的质量和可维护性应该有很大提升。

    [1]: Whither Literate Programming (1)/(2)/(3).
    AndyAO
        77
    AndyAO   58 天前
    还有就是,很好奇你说的具体是哪个「大公司」,「大」是个很模糊的词汇,如果看市值和知名度的话,可口可乐算是很大的公司,但保不齐他们的某个 IT 项目做得非常烂。
    abcbuzhiming
        78
    abcbuzhiming   58 天前
    记得在别处看到过,google 的搜索引擎有个核心程序是 C++写的,编译出来得到的可执行文件高达 1GB ;以至于编译时的 GCC 超出内存占用,以至于那个开发组不得不魔改 GCC 来完成编译。

    我个人觉得,抽象也好,各种设计模式也好,过于学术,过于完美。而现实不是完美的,所以现实的东西总是看起来这里有缺点,那里有缺点。所以我觉得,程序员尤其不能处女座
    chenqh
        79
    chenqh   58 天前
    @paradoxs 你这在黑谁呀?怎么感觉都黑了
    chenqh
        80
    chenqh   58 天前
    @abcbuzhiming 谷歌不都是 128G 内存的吗,还会内存溢出?
    jianghu52
        81
    jianghu52   58 天前   ❤️ 2
    说一下个人经历,接手一个小项目,不到 7 千的代码,最核心的代码超过 1 千行,写在一个文件的一个函数里面,光参数就 20+,还很多都是结构体。
    这样的一个结构,领导给的时间只有一周,如果按照式样书做,就是结构体追加两个变量,然后在参数的 600 多行的位置,再追加两个判断,就能完事儿。测试也很简单,只要测试这一个结构体相关的内容就可以了。
    当时年轻,总觉着自己能改变现状,于是业余时间花了快两个月的时间,自己重构这个函数,把他拆成六个相对独立的函数,同时还做了两个接口,用于外部调用。然后拿着这个解决方案给领导,本以为会受到表扬,结果被训了一顿。
    领导的意思:首先,我做的拆分没有实际的根据,完全是根据现有代码逻辑来的,对于以后的业务完全没有扩展。其次,这样的拆分对于客户来说,风险远远大于收益,核心函数这样大的变化,客户的 sku 超过 2 千个,每个都要测试,但是收益只是维护的便利性增加了一点点。最后,函数级别的解耦,通常只能解决部分问题,如果要做,那么应该从整体结构就开始做解耦,单做一点,费力不说,而且效果很小。
    通常历史悠久的公司,往往烂代码更多。一方面是因为当时的编程者的只是结构就是老的,一方面也是因为当时的设计根本不可能完全适合未来的变化。但是业务有时候会剧烈的变化,可是代码受限于当时的结构,就不可能剧烈的变化,于是开始有了补丁。也是技术债的产生根源。
    作为程序员,在我们眼中,程序的质量高于一切。但是在商业社会,商业活动最终是利润说话的。假设一个 60 分的代码,可以提前 3 个月面世,并且每月能获得 100 万的收益,并且每月他的维护费用为 10 万,一个 90 分的代码,要晚 3 个月面世,同样收益为 100 万,每月维护费用为 1 万。你觉得你是老板会选哪个。
    zhc
        82
    zhc   58 天前 via iPhone
    看回复就看得出靠写代码混饭吃的还是占绝大多数。很难体到编程带来的快乐。大公司的通病说白了就是随着人员增多代码爆炸,复杂度太高的问题。好好看看英文原版的代码大全,人家早就总结出了很多经验。
    edimetia3d
        83
    edimetia3d   58 天前
    开源项目要 PR,算是脸面..

    内部项目你代码质量写的好是能反向 PUA leader 吗?
    geektony
        84
    geektony   58 天前
    其实这是一个恶性循环:管理层要求短时间出成绩 -> 没有充分思考的产品决策 -> 不充裕的开发周期下的技术架构与决策 -> 坏味道代码 -> 产品没有不符合管理层预期。

    要打破这个循环,要改变的是管理层的思维和决策方式还有自顶而下的协作方式。在大厂这部分基本都比较固化,前线员工是无法改变体制的。这是出现的 side-effect 就是,前线员工一边骂着老板傻逼,一般要加班加点干出实现逻辑,各种技术决策开始折中妥协。后来加入的人又再循环,“在屎上面继续拉屎”。

    回到管理层的问题,其实是企业文化的反应,而企业文化又不是一时半刻形成的,更不可能被前线员工,甚至中层管理者可以撼动的。如果你能忍受,可以继续待下去。如果不能,那就找适合自己的环境。

    这样看来,我们的编码规范、原则和思想都可以通过人和时间完善。但是在冰山下隐藏的,本质上不是技术问题,而是协同与管理的问题。
    CastleBUPT
        85
    CastleBUPT   58 天前 via iPhone
    楼上们说的抽象不足的 DRY 是啥意思啊,重复代码又是怎么保证甚至提高抽象性的啊,我怎么看不懂你们说的,去哪儿能买到你们的著作?就问一件事,如果业务改动导致要在重复代码中间加一行,你们打算怎么做啊,是找到所有重复代码然后粘贴这一行吗?
    ericgui
        86
    ericgui   58 天前
    @abcbuzhiming 我是处女座
    chinuno
        87
    chinuno   58 天前 via Android
    同样安防写 c 艹的说说我的想法吧。新旧项目都做过,发现代码越来越烂是必然的结果。
    一开始架构设计一般来说问题都不大,都是最切合立项时的需求的,一般设计上的问题在第一个版本做出来的时候不太还会存在了。
    问题出在项目的后续需求演变,首先公司的人员流动性很高,项目的维护者没多久就要换一批。前期架构不管设计得多好这个时候就要看接手人的水平了。能够理解一开始设计架构的思路跟着做下去就很好,这种情况最舒服了,有问题好改好排查,结构清晰节省时间。水平不够的对不上架构电波的就自己发挥随便乱拉屎了,从这个时候开始整个项目就被屎污染了,后面维护的人只能跟着继续搅屎。这两种情况我都遇到过,真的是最真实的体验了。
    再一个问题是客户端需求奇葩。安防行业的客户专业的很专业,不专业的就。很任性,一定要你照他说的做,特别强硬。经常会出现毫无意义浪费资源,但是客户坚持要的功能。这种奇葩需求前期设计的时候是根本无法预见到的,所以为了应付客户只能跳出框架挂个屎包补丁。
    不说客户端奇葩需求,正常需求也很麻烦。同样一套系统对不同用户都要做不同的定制,这些修改往往都是不通用的不好抽象的。这样导致的情况就是一个定制版本就是一套系统复制粘贴稍作修改,看起来大部分东西都一样,但是就是抽象整合不出来。
    其实就我感觉行业内的东西都是一样烂,天天跟友商做对接感觉就很明显了,都是系统天天出问题,从来没有稳定过。不是公司核心业务也根本不会投入资源去给你做重构的,能用就行。
    Cbdy
        88
    Cbdy   58 天前 via Android
    瞎抽象不如不抽象,现在很多程序员都是干苦力,软件能跑能赚钱就行,要啥自行车
    whi147
        89
    whi147   58 天前 via iPhone
    @chinuno 现在客户都反馈界面 ui 比几年前慢,可以看出第一版时期的开发者还是有考虑用户体验的,后面出现国际化版本(多个国家)后人员激增,就破坏原有设计了
    dorothyREN
        90
    dorothyREN   58 天前
    大公司要突出一个大字啊,不复制粘贴怎么能体现出来呢
    JoStar
        91
    JoStar   58 天前
    之前看过一篇文章,也是关于代码简洁问题的

    出自 react redux 核心开发者的文章
    https://overreacted.io/zh-hans/goodbye-clean-code/

    代码简洁这个问题,还是要找一个平衡点,要抽象也要解耦。
    jinsongzhao
        92
    jinsongzhao   58 天前
    吐槽归吐槽,调侃归调侃, 娱乐过后, 是一地鸡毛, 还是像钱学森的故事一样, 放下国内远远达不到精度的工艺, 依旧实现了目标. 工程本来就无法完美,再完美的理论也要适配精度.
    l00t
        93
    l00t   57 天前
    @zhc #82 编程有啥快乐的。程序员的快乐是创造,不是书法。创造体现在产出新的能做到什么什么的产品,而不是怎样写出一个产品。
    bthulu
        94
    bthulu   57 天前
    @CastleBUPT 是的, IDE 中正则搜索添加, 不到一分钟搞定
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3482 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 08:32 · PVG 16:32 · LAX 01:32 · JFK 04:32
    ♥ Do have faith in what you're doing.