这是一个创建于 2560 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 hbsfxlz 2019 年 1 月 8 日 什么业务 |
 | 2 Malthael 2019 年 1 月 8 日 后端就你一个？ |
 | 3 oxoxoxox 2019 年 1 月 8 日 via Android  2 函数模块细分 分层设计 降低模块间的耦合 |
 | 4 Linxing 2019 年 1 月 8 日 via iPhone 3 数据库设计尽量冗余 |
 | 5 zhangjiabin1010 2019 年 1 月 8 日 三楼+1，降低耦合才是王道。顺便在办公桌上放把三十米的大刀来威慑一下 |
 | 6 splendone OP 就给前端提供接口，一般业务，多个后端程序员，我写的多一些。我的感受是需求怎么实现都可以，各有各的写法，高明的，菜鸟的，需求不变都可以交差，感觉差别在后期需求不断变化之后，就有差距了，高手们总有些针对这方面总结的一般而言的经验之谈吧，怎样的架构可以降低需求变更成本？以不变应万变（理想情况？），或者不能抽象到一般情况，劳烦举例一二说明里面的门道也是好的。或者有同感的分享经历，没杀过猪也见过猪跑了，也能增加几分阅历。在下洗耳恭听，望各位不吝赐教。 |
 | 7 lueffy 2019 年 1 月 8 日 3 一个不成熟的小建议 将你觉得可能会变动的规则 动态配置 尽量不要写死 比如说 我最近在做 判定老师是否迟到早退 ，一会说只要是提前走就算早退，一会又说提早十分钟才算，把这个差值放数据库里，启动时动态读 还有就是 产品提需求的时候，自己先想下可能会出现变动的地方(对开发影响比较大),提前跟产品沟通清楚，告诉他哪些地方如果改动会影响较大，哪些无所谓；并且问他未来哪些细节可能会改动 |
 | 8 Kilerd 2019 年 1 月 8 日 via iPhone 1 目前实践 GraphQL |
 | 9 PazuLee 2019 年 1 月 8 日 降低耦合+提前跟产品沟通下阶段需求 |
 | 10 ducklyl 2019 年 1 月 8 日 这问题很大，如何做好架构设计 |
 | 11 megachweng 2019 年 1 月 8 日 via iPhone 文案统一服务端给 手动狗头 |
 | 12 zgcwkj 2019 年 1 月 8 日 同 #4，把数据库设计的冗余都一点，还有提前想到被人后面可能要改的地方。另外模块和模块间尽量用接口调用的方式实现，（我是一枚小白） |
 | 13 Yuicon 2019 年 1 月 8 日 学会讨价还价 提高需求变更成本 |
 | 14 rockyou12 2019 年 1 月 8 日 不然 lz 觉得架构师是干嘛的…… |
 | 15 luosuosile 2019 年 1 月 8 日 13l 说的好:-)， |
 | 16 onepunch 2019 年 1 月 8 日 扫码改需求才是正道！产品变更频繁的话，你无法在代码层面避免较小的改动。 |
 | 17 songkai 2019 年 1 月 8 日 1 抽象 、降低耦合，多了解些设计模式对你有好处。 |
 | 18 Banxiaozhuan 2019 年 1 月 8 日 个人觉得，维护成本的提高，与你每次完成需求的方式有关。 如果你每次写一个需求的时候，都 不断的重构代码，虽然看似每次多用了些时间，但是对与后期的维护起到很大的帮助。 |
 | 19 Eugene1024 2019 年 1 月 8 日 需求一直变更，就算没 bug，你也会一直改的 |
