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

要多健壮的代码才能支撑起千变万化的需求?

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

    最后不会成为屎山

    114 条回复    2021-08-14 16:48:37 +08:00
    1  2  
    typing
        1
    typing   73 天前 via iPhone   ❤️ 1
    容易改的代码
    FanChen
        2
    FanChen   73 天前 via iPhone
    if else 足够多的话
    flyingghost
        3
    flyingghost   73 天前
    千变万化的开发团队。
    MrBearin
        4
    MrBearin   73 天前   ❤️ 9
    人容易看懂的代码
    XiLingHost
        5
    XiLingHost   73 天前
    可维护性高,可扩展性强的代码
    wangritian
        6
    wangritian   73 天前
    看架构怎么拆分层级依赖
    qping
        7
    qping   73 天前
    怎么都不可能吧,
    尽可能的解耦. 不断迭代 , 把一段时间内堆的小屎山铲掉
    xieqiqiang00
        8
    xieqiqiang00   73 天前   ❤️ 1
    “开闭原则( OCP ): 如果系统想要容易被改变,那么其设计就必须允许只靠增加代码来改变系统行为,而非只能修改原有代码”

    “不将未来的需求抽象化,「 You aren’t going to need it 」,一项中的需求往往是不存在的
    需要发现在某个位置确实需要边界,如果不设置,再添加的时候需要的成本和风险往往是比较高的
    架构师需要在上边两点做 trade-off,需要一点点未卜先知的能力”
    h82258652
        9
    h82258652   73 天前
    不可能的,例如一个一对一的逻辑,贯穿了整个业务流程,然后某天产品说要改成一对多的。
    HENQIGUAI
        10
    HENQIGUAI   73 天前   ❤️ 16
    waiaan
        11
    waiaan   73 天前
    @h82258652
    不错,就是这种业务逻辑都变了。
    BeautifulSoap
        12
    BeautifulSoap   73 天前   ❤️ 3
    这是做梦呢,对于处理千变万化业务的代码,最好办法就是引入测试(单元测试、集成测试)然后根据需求持续重构代码,而不是不停在之前的代码上修修改改

    代码即模型,你业务变了意味着模型也变了,想用一套代码处理所有业务意味着想用一套模型去处理所有业务,不存在这种神奇的银弹的
    zhangchongjie
        13
    zhangchongjie   73 天前   ❤️ 1
    代码这玩意儿,感觉就和做生活中产品一样,单一的产品功能简单反而达到更好地效果,想必这也是以后发展的趋势吧。而不是像现在 bat 一样,恨不得一个软件所有功能都集成了
    Granado
        14
    Granado   73 天前
    个人认为,这从来都不是代码的问题,根本在于没有一套合理的模型去处理业务;
    每次开发的时候,leader 都说要抽象,要扩展,可是最开始的设计根本考虑不到以后的各种业务细分 case,只能不停修修补补。
    pengtdyd
        15
    pengtdyd   73 天前   ❤️ 6
    典型的程序员思维。如果出现千变万化的需求说明你们公司应该换一个带脑子的产品经理
    yunyuyuan
        16
    yunyuyuan   73 天前
    @HENQIGUAI #10 少了个'亲',差评。

    应该是'亲,你好,有的'
    way2explore2
        17
    way2explore2   73 天前
    无码
    CodeCodeStudy
        18
    CodeCodeStudy   73 天前
    需求千变万化说明老板都不知道要做什么,赶紧跑路
    FranzKafka95
        19
    FranzKafka95   73 天前 via Android
    个人认为不是代码问题,是架构问题
    maichael
        20
    maichael   73 天前
    “没有银弹”
    charlie21
        21
    charlie21   73 天前
    垃圾需求直接挡掉,
    若你什么需求都接(且免费做),那么,嗯,哈哈,哈哈,连外包公司都知道 每一次和客户商定额外变化需求 都得额外加钱
    boywang004
        22
    boywang004   73 天前
    easier to change 也许更值得追求……
    yidinghe
        23
    yidinghe   73 天前   ❤️ 4
    我这边有一个服务就是帮助学校统计考试成绩。为了支撑各种学校的不同需求,我只能将统计过程划分成非常细微的步骤,根据需要进行组合。如下图所示:

    ![]( )
    Hack3rHan
        24
    Hack3rHan   73 天前 via iPhone   ❤️ 1
    正经回答:屎山
    rationa1cuzz
        25
    rationa1cuzz   73 天前
    足够简单的易懂的,记得之前的老大哥说过一句话,写代码秀什么操作,怎么简单怎么易懂怎么写,秀技术过段时间自己都不看不懂,更别说别人(小公司)
    huangmingyou
        26
    huangmingyou   73 天前
    像魔兽一样,允许产品经理写 lua 脚步,有没有搞头?
    wangkun025
        27
    wangkun025   73 天前
    道高一尺魔高一丈。
    放下反抗,立地成佛。
    waiaan
        28
    waiaan   73 天前
    liuxingdeyu
        29
    liuxingdeyu   73 天前
    没有银弹
    tabris17
        30
    tabris17   73 天前
    健壮性和“支撑起千变万化的需求”有什么关系?

    printf("Hello world"); 最健壮了,能撑起个啥?
    dxpy
        31
    dxpy   73 天前
    无解
    guisheng
        32
    guisheng   73 天前 via iPhone
    写的时候先走一步。
    Building
        33
    Building   73 天前 via iPhone   ❤️ 11
    我们公司开发了一个云软件,只要本地输入需求,AI 就会生成专用软件,使用特简单,就是编译时间比较长,可以随时登录查看编译进度,完成后直接下载就可以使用了。

    实际: 后台收到需求立刻组织团队人工开发,项目经理定时更新进度,完成后上传。
    newtype0092
        34
    newtype0092   73 天前   ❤️ 4
    代码不用多健壮,只要开发人员足够健壮,看起来一拳能打死🐂那种,就可以让提需求的人主动闭嘴,把千变万化的需求消灭在萌芽里。
    molvqingtai
        35
    molvqingtai   73 天前 via Android
    没有
    weiwenhao
        36
    weiwenhao   73 天前
    web 业务的话 直接把数据库数据原样丢给前端,让前端去处理,后端建表暴露增删改查,千万别做复杂处理和组合,不然需求一变你就要改代码。
    需求方都是看着最前端界面改的需求,让前端跟着变就好了, 数据则是固定的,不会因为需求的改变而改变。
    cz5424
        37
    cz5424   73 天前
    先教产品经理写代码,或招个会写代码的产品经理
    littlewing
        38
    littlewing   73 天前
    不可能,很多情况就是,功能 A 不需要做,以后也不会有,不用考虑这个功能,不需要设计那么复杂,快上线,过一段时间,A 功能需要做,马上就要,这周就要上线
    pkoukk
        39
    pkoukk   73 天前
    不需要健壮
    改变程度超过阈值就重写
    不然哪来的工作量,怎么造福新入行的同事
    手动狗头
    iBaoger
        40
    iBaoger   73 天前 via Android
    简单,易懂,功能闭环
    keepeye
        41
    keepeye   73 天前
    屎山是如何形成的。很多时候不是因为增加需求,而是因为需求不断变化,前后矛盾
    vone
        42
    vone   73 天前
    @HENQIGUAI nocode 现在的 issues:3,487 Open,514 Closed 。看起来也不是特别健壮了。/doge
    gps949
        43
    gps949   73 天前
    取决于你的“千变万化”会发生在多长时间内。
    [几天之内千变万化] 别写代码了,搞个脚本,最好还是靠人工吧。
    [几个月之内千变万化] 要注意类函数变量的类型、命名、作用范围等,编码时尽可能的考虑全特殊值、边界问题等。
    [几年之内千变万化] 写好注释、文档,系统模块化设计,标准化接口,数据格式精心设计更灵活,方法和模块复用尽可能小心。
    [几十年之内千变万化] 系统架构设计灵活、可扩展,代码语言的选择仔细考量,第三方框架、库、插件等尽量少用,一切轮子尽可能自己实现,并除很小内核外,尽可能以松耦合的插件方式实现。
    [几百年之内千变万化] 你 /你的程序 /业务活不了那么久,不如思考下人类发展历史走向吧。
    iBugOne
        44
    iBugOne   73 天前 via Android
    乱改需求可以掀翻小菜鸟,但是掀不翻大佬
    YUCOAT
        45
    YUCOAT   73 天前   ❤️ 2
    我觉得方法只有一种,那就是“看到 shit 的时候及时把屎铲掉,别等堆起来”。

    以前所在的团队,我们写代码遵循两条原则:
    1 、以前的旧代码,能不动就不动。
    2 、添加新代码的时候,尽可能少的对旧代码进行修改。

    正是因为这两条原则,使得垃圾代码越堆越高。

    纯靠设计来防止垃圾代码越堆越高根本不现实,项目早期的时候,我们会对未来需求的预测来设计代码结构。
    刚开始可能设计良好,一两年以后,新的需求与早期的预测差别越来越大,这时老的设计已经无法通过扩展代码的方式来满足新的需求了,这时如果不对部分代码进行翻新,垃圾代码就会慢慢堆积起来。
    bloomy8
        46
    bloomy8   73 天前
    @yidinghe 请教下这个图是手工画的还是自动生成的,用的什么软件
    thtznet
        47
    thtznet   73 天前
    能支撑业务的,从来就不是代码,而是资本。
    shyangs
        48
    shyangs   73 天前   ❤️ 2
    開閉原則( OCP ): 如果系統想要容易被改變,那麼其設計就必須允許只靠增加代碼來改變系統行為,而非只能修改原有代碼

    ----

    以前所在的團隊,我們寫代碼遵循兩條原則:
    1 、以前的舊代碼,能不動就不動。
    2 、添加新代碼的時候,盡可能少的對舊代碼進行修改。

    正是因為這兩條原則,使得垃圾代碼越堆越高。
    seakingii
        49
    seakingii   73 天前
    这不叫健壮,叫灵活吧
    opentrade
        50
    opentrade   73 天前
    解耦+单元测试
    swim2sun
        51
    swim2sun   73 天前
    没有银弹
    Perry
        52
    Perry   73 天前 via iPhone
    有各种测试真的是最重要的
    ericls
        53
    ericls   73 天前 via iPhone
    不需要 把该满足的目的满足就行了

    平面几何解决不了曲面几何的问题
    牛顿力学也解决不了微观的需求
    你的代码要那么厉害干什么?
    shot
        54
    shot   73 天前
    @yidinghe #23

    只是类图就错综复杂绕来绕去的……
    就算代码写的再优雅,要是移交给别人(或者半年后自己再来看)会很难看懂吧……

    针对这种计算规则多样,并且可能频繁修改的需求,一个比较推荐的办法是做个简单的「计算规则引擎」。

    比如说:把「计算公式」和「参数」按照标准的格式记录在 Excel 文件里,「计算规则引擎」解读该 Excel 文件生成计算规则,然后应用程序读取数据并调用计算引擎作计算。
    当需要更新计算规则时,业务人员只需修订 Excel,然后重新上传到系统。

    除了 Excel,Python/Lua/Javascript 之类的脚本语言也能用来定义计算规则,我甚至用过 xml 。
    之所以首选 Excel,是因为运营人员(产品经理、系统运维)和用户(学校老师)都熟悉 Excel 操作,而且能直接在 Excel 文件里输入一些样例数据对公式做人工验证。
    namelosw
        55
    namelosw   73 天前
    个人人为如果你用的语言支持 ad-hoc polymorphism,才比较建议追求灵活。

    如果语言只有继承的话,追求灵活一般都是作死。

    下面这篇文章说的是著名的表达式问题,很简单,就是加法乘法这些数据结构作为表达式,分别有打印和计算这些操作,然后希望符合 OCP 原则的情况下可以增加新的表达式和新的操作:

    https://koerbitz.me/posts/Solving-the-Expression-Problem-in-Haskell-and-Java.html

    如果你对比一下里面 Haskell 和 Java 的解决方案,就会发现 Haskell 在这个问题下实现 OCP 原则,使用了 Type Class 基本不牺牲可读性;而 Java 没有 ad-hoc polymorphism,要实现 OCP 只能用 Object Algebra 的方式来模拟,代码基本看不懂。
    3dwelcome
        56
    3dwelcome   73 天前
    @yidinghe 那么多英文,不写中文注释,完全不懂每个子模块的意思啊。
    libook
        57
    libook   73 天前
    《没有银弹》
    Sequencer
        58
    Sequencer   73 天前
    AOP
    g0thic
        59
    g0thic   73 天前
    写好文档和注释 就好了
    sakasaka
        60
    sakasaka   73 天前
    DDD 可以缓解这种问题,不过随着版本的演进,搞不好最终还是一坨屎
    starcraft
        61
    starcraft   73 天前
    如果项目本身就是业务型的,那就不可能存在你所说的。
    前期考虑的再细致完美,几次需求一变,都成屎山。
    xwayway
        62
    xwayway   73 天前
    遗憾的是管理者、乃至技术架构师都不能真正地接受演进式设计( Evolutionary Design ),尤其不能接受一个具有良好设计的系统,应该是能够被报废的,潜意识中总会希望系统建设能够一步到位,至少是“少走几步能到位”。
    摘自 [凤凰架构]
    Samuelcc
        63
    Samuelcc   73 天前 via Android
    个人认为是分层设计搭配合理的抽象,并及时地应对需求进行架构演进,不要堆技术债务。
    在写代码的时候发现有 bad smell,及时着手修改。
    Mark24
        64
    Mark24   73 天前
    不如解决产品。
    godgc
        65
    godgc   73 天前
    个人认为,在重大代码更新后能够有一定时间可以对代码进行升级,不断的 patch 增加代码的鲁棒性,当然注释肯定必不可少
    NonClockworkChen
        66
    NonClockworkChen   73 天前
    产品逻辑一塌糊涂的话,没救。
    chanchan
        67
    chanchan   73 天前
    设计一个 DSL 丢给别人,然后进入下一个循环
    hungrybirder
        68
    hungrybirder   73 天前
    放心,再牛逼的架构,也跟不上产品逻辑的变化。
    wsfmzq
        69
    wsfmzq   73 天前
    https://www.v2ex.com/t/795055#reply52 只有放弃英文代码,写全中文代码,才能支撑起千变万化的需求
    jones2000
        70
    jones2000   73 天前
    钱到位, 别说千变万化, 就算亿万变化也没问题.
    justrand
        71
    justrand   73 天前
    我觉得,公司能保证每次代码改动都有详细的开发文档(改在哪里,为什么改,涉及那些业务)留底才行!
    ljzxloaf
        72
    ljzxloaf   73 天前
    ddd,如果業務模型發生顛覆性變化的話不能算是程序設計的問題。另外,這不叫健壯,這叫可擴展性。有個原則叫做 ETL ( easy to change )
    lap510200
        73
    lap510200   73 天前
    @flyingghost 我觉得是稳定的开发团队才能支撑,频繁更换人的团队,坑只会越来越多,然后在原基础打补丁,而不敢轻易重构
    whileFalse
        74
    whileFalse   73 天前 via iPhone
    需求也得健壮。
    有的需求一看就不靠谱的喷死就是了。
    lulu7
        75
    lulu7   73 天前
    当然要代码集体所有,这样团队中的每个人都可以看到并修改代码的任意部分。看过一个相关小视频,楼主可以参考: https://www.zentao.net/redirect-index-19354.html
    jin7
        76
    jin7   73 天前
    需要健壮的身体
    shuxhan
        77
    shuxhan   73 天前
    一个计划做一把椅子最后产出一套房子的行业,忍着吧
    coolmenu
        78
    coolmenu   73 天前
    不可能有对付千变万化需求的框架,能在某一个领域解决一部问题的框架就很好了,类似于 saleforce 这种体系,把销售的框架搭好,然后给一堆 api,还有定制的开发语言,公司定制自己的销售策略,管理等等,这已经很复杂了。
    php01
        79
    php01   73 天前
    世界上能言出法随的,都不是人,二郎神也才 36 变化,孙悟空也才 72 变化。
    你上来就千万变化。。。
    janxin
        80
    janxin   73 天前
    不可能
    TheBlade
        81
    TheBlade   73 天前
    @bloomy8 可以试试看 Mermaid, 可以在 typora 里直接成图, java 项目有一个 X-Ray 的 eclipse 插件, 可以根据你的项目自动生成 https://xray.inf.usi.ch/xray.php, 个人比较喜欢 Mermaid
    henryhu
        82
    henryhu   73 天前
    配置化模块
    simo
        83
    simo   73 天前
    千变万化才能养活这么多人
    bloomy8
        84
    bloomy8   73 天前
    @TheBlade 好的,我试试能不能在 OC 项目里用,谢谢
    wolfie
        85
    wolfie   73 天前   ❤️ 1
    团队所有人对要更改代码足够熟悉
    足够的时间开发
    glfpes
        86
    glfpes   73 天前
    如果需求是千变万化的,那将需要重构。

    所以微服务还是有它的优势的,每一个服务都尽可能保持小,坚守初心。这样解耦的系统重构的模块会隔离。
    akira
        87
    akira   73 天前
    不相关的事情 不要放一起 , 尽可能的拆分
    burby
        88
    burby   73 天前 via iPhone
    千变万化的需求,不适合用现在程序来实现吧…… 等真人工智能吧
    jiayong2793
        89
    jiayong2793   73 天前
    代码?
    难道不是设计模式和架构吗?
    crclz
        90
    crclz   73 天前
    1. 战略设计:充分理解业务领域、合理划分 BoundedContext,并在 BoundedContext 间的耦合点做足抽象,保证耦合点变化少(例如,最开始只有手机号注册,后面来了微信微博用户。如果合理划分了 BC,那么只需要改身份与访问上下文,其他模块不需要改一行代码、一行测试代码)
    2. 遵循 DDD 的战术设计( less important than (1) )
    3. 代码需要有测试。易于测试的代码大概率是好的代码(例外:test induced design damage )
    4. 少魔法、少炫技的代码,尽量减少他人的障碍

    说开闭原则的,还只是停留在理论阶段的菜鸟。web 框架可以开闭,例如 asp.net 、spring,但是你的业务代码中的 application layer 你使用继承的方式扩展一个试试?根本原因在于 application layer 的职责是协调,是非常贴近核心需求的。新到来的需求用继承来扩展,如果你实践过,会发现非常痛苦。

    开闭原则描述的是通过继承、重写方法来进行扩展。打个比方,你写一个字可以越描越好看,越描越有楷体的感觉;但是你写作文如果这里插入一句,那里插入一句,就会乱七八糟。
    Kylin30
        91
    Kylin30   73 天前
    一个函数一个进程
    Rheinmetal
        92
    Rheinmetal   72 天前
    做低代码平台
    来键盘鼠标给你自己写
    :doge
    zhanghua0
        93
    zhanghua0   72 天前
    这个老哥提出来的见解 /t/795055
    isnullstring
        94
    isnullstring   72 天前
    支撑不了,要是能支撑,就是需求没到千变万化的程度。狗头.jpg
    Felldeadbird
        96
    Felldeadbird   72 天前
    屎山是不可避免的。只能尽量降低屎山的高度。
    raaaaaar
        97
    raaaaaar   72 天前 via Android
    有的问题不是代码问题
    wangyzj
        98
    wangyzj   72 天前
    千变万化但都可以砍掉的无用需求
    bear2000
        99
    bear2000   72 天前
    没有。最后都会变成屎山,我现在就在看屎山
    tobepro
        100
    tobepro   72 天前
    所以才需要定期重构,推倒重来才能解决问题。还能制造点 OKR
    1  2  
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1831 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 16:35 · PVG 00:35 · LAX 09:35 · JFK 12:35
    ♥ Do have faith in what you're doing.