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

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

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

@huifer 嗯嗯嗯 我消化一下

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

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

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

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

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

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

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

让产品经理抽象需求

重构 重构 不断重构

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

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

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

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

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

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

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