工作多年以后,你们写复杂逻辑出的 Bug 还多吗

256 天前
xiaotianhu  xiaotianhu
RT ,有什么减少 bug 的方式可以介绍下么。
写复杂逻辑(非 CRUD )还是比较容易出 bug 。
先写 test case 我也知道,但是复杂逻辑的 test 也不是很好写诶。
2574 次点击
所在节点   职场话题  职场话题
14 条回复
kiracyan
kiracyan
256 天前
业务多年后出 BUG ,大多数是因为业务需求的变化导致的。
kiracyan
kiracyan
256 天前
复杂逻辑也要 test case ,这是测试要考虑的事情了
oldcaptain666
oldcaptain666
256 天前
笑死,前端搬砖工根本没有什么复杂逻辑😭
qwertyzzz
qwertyzzz
256 天前
有什么减少 bug 的方式可以介绍下么。
---测试哇
ShrinkLynn
ShrinkLynn
256 天前
上次我们 UI 问我为啥她提了个修改我一分钟就改好了,我告诉她,我提前预判了你要改这边 .. 笑死
treblex
treblex
256 天前
@oldcaptain666 后端:来了哦,别急
shawnsh
shawnsh
256 天前
bug 原因不是有个饼图统计结果吗,其中占大头的有需求理解不清晰,设计问题,编码问题。复杂逻辑根本在于不是十分清楚需求,设计上不能很好降低复杂度。
NNS71L068O2v70DB
NNS71L068O2v70DB
255 天前
开发之前规约看一下,每条规约后面都是一个个血淋淋的教训
JoeDH
JoeDH
255 天前
我开发的那些破系统,还真没啥复杂逻辑
shapper
shapper
254 天前
复杂逻辑分成一坨一坨的小逻辑(就是拿一坨一坨的 if-else )
namonai
namonai
254 天前
从理论上来说,计算机系统可以抽象分层为:
1. 需求
2. 算法
3. 高级语言实现
4. 汇编码/机器码
5. 硬件实现

这中间的任何一层转化错误都会导致程序的正确性出现问题。而写业务逻辑的程序员可以把控只有需求->算法与算法->高级语言实现,有的时候是算法无法 cover 需求,有的时候是算法的实现出现了问题。但是更多的时候,抽象出需求这一步本身就有可能出现问题。所以要少写 bug ,第一步是要清楚自己需要做什么,事无巨细方方面面考虑到。
ccde8259
ccde8259
254 天前
多,所以不写复杂逻辑……
接需求的时候,最重要的一步动作就是怎么把这个实现做拆解……拆解成一堆 stupid simple 的事情去实现,然后对这些实现进行一个个组装的动作……
如果你的实现不能做到 stupid simple ,叠加各种代码交接和新的逻辑加入,那最终一定有一天这个实现就会失控从而被重构。
xavierchow
254 天前
同意 12 楼,尽量不写复杂逻辑,if-else 也尽量少用,多用 composition 和 polymophism 。
编码层面可以尽量用抽象的思维隔离开通用和特殊的处理,
业务层面可以让产品经理或者架构设计师尽量把复杂逻辑捋清楚或者简化/统一化,最佳实践是拿着测试 case/code 和 产品对一对。
changyou8
253 天前
bug 大部分是不懂技术的产品设计的不合理需求导致的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1047715

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX