这是一个创建于 2434 天前的主题，其中的信息可能已经有所发展或是发生改变。
总是会有一些情况考虑不到，所以出现 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