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

[hbsfxlz]

什么业务

[Malthael]

后端就你一个？

[oxoxoxox]

函数模块细分 分层设计 降低模块间的耦合

[Linxing]

数据库设计尽量冗余

[zhangjiabin1010]

三楼+1，降低耦合才是王道。顺便在办公桌上放把三十米的大刀来威慑一下

[splendone]

就给前端提供接口，一般业务，多个后端程序员，我写的多一些。我的感受是需求怎么实现都可以，各有各的写法，高明的，菜鸟的，需求不变都可以交差，感觉差别在后期需求不断变化之后，就有差距了，高手们总有些针对这方面总结的一般而言的经验之谈吧，怎样的架构可以降低需求变更成本？以不变应万变（理想情况？），或者不能抽象到一般情况，劳烦举例一二说明里面的门道也是好的。或者有同感的分享经历，没杀过猪也见过猪跑了，也能增加几分阅历。在下洗耳恭听，望各位不吝赐教。

[lueffy]

一个不成熟的小建议
将你觉得可能会变动的规则 动态配置
尽量不要写死
比如说 我最近在做 判定老师是否迟到早退 ，一会说只要是提前走就算早退，一会又说提早十分钟才算，把这个差值放数据库里，启动时动态读
还有就是 产品提需求的时候，自己先想下可能会出现变动的地方(对开发影响比较大),提前跟产品沟通清楚，告诉他哪些地方如果改动会影响较大，哪些无所谓；并且问他未来哪些细节可能会改动

[Kilerd]

目前实践 GraphQL

[PazuLee]

降低耦合+提前跟产品沟通下阶段需求

[ducklyl]

这问题很大，如何做好架构设计

[megachweng]

文案统一服务端给 手动狗头

[zgcwkj]

同 #4，把数据库设计的冗余都一点，还有提前想到被人后面可能要改的地方。另外模块和模块间尽量用接口调用的方式实现，（我是一枚小白）

[Yuicon]

学会讨价还价 提高需求变更成本

[rockyou12]

不然 lz 觉得架构师是干嘛的……

[luosuosile]

13l 说的好:-)，

[onepunch]

扫码改需求才是正道！产品变更频繁的话，你无法在代码层面避免较小的改动。

[songkai]

抽象 、降低耦合，多了解些设计模式对你有好处。

[Banxiaozhuan]

个人觉得，维护成本的提高，与你每次完成需求的方式有关。 如果你每次写一个需求的时候，都 不断的重构代码，虽然看似每次多用了些时间，但是对与后期的维护起到很大的帮助。

[Eugene1024]

需求一直变更，就算没 bug，你也会一直改的

[surick]

@lueffy 赞同你的想法，但是放数据库不太好吧，一般这类太多的话还是写在配置文件

[lueffy]

@JinyAa 我之前也是写在配置文件里的，但是如果规则变动了还要改代码，重新打包，走一遍上线的流程，很麻烦
那些参数，在服务器启动的时候，读取一次，放到全局变量里
这样如果修改了，改下数据库的值，重启一下服务器就行了

[fmumu]

@lueffy 配置文件放在外部，再弄个热加载

[manr]

3L 说的很对，直接一点就是解耦，熟悉项目流程架构对开发很有帮助

[AnyISalIn]

@lueffy #21 配置文件读环境变量就行了

[jwk345]

@lueffy 放数据库里，提供修改的接口，修改完自动刷新，不用重启

[jswh]

没有银弹。

[colorwin]

单元测试

[kaedea]

少接需求

[FallenTy]

只要需求没有停止变更，BUG 就少不了。细分函数，解耦之类的操作都是为了后面尽量少的改动

[Vegetable]

这问题太大了
自己能做的就是写易维护的代码
留足配置空间,解耦合

[yoqu]

使用拒绝技能，需求没有太明确尽量少写代码，没有代码的程序 bug 率是最低的

[lcdxiangzi]

个人理解需要对业务背景有一个比较深刻的理解，在此基础上做一个好的架构设计，从数据、流程等多个维度对系统进行建模设计，参数化是一个思路，但是随之而来的是测试工作量的增多。
这个问题不是前端或者后端的问题，而是一个整体的规划和设计。涉及到一个软件项目的方方面面

[NoString]

@megachweng 哈哈哈你太真实了。我这就期就是，产品天天喊着文案后端给

[fleam]

不改 bug 等着被开除吗？

[yhvictor]

针对 bug 多写测试

[glacer]

《重构》中的建议是，不要在项目初期就进行过多的设计，重构应该是在项目开发的过程中同步进行。一旦察觉出有代码的问题就应该立即进行优化，而不是堆积起来后再重构。

[splendone]

总结、反馈

总结：
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]

前几天不是有一篇说后端因为架构写得太好被开了么

[vindurriel]

这个问题非常适合面试时问 区分度很高