V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
hh3755
V2EX  ›  问与答

烂架构的代码是如何最后变好的呢。

  •  
  •   hh3755 · 2015-07-04 11:07:21 +08:00 · 3375 次点击
    这是一个创建于 3429 天前的主题,其中的信息可能已经有所发展或是发生改变。
    不知道大家有没有这样的经历,你当前所做的项目的代码很乱,无架构可言,每天又会有源源不断的新需求过来,参与开发的人并不全是比较牛的人,所以还会补充进去一些烂代码。这样的代码最后如何能变好,或者怎么做才能让这样的代码变得更好。人很少,需求很多,代码比较烂。
    27 条回复    2015-07-05 11:47:54 +08:00
    YouXia
        1
    YouXia  
       2015-07-04 11:08:00 +08:00 via Android
    重构
    hh3755
        2
    hh3755  
    OP
       2015-07-04 11:11:24 +08:00
    @YouXia 人少,需求多。是要抽出一个人来做专门重构吗。如何解决项目进度和重构本身挤占时间的冲突呢。重构如何做呢。专门设计还是调整当前的东西以满足需求,有何准则,或书推荐。
    loading
        3
    loading  
       2015-07-04 11:13:47 +08:00 via Android
    跑起来再说,等你们人走差不多了,项目不能看,自然就“重构”了…
    kn007
        4
    kn007  
       2015-07-04 11:16:34 +08:00
    没有规划是很sb的,以后很难改,牵一发而动全身。。。
    没有规划就如 @loading 所说的,等你们走光了, 这个项目就可以重构了。。。
    gongweixin
        5
    gongweixin  
       2015-07-04 11:18:43 +08:00
    逐步优化,每个新需求多估点时间,每次把周边的优化下,全部重构在公司里不现实
    hh3755
        6
    hh3755  
    OP
       2015-07-04 11:18:49 +08:00
    @kn007 项目刚开始的时候什么情况都有可能发生。我现在接手的项目就有这个问题。重写?有没经验分享。
    hh3755
        7
    hh3755  
    OP
       2015-07-04 11:21:00 +08:00
    @gongweixin 我也觉得可以这样。但是每次新需求,并不是所有人(有新手)都愿意去动哪些容易产生问题的东西,比如重构,一般是怎么处理这种情况的呢。另外遵循怎么样的准则,重构能做得比较好呢。
    loading
        8
    loading  
       2015-07-04 11:21:51 +08:00 via Android
    @hh3755 在一个跑起来的项目面前,首先业务逻辑应该是很清晰的,安排一个最高水平的重构就行!
    hh3755
        9
    hh3755  
    OP
       2015-07-04 11:24:52 +08:00
    @loading 设计架构弄不好就弄巧成拙,大家都是如何提高自己的架构设计水平的呢。目前我只知道*重构*那本书。想顺便把大家的重构水平也提高一下。
    kn007
        10
    kn007  
       2015-07-04 11:25:20 +08:00   ❤️ 1
    @hh3755 如果你确实有时间,而且这个项目老板也不想投入金钱去重构新的。。。
    看下你这个项目,尽量先把这个项目按功能模块化(简单说就是函数汇集),然后看下模块里函数是不是有重复的东西,去掉,有些东西只能顺藤摸瓜,才能搞好。全部弄好后,集成起来就是烂尾的代码了。

    最好一个方向,就是选好个项目的核心,围绕那个核心来模块化。

    就像核心交换机、路由器、无线控制器、防火墙、一堆二层交换机、一堆AP。肯定要以核心交换机为主,其他为辅,来配置规则。
    ZackYang
        11
    ZackYang  
       2015-07-04 11:29:17 +08:00
    <<代码大全2>>, <<重构>>, <<PoEAA>>, <<设计模式>>
    hh3755
        12
    hh3755  
    OP
       2015-07-04 11:33:31 +08:00
    @kn007 谢谢中肯的建议。我也渐渐发现某些东西在原来尚能满足需求,但是源源不断的新的需求进来之后,让原来的架构渐渐的运行起来有些吃力,进而慢慢变成一个大问题。但是需求进来的时候时间往往是不可控的。大家都不能等你把架构改了再做需求。如果是盲目的直接调整架构是有益的。比如觉得哪点就好,需要调整就直接调整。问题就是说 架构哪些,怎么判断哪些需要被架构。
    hh3755
        13
    hh3755  
    OP
       2015-07-04 11:34:15 +08:00
    @ZackYang 谢谢书籍上的推荐。
    initialdp
        14
    initialdp  
       2015-07-04 11:43:56 +08:00
    从来没有见过这种情况下代码最后会变好。
    hahasong
        15
    hahasong  
       2015-07-04 11:49:44 +08:00
    并不能变好,有一天你受不了走人的时候,这事就算完了
    datou552211
        16
    datou552211  
       2015-07-04 13:36:28 +08:00 via iPhone
    赶紧重构,要不然恶性循环,甚至影响产品质量
    Felldeadbird
        17
    Felldeadbird  
       2015-07-04 15:11:36 +08:00   ❤️ 1
    我给楼主一些建议:
    1.先明确目前项目是否公司核心。核心项目不是你说重构就重构的,
    2.核心项目如何重构?最好就是在开发某些大功能时,偷偷加入自己的设想架构。但是未必凑效。我就试过这样做,而且很快就失败了。因为该改动的需求流产了,我做的重构也没了。
    3.是否有相同的新项目开发。老板可能会让你使用现有的程序直接修改过去。把握这个时机,强烈向老板推荐重构或者自己有权利进行重构。 我现在就是走这样的路线。在新项目用新架构,待新项目成熟了,就淘汰掉旧项目的旧架构,使用新架构。
    4.旧项目如何处理?有一个过渡期,楼主可能需要投入第一时间进行维护的。所以做好觉悟吧。
    这玩意其实吃力不讨好,因为整个团队里面,不是每个人都有重构的思想。
    kn007
        18
    kn007  
       2015-07-04 15:17:25 +08:00
    @Felldeadbird 这种处理方式好,哈哈,也挺无奈的
    vietor
        19
    vietor  
       2015-07-04 15:25:00 +08:00 via Android
    逐步分拆独立模块
    hohoho
        20
    hohoho  
       2015-07-04 15:28:37 +08:00 via iPhone
    也遇到了楼主的问题。公司的 iOS app 找的外包,我接手时看了代码都快哭了。新需求很多,没人没时间重构,领导关心的是功能,跟老大提出来老大也很无奈,完全推倒重写是不可能的。

    能做的就是边加新功能边力所能及地修改重构原来的,这个过程好蛋疼。到现在也重写了近三分之一啦,希望最近的需求忙完能稍微空闲些,至少把tm的那一坨storyboard都删了!
    Keinez
        21
    Keinez  
       2015-07-04 17:49:52 +08:00
    Clarencep
        22
    Clarencep  
       2015-07-04 17:58:21 +08:00
    难道不是代码越来越烂,快要无法维护的时候,干脆起个2.0版本,重写一遍...
    2.0也越来越烂,要无法维护了,老板终于下定决心搞代码质量,起个NG(next generation)版本,要狠抓代码质量...
    NG版本依旧越来越烂, 干脆起个3.0版本继续重写吧...
    hh3755
        23
    hh3755  
    OP
       2015-07-04 21:04:50 +08:00
    @Felldeadbird 对于第2点。关键是我们在不断的在原来的功能上加需求。越加越乱,不重构似乎已不可能。时间上的确很紧张。很多时候花了很多时间,结果新重构的功能比原来的功能不稳定还引来怀疑改动的价值。 对于第3,4点,公司只想把代码跑下去。重写一个新版本根本不是产品能提得出来的需求。也不会有那么多时间。也同意不是每个人愿意重构。
    hh3755
        24
    hh3755  
    OP
       2015-07-04 21:33:44 +08:00
    @datou552211 是否有重构的经历可供参考。其实现在比较迷茫。
    mouhong
        25
    mouhong  
       2015-07-04 21:39:24 +08:00
    重构,小步慢进。一般情况下不要想着重写,在很多时候,重写要么是写不完,要么是写完不见得比原来的好
    mouhong
        26
    mouhong  
       2015-07-04 21:44:48 +08:00
    不过,你是项目负责人的角色么?要是,那或许可以先争取让上层认同重构的重要性,再通过一些制定一些规范让其它开发人员来遵循,定期做些 Code Review?要不是,那貌似就比较纠结了~
    hh3755
        27
    hh3755  
    OP
       2015-07-05 11:47:54 +08:00
    @mouhong 也不算是,只是项目不大,搞着项目好乱,想看看大家一般都是怎么把它搞好的。交流学习一下。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2824 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 02:48 · PVG 10:48 · LAX 18:48 · JFK 21:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.