这是一个创建于 2360 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近做 OJ 题，发现自己在考虑程序边界条件的能力过于薄弱，很多特殊情况没有考虑到，导致程序通过率较低。
回想起工作中，也会经常漏掉一些特殊情况。程序的使用者并不会像自己想的那么老老实实地输入，于是线上会经常因为这种原因报出问题（公司并没有完整的测试体系），于是曾经和同事戏谑：一定要把每个用户当傻子来看待才能开发出稳健的程序。
但对于现在我的水平来说，非常难以考虑周全，而且开发周期也不允许花太多时间在这个上面。对于这种问题，大家有没有系统的解决方案呢？
 |
1
night98 2018-05-18 16:28:25 +08:00 via Android
多写多脸
|
|
2
night98 2018-05-18 16:28:37 +08:00 via Android
练
|
 |
3
young7657 2018-05-18 16:30:22 +08:00
不停完善边界情况，一步到位很难吧
|
 |
4
ray1888 2018-05-18 17:38:20 +08:00
tdd? 我觉得可能会有帮助
|
 |
5
Luckyray 2018-05-18 17:48:30 +08:00 via iPhone
经验吧，我写 oj 就从来没一次通过过……
|
 |
6
Building 2018-05-18 18:40:43 +08:00 via iPhone
要么让它崩溃，至少知道错在哪里，如果检查参数一定要有打印和说明，否则默默帮你 Handle 掉了特殊情况一环套一环你的代码就莫名其妙跑到了未知区域...
|
 |
7
jamesxu 2018-05-18 19:18:30 +08:00 via iPhone
多思考+流程图
|
 |
8
TWalker 2018-05-18 19:45:55 +08:00 via iPhone
多思考
函数开头先处理异常情况，考虑参数是否合法； |
 |
9
MinQ 2018-05-18 23:18:04 +08:00
写单元测试，错数据统统塞进去
|
 |
10
cxbig 2018-05-18 23:56:24 +08:00
经验为主，但不要一开始就想得太多。靠反馈和迭代逐步完善。
|
 |
11
huangdaxian OP @ray1888 在我们这种业务性公司，TDD 是不现实的
|
 |
12
hirra 2018-05-19 15:33:57 +08:00
流程图，思维导图
|
|
13
huangdaxian OP 这几天看了一些文章，有的说业务代码里非业务的边界不应该有任何检查，全部由外层调用者自己控制，也有的说程序的每一层都需要进行检测，并且对异常进行封装，确保对异常的掌控性。
对于我来说，最纠结的点在于有些程序的边界并不常见，而效验这些边界需要较高的计算成本，如果这段程序每次执行时都进行检查，可能会成倍地降低效率，并且开发成本也是相应地提高的（相当费脑）。 |
Select Language