写后端，怎样才能尽量少的改动来应对需求的变更，我写的代码到后期改不完的 bug
splendone · splendone · 2019-01-08 09:56:30 +08:00 · 5256 次点击这是一个创建于 2180 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
hbsfxlz 2019-01-08 10:04:18 +08:00
什么业务
|
 |
2
Malthael 2019-01-08 10:06:42 +08:00
后端就你一个？
|
 |
3
oxoxoxox 2019-01-08 10:11:00 +08:00 via Android  2
函数模块细分 分层设计 降低模块间的耦合
|
 |
4
Linxing 2019-01-08 10:12:10 +08:00 via iPhone 3
数据库设计尽量冗余
|
 |
5
zhangjiabin1010 2019-01-08 10:14:46 +08:00
三楼+1，降低耦合才是王道。顺便在办公桌上放把三十米的大刀来威慑一下
|
 |
6
splendone OP 就给前端提供接口，一般业务，多个后端程序员，我写的多一些。我的感受是需求怎么实现都可以，各有各的写法，高明的，菜鸟的，需求不变都可以交差，感觉差别在后期需求不断变化之后，就有差距了，高手们总有些针对这方面总结的一般而言的经验之谈吧，怎样的架构可以降低需求变更成本？以不变应万变（理想情况？），或者不能抽象到一般情况，劳烦举例一二说明里面的门道也是好的。或者有同感的分享经历，没杀过猪也见过猪跑了，也能增加几分阅历。在下洗耳恭听，望各位不吝赐教。
|
 |
7
lueffy 2019-01-08 10:18:37 +08:00 3
一个不成熟的小建议
将你觉得可能会变动的规则 动态配置 尽量不要写死 比如说 我最近在做 判定老师是否迟到早退 ，一会说只要是提前走就算早退，一会又说提早十分钟才算，把这个差值放数据库里，启动时动态读 还有就是 产品提需求的时候，自己先想下可能会出现变动的地方(对开发影响比较大),提前跟产品沟通清楚，告诉他哪些地方如果改动会影响较大，哪些无所谓；并且问他未来哪些细节可能会改动 |
 |
8
Kilerd 2019-01-08 10:19:17 +08:00 via iPhone 1
目前实践 GraphQL
|
 |
9
PazuLee 2019-01-08 10:20:53 +08:00
降低耦合+提前跟产品沟通下阶段需求
|
 |
10
ducklyl 2019-01-08 10:21:04 +08:00
这问题很大，如何做好架构设计
|
 |
11
megachweng 2019-01-08 10:24:10 +08:00 via iPhone
文案统一服务端给 手动狗头
|
 |
12
zgcwkj 2019-01-08 10:29:06 +08:00
同 #4，把数据库设计的冗余都一点，还有提前想到被人后面可能要改的地方。另外模块和模块间尽量用接口调用的方式实现，（我是一枚小白）
|
 |
13
Yuicon 2019-01-08 10:30:41 +08:00
学会讨价还价 提高需求变更成本
|
 |
14
rockyou12 2019-01-08 10:31:24 +08:00
不然 lz 觉得架构师是干嘛的……
|
 |
15
luosuosile 2019-01-08 10:46:56 +08:00
13l 说的好:-)，
|
 |
16
onepunch 2019-01-08 10:53:16 +08:00
扫码改需求才是正道！产品变更频繁的话，你无法在代码层面避免较小的改动。
|
 |
17
songkai 2019-01-08 10:57:31 +08:00 1
抽象 、降低耦合，多了解些设计模式对你有好处。
|
 |
18
Banxiaozhuan 2019-01-08 11:26:27 +08:00
个人觉得，维护成本的提高，与你每次完成需求的方式有关。 如果你每次写一个需求的时候，都 不断的重构代码，虽然看似每次多用了些时间，但是对与后期的维护起到很大的帮助。
|
 |
19
Eugene1024 2019-01-08 11:27:56 +08:00
需求一直变更，就算没 bug，你也会一直改的
|
|
21
lueffy 2019-01-08 12:07:37 +08:00 via iPhone
@JinyAa 我之前也是写在配置文件里的，但是如果规则变动了还要改代码，重新打包，走一遍上线的流程，很麻烦
那些参数，在服务器启动的时候，读取一次，放到全局变量里 这样如果修改了，改下数据库的值，重启一下服务器就行了 |
 |
23
manr 2019-01-08 12:57:04 +08:00
3L 说的很对，直接一点就是解耦，熟悉项目流程架构对开发很有帮助
|
 |
26
jswh 2019-01-08 13:07:48 +08:00
没有银弹。
|
 |
27
colorwin 2019-01-08 13:08:51 +08:00
单元测试
|
 |
28
kaedea 2019-01-08 14:14:24 +08:00 via Android
少接需求
|
 |
29
FallenTy 2019-01-08 14:34:18 +08:00
只要需求没有停止变更，BUG 就少不了。细分函数，解耦之类的操作都是为了后面尽量少的改动
|
 |
30
Vegetable 2019-01-08 14:46:34 +08:00
这问题太大了
自己能做的就是写易维护的代码 留足配置空间,解耦合 |
 |
31
yoqu 2019-01-08 15:22:56 +08:00
使用拒绝技能，需求没有太明确尽量少写代码，没有代码的程序 bug 率是最低的
|
 |
32
lcdxiangzi 2019-01-08 15:32:33 +08:00
个人理解需要对业务背景有一个比较深刻的理解，在此基础上做一个好的架构设计，从数据、流程等多个维度对系统进行建模设计，参数化是一个思路，但是随之而来的是测试工作量的增多。
这个问题不是前端或者后端的问题，而是一个整体的规划和设计。涉及到一个软件项目的方方面面 |
 |
33
NoString 2019-01-08 15:38:46 +08:00
@megachweng 哈哈哈你太真实了。我这就期就是，产品天天喊着文案后端给
|
 |
34
fleam 2019-01-08 15:46:02 +08:00 via Android
不改 bug 等着被开除吗？
|
 |
35
yhvictor 2019-01-08 16:08:28 +08:00 via iPhone
针对 bug 多写测试
|
 |
36
glacer 2019-01-08 16:16:01 +08:00 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-01-08 17:06:17 +08:00
前几天不是有一篇说后端因为架构写得太好被开了么
|
 |
39
vindurriel 2019-01-09 06:26:33 +08:00 via iPhone
这个问题非常适合面试时问 区分度很高
|
Select Language