这段时间阅读了《代码大全》这本读物。
首先阅读的是第八章——防御式编程。
该章的重要内容如下：
1. 最终产品代码中对错误的处理方式要比“垃圾进，垃圾出”复杂的多。
2. 防御式编程技术可以让错误更容易发现、更容易修改，并减少错误对产品代码的破坏。
3. 断言可以帮助人尽早发现错误，尤其是在大型系统和高可靠性的系统中，以及快速变化的代码中。
4. 关于如何处理错误输入的决策是一项关键的错误处理决策，也是一项关键的高层设计决策。
5. 异常提供了一种与代码正常流程角度不同错误处理手段。如果留心使用异常，它可以称为程序员们知识工具箱中的一项有益补充，同时也应该在异常和其他错误处理手段之间进行权衡比较。
6. 针对产品代码的限制并不适用于开发中的软件。你可以利用这一优势在开发添加有助于更快地排查错误的代码。
目前我的体会是，使用断言更容易地找到代码错误的位置，这一点大一时老师就教授了我们，然后大二时使用过一些异常，但是对这方面还是并不熟悉，异常也是经常使用的，以后也要多多学习和使用异常处理；在开发添加有助于更快地排查错误的代码方面应用也是很广阔的，目前我使用最多的是输出语句，这语句虽然简单，但是排查效果确实好，不仅可以帮助我很快的找到错误，也能让我对自己代码的思路更加了解 。
然后重要的一点是确定在产品代码中保留多少防御式代码
1. 保留那些检查重要错误的代码
2. 去掉检查细微错误的代码
3. 去掉可以导致程序硬性崩溃的代码
4. 保留可以让程序稳妥地崩溃的代码
5. 为你的技术支持人员记录错误信息
6. 确认留在代码中的错误消息是友好的
目前我的代码冗余很严重，可能是受编程水平的影响，这一点我也是感触颇深，比如我的程序中有许多的代码都是重复或者是没用的。在某种程度上来说，代码越多其实思路就越混乱；另一方面也是老师经常教导我们的，要注意代码的重构，记得有次课堂测试就是将上一次的代码重新组装一下，然而有许多的同学到下课也没有能够完成，毫无疑问，他们的思路绝对是混乱的，所以我们一定要注意代码的重构，老师说的一句话对我影响很深，他说：“一个方法只实现一个功能，主函数代码不能超过10行”。
而下面也是我们要时刻检查自己的程序代码的：
一般事宜
· 子程序是否保护自己免遭有害输入数据的破坏？
· 你用断言来说明编程假定吗？其中包括了前条件和后条件吗？
· 断言是否只是用来说明从不应该发生的情况？
· 你是否在架构或高层设计中规定了一组特定的错误处理技术？
· 你是否在架构或高层设计中规定了是让错误处理更倾向于健壮性还是正确性？
· 你是否建立了隔栏来遏制错误可能造成的破坏？是否减少了其他需要关注错误处理的代码的数量？
· 代码中用到的辅助调试的代码了吗？
· 如果需要启用或禁用添加的辅助助手的话，是否无须大动干戈？
· 在防御式编程时引入的代码量是否适宜——既不过多，也不过少？
· 你在开发阶段是否采用了进攻式编程来使错误难以被忽视？
异常
· 你在项目中定义了一套标准化的异常处理方案吗？
· 是否考虑过异常之外的其他替代方案？
· 如果可能的话，是否在局部处理了错误而不是把它当成一个异常抛到外部？
· 代码中是否避免了在构造函数和析构函数中抛出异常？
· 所有的异常是否都与抛出它们的子程序处于同一个抽象层次上？
· 每个异常是否都包含了关于异常发生的所有背景信息？
· 代码中是否没有使用空的catch语句？（或者如果使用空的catch语句确实很合适，那么明确说明了吗？）
安全事宜
· 检查有害输入数据的代码是否也检查了故意的缓冲区溢出，SQL注入、HTML注入、整数溢出以及其他恶意输入数据？
· 是否检查了所有的错误返回码？
· 是否捕获了所有异常？
· 出错消息中是否避免出现有助于攻击者攻入系统所需的信息