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

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

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

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

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


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

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

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

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