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

如何管理历史悠久,几经易手的代码?

  •  
  •   cassidyhere · 2021-01-25 10:31:09 +08:00 · 3822 次点击
    这是一个创建于 1158 天前的主题,其中的信息可能已经有所发展或是发生改变。

    公司一个将近 20 年的 mfc 项目,体积庞大,没人能全懂。公司要求每次修改都要注释作者 /时间 /修改内容,由于人员水平参差不齐,导致注释完备但代码难懂。部分文件几经变迁,混杂着各种业务代码与黑魔法,例如几十行的逻辑判断,旁边有各年代留下的为什么加这个判断的注释。 请问有什么方案可以管理代码的变更,优雅的反应代码如何到今天这样子,而只需对代码做最少的更改?

    kiracyan
        1
    kiracyan  
       2021-01-25 10:33:58 +08:00
    别动
    caijihui11
        2
    caijihui11  
       2021-01-25 10:35:24 +08:00
    别动
    kaiki
        3
    kaiki  
       2021-01-25 10:36:03 +08:00
    不要管理,新功能就用新代码,出 BUG 找不到负责人就把这部分重新写一个。
    kop1989
        4
    kop1989  
       2021-01-25 10:38:16 +08:00
    这个很难。
    1 、注释有可能不正确,也有可能过期。
    2 、代码中的逻辑未见得都有效。

    你很难通过简单规则来把代码变更的历史追溯起来了。
    所以你需要做的是确保当前版本可用。然后引入版本管理软件。
    BeautifulSoap
        5
    BeautifulSoap  
       2021-01-25 10:40:53 +08:00   ❤️ 1
    「不要乱动!不要乱动!!不要乱动!!!」
    ltm
        6
    ltm  
       2021-01-25 10:41:24 +08:00   ❤️ 1
    公司认可:用 C#重写一个;

    否则,别动,继续加屎,知道大厦崩塌

    我也曾经在屎山上实践过《重构》的,但是,真的不如推倒重来
    nicevar
        7
    nicevar  
       2021-01-25 10:42:53 +08:00
    不要乱动,这是真理,特别是线上跑了很多年的项目
    总有些人有代码洁癖又盲目自信,结果弄出大故障的
    murmur
        8
    murmur  
       2021-01-25 10:45:09 +08:00
    除非出现了导致系统不能运行的 bug,千万不要动
    bfdh
        9
    bfdh  
       2021-01-25 10:48:20 +08:00
    交给下一任管理者?
    Aaronsunny
        10
    Aaronsunny  
       2021-01-25 10:51:09 +08:00
    不要乱动
    fixend
        11
    fixend  
       2021-01-25 11:02:40 +08:00   ❤️ 1
    1 、大部分人的选择都是别乱动,新功能用新代码,
    然后,后面会陆续出现,同样 /类似功能的函数会有 N 个,
    甚至同样意义的常量也有 N 个,有一大堆无用或不明意义的代码,
    总的来说,代码会退化得越来越严重。

    2 、从公司的角度来看是不好的发展,从程序的角度来看:关我鸟事,我能完成上面安排的需求就得了。

    3 、最好是进行大规模重构、重写,但多数公司都不会支持,风险也很大,新版本不一定就做得比旧的好。
    yanzhiling2001
        12
    yanzhiling2001  
       2021-01-25 13:39:32 +08:00
    投个硬币,正面重构,反面不动。没有硬币投个手机也行
    MaverickLee
        13
    MaverickLee  
       2021-01-25 13:43:43 +08:00   ❤️ 1
    继续往上拉屎
    wolfan
        14
    wolfan  
       2021-01-25 14:02:56 +08:00 via Android
    当没见过,只要你没见过,那就不存在!
    zsc8917zsc
        15
    zsc8917zsc  
       2021-01-25 14:08:54 +08:00   ❤️ 2
    参考一下 oracle 的维护。
    不要相信注释,要相信自己的调试。
    如果想重构,那就先维护好测试用例。
    wmhx
        16
    wmhx  
       2021-01-25 14:13:04 +08:00
    20 年累计的注释, 代码逻辑早就不是那么回事了, 还是等钱到位了刚一波吧.
    NexTooo
        17
    NexTooo  
       2021-01-25 14:24:19 +08:00
    别动。你不会知道这一句看着毫无意义且让人难受的垃圾代码,是为了哪个问题而存在的。。
    firefox12
        18
    firefox12  
       2021-01-25 14:25:22 +08:00
    如果有能力 把 20 年的屎山理得干干净净 清清楚楚 你就去做, 考虑下, 所有的 业务需求是否清楚,所有用例是否完备, 所有的依赖是否到位, 你要花多少时间?
    AndyAO
        19
    AndyAO  
       2021-01-25 14:27:18 +08:00
    如果你要做很大的改动,那么最好的方法是不要动而选择重新写,因为动的成本比重新写可能要高很多.

    这个临界点好像是在 10%~20%左右,这是在软件工程的书上写着的.

    当然这不意味着完全抛弃之前的东西,里面有很多的设计的理念是可以通用的,是可以迁移的,这些东西要学会.

    如果你已经决定进行比较少的改动,那么在要逐步的建立起相关的测试和文档,如果有这些东西,那么就会容易很多.
    AndyAO
        20
    AndyAO  
       2021-01-25 14:33:08 +08:00
    @AndyAO #18
    回去查证了一下,发现记忆有些偏差,这里补充相关资料

    **关于修改和重写的临界点问题**

    有关软件错误和软件成本的研究都证实了这一基本事实。本书中反复提到了 NASA-Goddard 所属的 SEL 。SEL 曾详细比较了修改旧代码和完全重写所需的成本问题( McGarry 等,1984 ; Thomas1997 )。他们的结果清晰明确,给人深刻的印象。如果现有软件系统的 20%~25%以上需要修改,那么从头构建新产品更便宜、更容易。这个百分比低的惊人。[1]

    **关于遗留代码与单元测试**

    在业内人士的口中,“遗留代码” 一词常常是"无法理解的、难以修改的代码”的代名词。然而,在多年来与形形色色的开发团队共事,并帮助他们解决重大的编码问题的过程中,我总结出了一个不同的定义。对我来说,遗留代码就是那些没有编写相应测试的代码。明白这一点是很痛苦的。人们会问,代码的好坏与是否编写了测试有什么关系呢?答案很明显,而这也正是我将要在本书中阐述的:没有编写测试的代码是糟糕的代码。不管我们有多细心地去编写它们,不管它们有多漂亮、面向对象或封装良好,只要没有编写测试,我们实际上就不知道修改后的代码是变得更好了还是更糟了.反之,有了测试,我们就能够迅速、可验证地修改代码的行为 ...

    开发团队的水平在不断提高,他们编写的代码也变得越来越清晰,然而旧代码要想变得更清晰就要花更长的时间。许多情况下旧代码甚至永远都不可能变得完全清晰。正因如此,我将“遗留代码”定义为“没有编写测试的代码”,而且它本身就提出了问题的一条解决方案。...[2]


    [1]〔美〕 RobertL.Glass. 软件工程的事实与谬误[M]. 中国电力出版社, 2006.
    [2] 修改代码的艺术 : Working effectively with legacy code[M]. 人民邮电出版社, 2007.
    xuanbg
        21
    xuanbg  
       2021-01-25 16:07:45 +08:00
    萧规曹随即可……这种场景就别多事了。
    Flymachine
        22
    Flymachine  
       2021-01-25 16:56:52 +08:00
    别动,重新写。有的时候,甚至编译环境的不同都可能引发 BUG 。最好的方案就是重新写——换 QT 或者干脆 C#。
    boris93
        23
    boris93  
       2021-01-25 17:14:31 +08:00 via Android
    继续拉屎就好了
    直到公司决定重写
    leafre
        24
    leafre  
       2021-01-25 17:47:03 +08:00
    老代码能不动就不动
    gengzi
        25
    gengzi  
       2021-01-25 17:57:03 +08:00
    别动
    shatuo
        26
    shatuo  
       2021-01-25 18:13:36 +08:00
    @yanzhiling2001 这是换手机的好方法
    huobazi
        27
    huobazi  
       2021-01-25 18:56:39 +08:00
    想把 摩托罗拉 汉显 重构成 iPhone 12 ?
    littiefish
        28
    littiefish  
       2021-01-25 22:39:53 +08:00 via iPhone
    终于明白了为啥 APP 越来越大
    fline
        29
    fline  
       2021-01-25 22:40:34 +08:00
    找 HR 要个实习生处理
    DoctorCat
        30
    DoctorCat  
       2021-01-25 23:01:50 +08:00
    不要动,加 Patch,FIXME 注释写下自己的修改思路即可(方便自己再次修改而已,doge )
    dany813
        31
    dany813  
       2021-01-26 09:21:07 +08:00
    看到老哥们都说别动,我就放心了
    kingfalse
        32
    kingfalse  
       2021-01-26 09:41:13 +08:00 via Android
    同意楼上继续拉屎,啥时候不行了就会变成印度那个航母,因为屎而爆炸
    gaoyadianta
        33
    gaoyadianta  
       2021-01-26 09:56:08 +08:00
    首先,并不一定历史悠久,几经易手,体积庞大,就一定是 shit 代码,可能是你对老的 coding 习惯不适应,也可能是你对业务理解不深入,反正不要盲目自信瞎改
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2720 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 15:31 · PVG 23:31 · LAX 08:31 · JFK 11:31
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.