这是一个创建于 174 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT ，有什么减少 bug 的方式可以介绍下么。
写复杂逻辑（非 CRUD ）还是比较容易出 bug 。
先写 test case 我也知道，但是复杂逻辑的 test 也不是很好写诶。
写复杂逻辑（非 CRUD ）还是比较容易出 bug 。
先写 test case 我也知道，但是复杂逻辑的 test 也不是很好写诶。
14 条回复 • 2024-06-10 09:39:37 +08:00
 |
1
kiracyan 174 天前
业务多年后出 BUG ，大多数是因为业务需求的变化导致的。
|
|
2
kiracyan 174 天前
复杂逻辑也要 test case ，这是测试要考虑的事情了
|
 |
3
oldcaptain666 174 天前  1
笑死，前端搬砖工根本没有什么复杂逻辑😭
|
 |
4
qwertyzzz 174 天前
有什么减少 bug 的方式可以介绍下么。
---测试哇 |
 |
5
ShrinkLynn 174 天前
上次我们 UI 问我为啥她提了个修改我一分钟就改好了，我告诉她，我提前预判了你要改这边 .. 笑死
|
 |
6
treblex 174 天前
@oldcaptain666 后端：来了哦，别急
 |
 |
7
shawnsh 173 天前 via Android 1
bug 原因不是有个饼图统计结果吗，其中占大头的有需求理解不清晰，设计问题，编码问题。复杂逻辑根本在于不是十分清楚需求，设计上不能很好降低复杂度。
|
 |
8
jojojo 173 天前
开发之前规约看一下，每条规约后面都是一个个血淋淋的教训
|
 |
9
JoeDH 172 天前
我开发的那些破系统，还真没啥复杂逻辑
|
 |
10
shapper 172 天前
复杂逻辑分成一坨一坨的小逻辑（就是拿一坨一坨的 if-else ）
|
 |
11
namonai 172 天前
从理论上来说，计算机系统可以抽象分层为：
1. 需求 2. 算法 3. 高级语言实现 4. 汇编码/机器码 5. 硬件实现 这中间的任何一层转化错误都会导致程序的正确性出现问题。而写业务逻辑的程序员可以把控只有需求->算法与算法->高级语言实现，有的时候是算法无法 cover 需求，有的时候是算法的实现出现了问题。但是更多的时候，抽象出需求这一步本身就有可能出现问题。所以要少写 bug ，第一步是要清楚自己需要做什么，事无巨细方方面面考虑到。 |
 |
12
ccde8259 171 天前
多，所以不写复杂逻辑……
接需求的时候，最重要的一步动作就是怎么把这个实现做拆解……拆解成一堆 stupid simple 的事情去实现，然后对这些实现进行一个个组装的动作…… 如果你的实现不能做到 stupid simple ，叠加各种代码交接和新的逻辑加入，那最终一定有一天这个实现就会失控从而被重构。 |
 |
13
xavierchow 171 天前
同意 12 楼，尽量不写复杂逻辑，if-else 也尽量少用，多用 composition 和 polymophism 。
编码层面可以尽量用抽象的思维隔离开通用和特殊的处理， 业务层面可以让产品经理或者架构设计师尽量把复杂逻辑捋清楚或者简化/统一化，最佳实践是拿着测试 case/code 和 产品对一对。 |
 |
14
changyou8 171 天前
bug 大部分是不懂技术的产品设计的不合理需求导致的。
|
Select Language