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

后端程序员编码之前需要做些什么

  •  
  •   florentino · 2022-05-24 11:37:49 +08:00 · 2597 次点击
    这是一个创建于 674 天前的主题,其中的信息可能已经有所发展或是发生改变。

    背景

    最近项目上面来了需求,但是对于之前的逻辑改动很大,而且需求是一点一点加,遇到什么甲方就加什么,就是甲方也不知道最后他们想要什么样的业务平台,就是什么都想要

    另外提的需求也格外复杂

    问题

    被这些需求要搞疯了,感觉自己的代码写的和 shit 一样,请问作为一个后端程序员

    • 接到复杂需求后,应该如何进行需求分析和功能拆解呢
    • 可以用哪些工具来辅助自己更高效的分析业务逻辑呢
    • 编写代码前,可以做哪些工作,能够来帮助提高编码效率呢
    • 如何避免写出屎山代码呢

    小白,求解,谢谢🙏

    17 条回复    2022-05-24 23:39:12 +08:00
    huifer
        1
    huifer  
       2022-05-24 13:54:47 +08:00
    全部做面向接口开发,将可变的不可变的全部做成接口,然后根据某个东西从接口实现类中选择,然后配合一定的流程控制器进行流程编写
    hay313955795
        2
    hay313955795  
       2022-05-24 13:54:55 +08:00
    屎山本不是屎,
    只是年代旧了,腐烂发臭了闻起来比较像屎,
    如同榴莲般散发着让人不适应的气味,尝起来却有不同的滋味.
    或者你找你们公司的老旧代码看看,
    仔细尝一尝,
    拨开岁月的痕迹,
    你就能发现哎呀卧槽.这不是我前两天刚拉的吗?
    florentino
        3
    florentino  
    OP
       2022-05-24 14:24:35 +08:00
    @huifer 嗯嗯嗯 我消化一下
    jones2000
        4
    jones2000  
       2022-05-24 17:15:13 +08:00
    这个只能是靠行业经验了, 如果你在这个行业里面待的够久, 就回了解为什么会有这个需求,你的竞品是怎么实现这个需求的, 后续这个需求可能再那几个地方需要参数化,让客户自己配置,预留好。这些跟代码能力没有关系, 主要是了解你做的行业, 平时多和产品经理,客户沟通。
    zh6335901
        5
    zh6335901  
       2022-05-24 18:03:04 +08:00   ❤️ 1
    短时间内不断重构。动手之前确实需要深思熟虑,但是再怎么考虑都会有遗漏或者没有想好的地方,在实现功能的过程中不断的审视相关代码,消除坏味道。重构开始的越早,成本越小。
    zh6335901
        6
    zh6335901  
       2022-05-24 18:04:10 +08:00
    接上,单元测试是个好方法
    simonlu9
        7
    simonlu9  
       2022-05-24 19:58:16 +08:00   ❤️ 1
    1. 大道至简,接口测试是个方法,你可以可以控制方法责任分明,变得容易测试
    2. 抽象业务,考虑扩展,你的代码是否支持
    3. 结合生活场景,理解代码架构
    4. 不要为了设计模式而设计,把命名写得简单明了就已经很不错了
    pengtdyd
        8
    pengtdyd  
       2022-05-24 20:23:56 +08:00
    后端程序员编码之前需要做些什么
    答:需要先泡一杯咖啡
    sunwei0325
        9
    sunwei0325  
       2022-05-24 21:01:19 +08:00   ❤️ 1
    只管写注释, 剩下的交给 copilot
    Dragonphy
        10
    Dragonphy  
       2022-05-24 21:25:05 +08:00
    可以先写,然后用设计模式不断重构
    haah
        11
    haah  
       2022-05-24 21:51:54 +08:00
    画流程图 -> 出原型系统 -> 写设计文档 -> ... ... ... 此处省略 108 个字。
    tairan2006
        12
    tairan2006  
       2022-05-24 21:58:10 +08:00 via Android
    让产品经理抽象需求
    v23x
        13
    v23x  
       2022-05-24 21:59:28 +08:00
    重构 重构 不断重构
    chihiro2014
        14
    chihiro2014  
       2022-05-24 23:11:30 +08:00
    先把接口列出来,再去做实现
    lmshl
        15
    lmshl  
       2022-05-24 23:35:13 +08:00   ❤️ 2
    和楼主差不多的工作内容,我是写 Scala 业务系统搬砖的,初创公司业务方向经常变来变去,还经常需要舔甲方爸爸做定制需求。

    我的方式是面向类型建模,因为 Scala 里有 ADT 这些 Sum type 类型,我可以把业务流程和状态编码到 Scala 的类型中,包括中间数据状态。同时还可以借助 Either / Option 这些内置类型抽象,做 Railway Oriented Programming
    https://fsharpforfunandprofit.com/rop/。Scala 编译器能辅助我避免掉 50% 以上的 Bug ,剩下的 Bug 很大一部分是产品经理自己都没想清楚,和过去的功能冲突了。只有很小一部分是一些运行时错综复杂的问题。

    同时尽量将系统核心部分稳定下来,新需求(特别是那些听上去就很扯的)往新的文件夹 /子项目里实现,哪天这个客户不做了(这块逻辑不要了)直接整体移除掉,对主线功能没有影响。

    其实避免屎山我觉得很重要的一点是,常维护,不要惧怕修改重构。在做新需求的时候,不可避免的会对老代码有些许修改,这就是重构的最佳时间。我曾花了 2-3 个月时间把整个系统的异步模型迁移到另一个框架上,这期间代码质量得到了很大提升,CPU 占用率也降低到原来的几十分之一。
    lmshl
        16
    lmshl  
       2022-05-24 23:36:46 +08:00   ❤️ 1
    总结:
    1. 接到复杂需求后,应该如何进行需求分析和功能拆解呢
    2. 可以用哪些工具来辅助自己更高效的分析业务逻辑呢
    3. 编写代码前,可以做哪些工作,能够来帮助提高编码效率呢
    4. 如何避免写出屎山代码呢

    答:
    1/2/3: 面向类型建模
    4: 常修常新,不要惧怕重构底层
    Buges
        17
    Buges  
       2022-05-24 23:39:12 +08:00 via Android
    屎山是不可避的,要不然也不会发明 go 了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3245 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 14:17 · PVG 22:17 · LAX 07:17 · JFK 10:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.