这是一个创建于 2704 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近做 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 div class="badges"> 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