这是一个创建于 2100 天前的主题，其中的信息可能已经有所发展或是发生改变。
总是会有一些情况考虑不到，所以出现 error，总是会自责不已，然后修复 bug。每次开发前总是想着要把场景想好，但是每次都是会漏掉一些场景，导致一些错误情况出现。求大佬分享技能
 |
1
hhyvs111 2019-02-15 15:47:07 +08:00
写多了就行了
|
 |
2
xcolder 2019-02-15 15:48:23 +08:00
单元测试
|
 |
3
jdgui 2019-02-15 15:49:04 +08:00
调整心态。
只需要在心里骂，什么傻逼用户这么用软件的。就完事 |
 |
4
emCupid 2019-02-15 15:50:11 +08:00  1
电脑、显示器、键盘、鼠标一切和撸代码有关的设备都贴上符，保平安
|
 |
5
misaka19000 2019-02-15 15:52:35 +08:00 via Android
靠测试来保证质量
|
 |
6
cnoder 2019-02-15 15:53:42 +08:00
感觉就像一个风中残烛的老人支撑着拐杖往前走，总怕他会在哪跌倒
|
 |
7
richangfan 2019-02-15 15:55:59 +08:00
软件的可用性是由测试保证的，大学里都教过的。
|
 |
8
Kylin30 2019-02-15 16:01:46 +08:00
配发操作手册，严格演练，责任到人。
|
 |
9
orangeChar 2019-02-15 16:06:49 +08:00
写监视程序 写监视监视程序的程序 写监视监视监视程序程序的程序
写备份方案 写备份方案的备份方案 写备份方案的备份方案的备份方案 想好甩锅方案(指甩锅给测试以及用户以及其他人,不包括开发) 想甩锅方案失败的甩锅方案 ~~~~ 完了就多写代码 |
 |
10
jinhan13789991 2019-02-15 16:08:26 +08:00
要么程序简单的没有 bug，要么复杂的到不到 bug
|
 |
11
unicloud 2019-02-15 16:17:48 +08:00
多写多总结
|
 |
12
c466934322 OP @cnoder 同感
|
 |
13
xpresslink 2019-02-15 16:23:16 +08:00
你保证不了。
正经软件公司都会有专业的测试部门和人员，要做功能测试和压力测试。 当你被测试的妹子给怼的不要不要的，不停改 bug 的时候你就提高了。 |
 |
14
tomczhen 2019-02-15 16:23:56 +08:00
对边界情况要保证测试用例覆盖。
可能会超出预期的情况，如果项目时间不足，则需要防御性编程，发生问题可以第一时间定位。 发生过的错误，除了修复，还需要编写对应测试用例。 |
 |
15
saulshao 2019-02-15 16:49:14 +08:00
这个其实就是测试用例，经验指的就是这种事情。
除非有一天我们可以用程序本身来写程序，否则就要依赖于这种失败->修正的循环过程来提高稳定性 |
 |
16
lk920724 2019-02-15 16:56:49 +08:00
一直试错
吧？ |
 |
17
KickAssTonight 2019-02-15 17:24:20 +08:00
代码 review
|
 |
18
cxtrinityy 2019-02-15 17:27:25 +08:00
写之前就做好所有 if else 的情况考虑，同时保证代码的扩展性，写出基础版本后自己测试各种情况，不断迭代，最后由测试来做最后的保证
|
 |
19
xiaoidea 2019-02-15 17:31:59 +08:00
即使你写了很完备的单元测试，你也没法保证不会出现各种运行时异常，数据 /机器 /网络甚至项目中用到的各种 library/middleware 都会导致难以预料的运行时异常。所以要做好日志+监控+报警，亡羊补牢是有必要的
|
 |
20
zlmdaybreak 2019-02-15 17:35:20 +08:00
少考虑场景谁都无法避免，全靠经验。开发前通过 review 方案和结束后的 review 代码是可以帮助减少这种现象。
|
 |
21
Sparetire 2019-02-15 19:14:19 +08:00
普通人靠静态类型的类型检查和单元测试, 巨佬靠形式化验证...
|
 |
22
leekafai 2019-02-15 20:19:55 +08:00 via Android
没做过自然就会没考虑到，多做就行了
|
 |
23
yiyi11 2019-02-15 22:05:46 +08:00 via Android
考虑不到是经验问题。理论方法来提高程序可靠性有很多。但实际上跟需求，设计，架构，工期有很大的关系，具体业务编码只是占很小作用的一部分。
|
 |
24
fish47 2019-02-16 14:33:09 +08:00
我建议加一个限定 -- "在你所见过，或实践过的，并且有所成效的" 。
|
 |
25
vtoee 2019-02-16 17:57:15 +08:00
@xpresslink 谁说测试一定是妹子
|
Select Language