| 21 lueffy 2019 年 1 月 8 日 via iPhone @JinyAa 我之前也是写在配置文件里的，但是如果规则变动了还要改代码，重新打包，走一遍上线的流程，很麻烦 那些参数，在服务器启动的时候，读取一次，放到全局变量里 这样如果修改了，改下数据库的值，重启一下服务器就行了 |
 | 23 manr 2019 年 1 月 8 日 3L 说的很对，直接一点就是解耦，熟悉项目流程架构对开发很有帮助 |
 | 26 jswh 2019 年 1 月 8 日 没有银弹。 |
 | 27 colorwin 2019 年 1 月 8 日 单元测试 |
 | 28 kaedea 2019 年 1 月 8 日 via Android 少接需求 |
 | 29 FallenTy 2019 年 1 月 8 日 只要需求没有停止变更，BUG 就少不了。细分函数，解耦之类的操作都是为了后面尽量少的改动 |
 | 30 Vegetable 2019 年 1 月 8 日 这问题太大了 自己能做的就是写易维护的代码 留足配置空间,解耦合 |
 | 31 yoqu 2019 年 1 月 8 日 使用拒绝技能，需求没有太明确尽量少写代码，没有代码的程序 bug 率是最低的 |
 | 32 lcdxiangzi 2019 年 1 月 8 日 个人理解需要对业务背景有一个比较深刻的理解，在此基础上做一个好的架构设计，从数据、流程等多个维度对系统进行建模设计，参数化是一个思路，但是随之而来的是测试工作量的增多。 这个问题不是前端或者后端的问题，而是一个整体的规划和设计。涉及到一个软件项目的方方面面 |
 | 33 NoString 2019 年 1 月 8 日 @megachweng 哈哈哈你太真实了。我这就期就是，产品天天喊着文案后端给 |
 | 34 fleam 2019 年 1 月 8 日 via Android 不改 bug 等着被开除吗？ |
 | 35 yhvictor 2019 年 1 月 8 日 via iPhone 针对 bug 多写测试 |
 | 36 glacer 2019 年 1 月 8 日 1 《重构》中的建议是，不要在项目初期就进行过多的设计，重构应该是在项目开发的过程中同步进行。一旦察觉出有代码的问题就应该立即进行优化，而不是堆积起来后再重构。 |
| 37 splendone OP 总结、反馈 总结： 1. 抽象、解耦、分层、细化； 2. graphql ； 3. 数据库的设计方面； 4. 参数动态调整，不写死； 5. 重构； 6. 设计模式 ------------------------------------ 反馈： 1. 问过‘有经验的’同事，也简单一提说分层，是个方向，但是自己还是没明白，再继续查查了； 2. 有简单查了一下 graphql，目前不明觉厉状态…… 3. 设计模式看了这个： https://www.cnblogs.com/susanws/p/5510229.html，较之前多了些理解吧； ------------------------------------ ps：刚完成一个项目，领导让我们复盘，总结一下怎么才能不出现干一年 bug 一堆的问题，就从自身想了一下，代码大部分是我写的，功能明确，就开始写接口，需要什么数据就从哪里获取数据，一个个接口写下来，功能也实现了，没有什么解耦啊的概念，到后期就是无尽的 bug 模式，肯定是自己哪里做的不够，需要提高才是，就这里来问一下，想必有前辈、老司机、同道中人会指点迷津，也许我面临的问题不是一两句能说明白的，仙人指路也可以，我去查查看，结合代码说明可能更清楚吧，那么届时留个博客地址什么的，我们去观瞻~ pps: 需求变更可以控制，但是不可避免，怎么控制的技巧还在这里之前，这里先讨论需求确认变化之后我能做什么，所以这里是讨教怎么写代码或者设计代码、架构什么的，才能在需求变更后更灵活的实现，眼下我想先提高自己这方面的能力吧。 ppps: 总结是我目前状态和能力能理解的各位的表达，也许有老司机的表达我现在还体会不到，没事，以后会来挖坟啃的。反馈是看到各位的意见和建议，立即行动起来的反馈，希望能有建设性和可执行的意见哦。 |
 | 38 orqzsf1 2019 年 1 月 8 日 前几天不是有一篇说后端因为架构写得太好被开了么 |
 | 39 vindurriel 2019 年 1 月 9 日 via iPhone 这个问题非常适合面试时问 区分度很高 |
Select Language