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

[florentino]

背景

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

另外提的需求也格外复杂

问题

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

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

小白,求解,谢谢🙏

[huifer]

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

[hay313955795]

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

[florentino]

@huifer 嗯嗯嗯 我消化一下

[jones2000]

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

[zh6335901]

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

[zh6335901]

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

[simonlu9]

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

[pengtdyd]

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

[sunwei0325]

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

[Dragonphy]

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

[haah]

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

[tairan2006]

让产品经理抽象需求

[v23x]

重构 重构 不断重构

[chihiro2014]

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

[lmshl]

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

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

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

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

[lmshl]

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

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

[Buges]

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