这几天读了《程序员修炼之道：从小工到专家》这本书的第三、四、五章的内容。
在第三章强调要接受事实：调试就是解决问题，要据此发起进攻。
我过去是怎么做的？自己以前很抵触调试，因为觉得调试特别麻烦，比如写一篇博客需要两个小时吧，调试却整整需要花上一天都不一定能够改完所有的bug。
结合书中所讲，说明为什么这样不好？这种心态很不好，抵触的情绪与心理只会让你事倍功半。
提出一个解决办法，避免再次掉入陷阱？首先应该学会接受事实，而不是逃避。在发现了别人的bug之后，不是一味地花费时间和精力去指责让人厌恶的肇事者，而是应该专注于修正问题。
第四章讲解了关于异常的问题之一是知道何时使用它们。异常很少作为程序的正常流程的一部分使用，异常应保留给意外事件。比如代试图打开一个文件进行读取，而该文件并不存在，应该引发异常吗？这取决于实际情况。如果文件应该在那里，那么就返回异常；如果不确定该文件是否存在，就应该返回错误。
我们要将异常勇于处理异常的问题。如果将异常用于正常处理的一部分的程序，那么就会影响可读性和可维护性，破坏了封装。
只要是编程，我们都要管理资源：内存、事务、线程、文件、定时器——所有数量有限的事物。大多数时候，资源使用遵循一种可预测的模式：你分配资源、使用它，然后解除其分配。但是对于资源的分配和解除许多开发者没有始终如一的计划。所以要做到要有始有终。对于资源，使用了就一定要记得关闭，我发现自己总是忘了用close关掉，结果自己的程序总是有很多警告，这样很不好，应该有开有关，有始有终才对。
第五章是说将抽象放进代码，细节放进元数据。细节会弄乱我们整洁的代码，尤其是如果它们经常变化，甚至会破环系统，引入新的bug。但是如果我们将细节放进元数据，可以迫使我们通过推迟细节处理，创建更健壮、更抽象我们需要容许并发，并考虑解除任何时间或次序上的依赖。这样做我们可以获取更多灵活性，并减少许多开发领域中的任何基于时间的依赖：工作流分析、架构、设计、还有部署。这段话提示我们设计时要考虑并发，到时候我们就可以更容易的满足可伸缩性或性能需求，也要考虑解除任何时间或次序上的依赖，以获取更多的灵活性。