关于驾驶，流传着一些段子：
1. 听到发动机嘶吼声，明明前方拥堵，请躲开，TA一定是想刹车。
2. 开车一路尾随，突然前车雨刮打开了，但是明明是大晴天，那么请注意TA一定是要转弯了。
看完这类段子，你以后再开车大概得这么想：MD，我们永远无法得知其他司机接下来要搞什么鬼，我们得瞪大眼睛保持专注，在他们整出什么危险的幺蛾子的时候，自己能远离伤害。这就是防御性驾驶。
再来看一下前两天发生在我身边的真实故事：
1. 工程师为运维人员搞了一个后台录入网页，前俩天，忽然有人大惊失色的在微信群里叫开了，说前方用户狂抱怨软件爆出大问题，都没法用了，半晌，有一个运维说，WC，下午谁把一个配置项改错了，修改过来就好了。又过了一会，另一个运维说，是他在改A的时候，不慎把B的值错改为A的值了。这一错直接从后台录入页面入库，然后大摇大摆的出入后台API，透过客户端页面，跑到用户面前跳脱衣舞。
2. 一测试人员报告Android客户端出了个问题，工程师听了以后，一通复现，抓log，debug，读源码，分析逻辑，...吭哧吭哧...，末了幽幽的说，客户端没有发现可疑线索，请求服务器联调，...吭哧吭哧...一起又搞了一袋烟功夫，怒了：MD，不应该有问题啊！找来测试人员再确认，哦，搞错了，误报。
这俩个案例，赤裸裸的展现了一个毫无防御的系统～任何一个不小心，意外就可以击穿整个系统，还有一个毫无防御能力的组织（成员）或者说是没有防御能力的流程，一个误报的信息，就可以牵动整个工作流水线的人员。
《Code Complete》有专门章节讲述软件构建过程中，编程阶段的防御，类似于驾驶，我们要确保无效的数据，事件，以及其他人的失误不会把自己卷进去，先苟活于这个冰冷，惨淡的世界，然后才可能去谈远方和诗。
第一个要做的就是拯救自己于无效的输入，所有来自外部的数据的值都检查，函数的所有入参的值都检查，明确如何处理不好的参数。
其次是用Assert断言，开发过程中，再运行时进行程序自检，一旦有检测项被打破，立刻挂起程序。
再次有一些实用的错误处理技术，可以直接选出来拿到项目里去用。
然后是异常机制的用法。
最后介绍实际部属防御体系的实践。
