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

开发前的设计要怎么保证扩展性呢,感觉怎么设计都赶不上突然的变化

  •  
  •   Renco · 2021-04-28 10:56:44 +08:00 · 3937 次点击
    这是一个创建于 1287 天前的主题,其中的信息可能已经有所发展或是发生改变。

    每次设计时,都要求要考虑好未来的扩展性。结局就是要么没有未来,要么未来也全部推翻

    33 条回复    2021-04-29 19:20:14 +08:00
    SaltyLeo
        1
    SaltyLeo  
       2021-04-28 11:08:49 +08:00
    一开始就模块化,未来扩展就扩展组件横向扩展,会很方便。
    shyangs
        2
    shyangs  
       2021-04-28 11:18:33 +08:00
    問問 PM 未來的展望. PM 和老闆不給力. 你就兼職 PM, 看看競品. 反正 PM 也會看競品, 包裝成需求提出.
    golangLover
        3
    golangLover  
       2021-04-28 11:24:32 +08:00 via Android
    这是人的问题,不是技术问题。
    Mohanson
        4
    Mohanson  
       2021-04-28 11:34:26 +08:00 via Android   ❤️ 1
    没有设计就是最好的设计
    SteinsGate
        5
    SteinsGate  
       2021-04-28 12:02:18 +08:00 via Android
    将有可能变化的模块(类)依赖接口
    kop1989
        6
    kop1989  
       2021-04-28 12:11:11 +08:00
    能做到的也就是功能解耦、性能冗余了。

    因为你不管用什么精妙设计,都会有刁钻角度的需求一击既溃的。
    no1xsyzy
        7
    no1xsyzy  
       2021-04-28 12:47:26 +08:00   ❤️ 1
    没有银弹

    除非你允许插件替换你的二进制码(参考 Minecraft 的 mod
    abcbuzhiming
        8
    abcbuzhiming  
       2021-04-28 13:22:20 +08:00
    别想了,你保证不了的,就现在互联网项目那种动不动推了重来的模式,你怎么弄都没有用,所谓扩展,是保证原有模块基本不变的情况下,新增功能,可现在的开发需求动不动玩的是“推翻”,还扯淡什么“拥抱变化”。这种换神仙也没用,推了重来是唯一方式
    baiyi
        9
    baiyi  
       2021-04-28 13:33:32 +08:00
    可以看看这本书作者提供的书单,虽然这本书讲的是重构,但重构和设计是分不开的
    https://github.com/phodal/migration
    PainAndLove
        10
    PainAndLove  
       2021-04-28 13:38:34 +08:00
    这个问题我之前也想过,如果基于目前我们项目的组织,让我自己提需求。 我可以变着花样让当前的扩展性=0
    312ybj
        11
    312ybj  
       2021-04-28 14:03:48 +08:00
    找到变化,封装变化。 在完成这一期需求的同时, 尽量地使用设计模式动态地抽象结构设计; 如果是增加功能,可以多加个节点就完事, 如果是改之前的需求, 那就得改之前的代码了。
    watcher
        12
    watcher  
       2021-04-28 14:09:11 +08:00
    重构 - 有效改善之前装过的逼
    zhengxiaowai
        13
    zhengxiaowai  
       2021-04-28 14:09:19 +08:00
    keep to refactor
    kooze
        14
    kooze  
       2021-04-28 14:12:32 +08:00
    这就是他们要的“经验”
    domodomo
        15
    domodomo  
       2021-04-28 14:23:23 +08:00
    向你推荐面向接口 /协议编程设计,用过的同学都说好,再也不怕产品经理拍脑袋的需求了。
    v2lhr
        16
    v2lhr  
       2021-04-28 14:27:48 +08:00
    计划赶不上变化
    charten
        17
    charten  
       2021-04-28 14:30:04 +08:00
    既然计划赶不上变化,那就以不变应万变
    IvanLi127
        18
    IvanLi127  
       2021-04-28 16:18:38 +08:00
    微服务?让重构的时候负担小点?
    libook
        19
    libook  
       2021-04-28 16:32:27 +08:00
    https://www.v2ex.com/t/767139?p=1#r_10391487

    先让产品设计人员做好未来的规划,在可预见的需求中进行扩展性的设计,有余力可以在不提高成本的条件下考虑一些未计划但可能大概率会有的需求。

    然后就是要时刻意识到,你的代码是有生命周期的,一旦需求发生变化,生命周期结束,让项目经理在评估项目 ROI 的时候把这个生命周期考虑进去。
    s0nnse
        20
    s0nnse  
       2021-04-28 16:35:25 +08:00
    DDD 领域驱动设计模式
    tairan2006
        21
    tairan2006  
       2021-04-28 16:40:05 +08:00
    保证不了的

    成本也不允许你保证
    fkdog
        22
    fkdog  
       2021-04-28 16:44:45 +08:00
    在国内的互联网项目就不要考虑扩展性一类的东西了。没必要也没有意义。

    国内的互联网项目很大的特点就是高层为了抢市场,经常会去起各种各样的项目养着,能养大的话就继续做,养不大就放弃掉。

    一般这类项目能做大的话,后期如果撑不住的就直接推翻重构了。
    jinhan13789991
        23
    jinhan13789991  
       2021-04-28 16:57:37 +08:00
    转行可破
    996icu007007
        24
    996icu007007  
       2021-04-28 17:00:14 +08:00
    借楼出域名 ofoer.com
    66beta
        25
    66beta  
       2021-04-28 17:01:45 +08:00
    这就是互联网公司抛弃 35 岁以上员工而失去的东西之一
    xingguang
        26
    xingguang  
       2021-04-28 17:25:21 +08:00
    除非开始的时候就把每个组件拆分的很细,然后自由组合,否则基本就要重构
    akira
        27
    akira  
       2021-04-28 17:28:06 +08:00
    没有什么是中间加一层解决不了的
    SolaWing
        28
    SolaWing  
       2021-04-29 01:36:25 +08:00 via iPhone
    扩展性是你把相关领域的问题想透,把核心能力和边界想清楚才有的。大部分敏捷开发,开发自己都没想清楚,老老实实按当前现状设计吧。别考虑什么扩展性。唯一需要考虑的,就是即时重构,依赖多的底层代码,记得拆分隔离。这样不至于需求改动时伤筋动骨。
    xuanbg
        29
    xuanbg  
       2021-04-29 05:17:39 +08:00
    抽象,就是关注共性的部分,把他们正确的分离出来,并且正确的使用共性的部分。当特性都被共性取代后,就自然而然成中台了。
    LessonOne
        30
    LessonOne  
       2021-04-29 09:36:15 +08:00
    @996icu007007 OFO 已经凉了 还欠着我 100 押金没退给我 兄嘚
    taowen
        31
    taowen  
       2021-04-29 13:43:55 +08:00
    既然肯定是要推翻的,那就让代码写得更容易被删除啊。被依赖越多的代码,越难以被删除。
    maxbon
        32
    maxbon  
       2021-04-29 17:25:50 +08:00
    经验咯,碰到的坑多了,就会提前排坑了
    NUT
        33
    NUT  
       2021-04-29 19:20:14 +08:00
    其实就是元信息抽象不够。最好的方式就是 产品懂技术。从技术的维度去构造需求。 可以把程序员理解为 实现,产品理解为 interface 。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3437 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 04:55 · PVG 12:55 · LAX 20:55 · JFK 23:55
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.