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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 919 天前的主题，其中的信息可能已经有所发展或是发生改变。

背景

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

另外提的需求也格外复杂

问题

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

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

小白,求解,谢谢🙏

代码

需求

甲方

后端

17 条回复 • 2022-05-24 23:39:12 +08:00

huifer

2022-05-24 13:54:47 +08:00

全部做面向接口开发，将可变的不可变的全部做成接口，然后根据某个东西从接口实现类中选择，然后配合一定的流程控制器进行流程编写

hay313955795

2022-05-24 13:54:55 +08:00

屎山本不是屎,
只是年代旧了,腐烂发臭了闻起来比较像屎,
如同榴莲般散发着让人不适应的气味,尝起来却有不同的滋味.
或者你找你们公司的老旧代码看看,
仔细尝一尝,
拨开岁月的痕迹,
你就能发现哎呀卧槽.这不是我前两天刚拉的吗?

florentino

2022-05-24 14:24:35 +08:00

@huifer 嗯嗯嗯我消化一下

jones2000

2022-05-24 17:15:13 +08:00

这个只能是靠行业经验了，如果你在这个行业里面待的够久，就回了解为什么会有这个需求，你的竞品是怎么实现这个需求的，后续这个需求可能再那几个地方需要参数化，让客户自己配置，预留好。这些跟代码能力没有关系，主要是了解你做的行业，平时多和产品经理，客户沟通。

zh6335901

2022-05-24 18:03:04 +08:00

短时间内不断重构。动手之前确实需要深思熟虑，但是再怎么考虑都会有遗漏或者没有想好的地方，在实现功能的过程中不断的审视相关代码，消除坏味道。重构开始的越早，成本越小。

zh6335901

2022-05-24 18:04:10 +08:00

接上，单元测试是个好方法

simonlu9

2022-05-24 19:58:16 +08:00

1. 大道至简，接口测试是个方法，你可以可以控制方法责任分明，变得容易测试
2. 抽象业务，考虑扩展，你的代码是否支持
3. 结合生活场景，理解代码架构
4. 不要为了设计模式而设计，把命名写得简单明了就已经很不错了

pengtdyd

2022-05-24 20:23:56 +08:00

后端程序员编码之前需要做些什么
答：需要先泡一杯咖啡

sunwei0325

2022-05-24 21:01:19 +08:00

只管写注释, 剩下的交给 copilot

Dragonphy

2022-05-24 21:25:05 +08:00

可以先写，然后用设计模式不断重构

haah

2022-05-24 21:51:54 +08:00

画流程图 -> 出原型系统 -> 写设计文档 -> ... ... ... 此处省略 108 个字。

tairan2006

2022-05-24 21:58:10 +08:00 via Android

让产品经理抽象需求

v23x

2022-05-24 21:59:28 +08:00

重构重构不断重构

chihiro2014

2022-05-24 23:11:30 +08:00

先把接口列出来，再去做实现

lmshl

2022-05-24 23:35:13 +08:00

和楼主差不多的工作内容，我是写 Scala 业务系统搬砖的，初创公司业务方向经常变来变去，还经常需要舔甲方爸爸做定制需求。

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

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

其实避免屎山我觉得很重要的一点是，常维护，不要惧怕修改重构。在做新需求的时候，不可避免的会对老代码有些许修改，这就是重构的最佳时间。我曾花了 2-3 个月时间把整个系统的异步模型迁移到另一个框架上，这期间代码质量得到了很大提升，CPU 占用率也降低到原来的几十分之一。

lmshl

2022-05-24 23:36:46 +08:00

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

答：
1/2/3: 面向类型建模
4: 常修常新，不要惧怕重构底层

Buges

2022-05-24 23:39:12 +08:00 via Android

屎山是不可避的，要不然也不会发明 go 了。