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

写后端,怎样才能尽量少的改动来应对需求的变更,我写的代码到后期改不完的 bug

  •  
  •   splendone · 337 天前 · 3610 次点击
    这是一个创建于 337 天前的主题,其中的信息可能已经有所发展或是发生改变。
    39 回复  |  直到 2019-01-09 06:26:33 +08:00
        1
    hbsfxlz   337 天前
    什么业务
        2
    Malthael   337 天前
    后端就你一个?
        3
    oxoxoxox   337 天前 via Android   ♥ 2
    函数模块细分 分层设计 降低模块间的耦合
        4
    Linxing   337 天前 via iPhone   ♥ 3
    数据库设计尽量冗余
        5
    zhangjiabin1010   337 天前
    三楼+1,降低耦合才是王道。顺便在办公桌上放把三十米的大刀来威慑一下
        6
    splendone   337 天前
    就给前端提供接口,一般业务,多个后端程序员,我写的多一些。我的感受是需求怎么实现都可以,各有各的写法,高明的,菜鸟的,需求不变都可以交差,感觉差别在后期需求不断变化之后,就有差距了,高手们总有些针对这方面总结的一般而言的经验之谈吧,怎样的架构可以降低需求变更成本?以不变应万变(理想情况?),或者不能抽象到一般情况,劳烦举例一二说明里面的门道也是好的。或者有同感的分享经历,没杀过猪也见过猪跑了,也能增加几分阅历。在下洗耳恭听,望各位不吝赐教。
        7
    lueffy   337 天前   ♥ 3
    一个不成熟的小建议
    将你觉得可能会变动的规则 动态配置
    尽量不要写死
    比如说 我最近在做 判定老师是否迟到早退 ,一会说只要是提前走就算早退,一会又说提早十分钟才算,把这个差值放数据库里,启动时动态读
    还有就是 产品提需求的时候,自己先想下可能会出现变动的地方(对开发影响比较大),提前跟产品沟通清楚,告诉他哪些地方如果改动会影响较大,哪些无所谓;并且问他未来哪些细节可能会改动
        8
    Kilerd   337 天前 via iPhone   ♥ 1
    目前实践 GraphQL
        9
    PazuLee   337 天前
    降低耦合+提前跟产品沟通下阶段需求
        10
    ducklyl   337 天前
    这问题很大,如何做好架构设计
        11
    megachweng   337 天前 via iPhone
    文案统一服务端给 手动狗头
        12
    zgcwkj   337 天前
    同 #4,把数据库设计的冗余都一点,还有提前想到被人后面可能要改的地方。另外模块和模块间尽量用接口调用的方式实现,(我是一枚小白)
        13
    Yuicon   337 天前
    学会讨价还价 提高需求变更成本
        14
    rockyou12   337 天前
    不然 lz 觉得架构师是干嘛的……
        15
    luosuosile   337 天前
    13l 说的好:-),
        16
    onepunch   337 天前
    扫码改需求才是正道!产品变更频繁的话,你无法在代码层面避免较小的改动。
        17
    songkai   337 天前   ♥ 1
    抽象 、降低耦合,多了解些设计模式对你有好处。
        18
    Banxiaozhuan   337 天前
    个人觉得,维护成本的提高,与你每次完成需求的方式有关。 如果你每次写一个需求的时候,都 不断的重构代码,虽然看似每次多用了些时间,但是对与后期的维护起到很大的帮助。
        19
    Eugene1024   337 天前
    需求一直变更,就算没 bug,你也会一直改的
        20
    JinyAa   337 天前
    @lueffy 赞同你的想法,但是放数据库不太好吧,一般这类太多的话还是写在配置文件
        21
    lueffy   337 天前 via iPhone
    @JinyAa 我之前也是写在配置文件里的,但是如果规则变动了还要改代码,重新打包,走一遍上线的流程,很麻烦
    那些参数,在服务器启动的时候,读取一次,放到全局变量里
    这样如果修改了,改下数据库的值,重启一下服务器就行了
        22
    fmumu   337 天前 via Android   ♥ 1
    @lueffy 配置文件放在外部,再弄个热加载
        23
    manr   337 天前
    3L 说的很对,直接一点就是解耦,熟悉项目流程架构对开发很有帮助
        24
    AnyISalIn   337 天前   ♥ 1
    @lueffy #21 配置文件读环境变量就行了
        25
    jamesxu   337 天前 via iPhone   ♥ 1
    @lueffy 放数据库里,提供修改的接口,修改完自动刷新,不用重启
        26
    jswh   337 天前
    没有银弹。
        27
    colorwin   337 天前
    单元测试
        28
    kaedea   337 天前 via Android
    少接需求
        29
    FallenTy   337 天前
    只要需求没有停止变更,BUG 就少不了。细分函数,解耦之类的操作都是为了后面尽量少的改动
        30
    Vegetable   336 天前
    这问题太大了
    自己能做的就是写易维护的代码
    留足配置空间,解耦合
        31
    yoqu   336 天前
    使用拒绝技能,需求没有太明确尽量少写代码,没有代码的程序 bug 率是最低的
        32
    lcdxiangzi   336 天前
    个人理解需要对业务背景有一个比较深刻的理解,在此基础上做一个好的架构设计,从数据、流程等多个维度对系统进行建模设计,参数化是一个思路,但是随之而来的是测试工作量的增多。
    这个问题不是前端或者后端的问题,而是一个整体的规划和设计。涉及到一个软件项目的方方面面
        33
    NoString   336 天前
    @megachweng 哈哈哈你太真实了。我这就期就是,产品天天喊着文案后端给
        34
    fleam   336 天前 via Android
    不改 bug 等着被开除吗?
        35
    yhvictor   336 天前 via iPhone
    针对 bug 多写测试
        36
    glacer   336 天前   ♥ 1
    《重构》中的建议是,不要在项目初期就进行过多的设计,重构应该是在项目开发的过程中同步进行。一旦察觉出有代码的问题就应该立即进行优化,而不是堆积起来后再重构。
        37
    splendone   336 天前
    总结、反馈

    总结:
    1. 抽象、解耦、分层、细化;
    2. graphql ;
    3. 数据库的设计方面;
    4. 参数动态调整,不写死;
    5. 重构;
    6. 设计模式

    ------------------------------------
    反馈:
    1. 问过‘有经验的’同事,也简单一提说分层,是个方向,但是自己还是没明白,再继续查查了;
    2. 有简单查了一下 graphql,目前不明觉厉状态……
    3. 设计模式看了这个: https://www.cnblogs.com/susanws/p/5510229.html,较之前多了些理解吧;


    ------------------------------------

    ps:刚完成一个项目,领导让我们复盘,总结一下怎么才能不出现干一年 bug 一堆的问题,就从自身想了一下,代码大部分是我写的,功能明确,就开始写接口,需要什么数据就从哪里获取数据,一个个接口写下来,功能也实现了,没有什么解耦啊的概念,到后期就是无尽的 bug 模式,肯定是自己哪里做的不够,需要提高才是,就这里来问一下,想必有前辈、老司机、同道中人会指点迷津,也许我面临的问题不是一两句能说明白的,仙人指路也可以,我去查查看,结合代码说明可能更清楚吧,那么届时留个博客地址什么的,我们去观瞻~

    pps: 需求变更可以控制,但是不可避免,怎么控制的技巧还在这里之前,这里先讨论需求确认变化之后我能做什么,所以这里是讨教怎么写代码或者设计代码、架构什么的,才能在需求变更后更灵活的实现,眼下我想先提高自己这方面的能力吧。

    ppps: 总结是我目前状态和能力能理解的各位的表达,也许有老司机的表达我现在还体会不到,没事,以后会来挖坟啃的。反馈是看到各位的意见和建议,立即行动起来的反馈,希望能有建设性和可执行的意见哦。
        38
    orqzsf1   336 天前
    前几天不是有一篇说后端因为架构写得太好被开了么
        39
    vindurriel   336 天前 via iPhone
    这个问题非常适合面试时问 区分度很高
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4247 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 38ms · UTC 06:37 · PVG 14:37 · LAX 22:37 · JFK 01:37
    ♥ Do have faith in what you're doing.