总是会有一些情况考虑不到，所以出现 error，总是会自责不已，然后修复 bug。每次开发前总是想着要把场景想好，但是每次都是会漏掉一些场景，导致一些错误情况出现。求大佬分享技能
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2818 days ago, the information mentioned may be changed or developed.
 |
hhyvs111Feb 15, 2019
1
写多了就行了
|
 |
xcolderFeb 15, 2019
2
单元测试
|
 |
jdguiFeb 15, 2019
3
调整心态。
只需要在心里骂，什么傻逼用户这么用软件的。就完事 |
 |
4
电脑、显示器、键盘、鼠标一切和撸代码有关的设备都贴上符，保平安
|
1 |
misaka19000Feb 15, 2019 via Android
5
靠测试来保证质量
|
 |
cnoderFeb 15, 2019
6
感觉就像一个风中残烛的老人支撑着拐杖往前走，总怕他会在哪跌倒
|
 |
richangfanFeb 15, 2019
7
软件的可用性是由测试保证的，大学里都教过的。
|
 |
Kylin30Feb 15, 2019
8
配发操作手册，严格演练，责任到人。
|
 |
orangeCharFeb 15, 2019
9
写监视程序 写监视监视程序的程序 写监视监视监视程序程序的程序
写备份方案 写备份方案的备份方案 写备份方案的备份方案的备份方案 想好甩锅方案(指甩锅给测试以及用户以及其他人,不包括开发) 想甩锅方案失败的甩锅方案 ~~~~ 完了就多写代码 |
 |
jinhan13789991Feb 15, 2019
10
要么程序简单的没有 bug，要么复杂的到不到 bug
|
 |
unicloudFeb 15, 2019
11
多写多总结
|
 |
12
@cnoder 同感
|
 |
xpresslinkFeb 15, 2019
13
你保证不了。
正经软件公司都会有专业的测试部门和人员，要做功能测试和压力测试。 当你被测试的妹子给怼的不要不要的，不停改 bug 的时候你就提高了。 |
 |
tomczhenFeb 15, 2019
14
对边界情况要保证测试用例覆盖。
可能会超出预期的情况，如果项目时间不足，则需要防御性编程，发生问题可以第一时间定位。 发生过的错误，除了修复，还需要编写对应测试用例。 |
 |
saulshaoFeb 15, 2019
15
这个其实就是测试用例，经验指的就是这种事情。
除非有一天我们可以用程序本身来写程序，否则就要依赖于这种失败->修正的循环过程来提高稳定性 |
 |
lk920724Feb 15, 2019
16
一直试错
吧？ |
 |
KickAssTonightFeb 15, 2019
17
代码 review
|
 |
cxtrinityyFeb 15, 2019
18
写之前就做好所有 if else 的情况考虑，同时保证代码的扩展性，写出基础版本后自己测试各种情况，不断迭代，最后由测试来做最后的保证
|
 |
xiaoideaFeb 15, 2019
19
即使你写了很完备的单元测试，你也没法保证不会出现各种运行时异常，数据 /机器 /网络甚至项目中用到的各种 library/middleware 都会导致难以预料的运行时异常。所以要做好日志+监控+报警，亡羊补牢是有必要的
|
 |
zlmdaybreakFeb 15, 2019
20
少考虑场景谁都无法避免，全靠经验。开发前通过 review 方案和结束后的 review 代码是可以帮助减少这种现象。
|
 |
SparetireFeb 15, 2019
21
普通人靠静态类型的类型检查和单元测试, 巨佬靠形式化验证...
|
 |
leekafaiFeb 15, 2019 via Android
22
没做过自然就会没考虑到，多做就行了
|
 |
yiyi11Feb 15, 2019 via Android
23
考虑不到是经验问题。理论方法来提高程序可靠性有很多。但实际上跟需求，设计，架构，工期有很大的关系，具体业务编码只是占很小作用的一部分。
|
 |
fish47Feb 16, 2019
24
我建议加一个限定 -- "在你所见过，或实践过的，并且有所成效的" 。
|
 |
vtoeeFeb 16, 2019
25
@xpresslink 谁说测试一定是妹子
|
Select Language