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

[splendone]

[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 赞同你的想法，但是放数据库不太好吧，一般这类太多的话还是写在配置文件