个人感受部分：

　　01.不注重重构代码，软件测试的时候总是避开bug走，不愿意面对bug。

　　02.用更深的理解，变化的需求进行重新设计的软件会更加优秀。在软件通过所有可用的测试之前，你不能声称它可以使用。

　　03.学会重构自己的代码，追求更好的体验，认真的进行软件测试，自助找出bug，以防后续出现问题。

　　读后感：

　　关于重构，很多书都提到，我读的前一本名著《梦断代码》也对重构这方面有着很详细的讲解。但是这本书的作者似乎有更深层的理解。随着程序的演化，我们有必要重新思考早先的决策，并重写部分代码，这一过程非常自然，代码需要演化，它不是静态的事物。软件与建筑相比，软件更像是园艺——它比混凝土更有机。你根据最初的计划和各种条件在花园里种植许多花木，你不短关注着花园的兴旺，并按照需要作出调整。

　　重写、重做和重新架构代码合起来，称为重构。那么我们该在什么时候进行重构呢？当你遇到绊脚石——代码不再合适，你注意到有两样东西其实应该合并或是其他任何对你来说是“错误”的东西，那么你不要对改动犹豫不决，应该现在就做。但往往现实世界特别复杂，当你去找你的老板和客户，对他们说：“这些代码能工作，但我需要再用一周时间重构它”，你猜猜他们会怎么回答？时间压力常常被用作不进行重构的借口，但是这个借口并不成立：现在没能进行重构，沿途修正问题将投入多得多的时间——那时将需要考虑更多的依赖关系。我们会有更多的时间可用吗？

　　就其核心而言，重构就是重新设计。你或者你们团队的其他人设计的任何东西都可以根据新的事实，更深的理解，变化的需求进行重新设计。但如果你无节制的撕毁大量代码，你看可能发现自己处于比一开始更糟糕的位置上。显然，重构是一项需要慎重、深思熟虑、小心进行的活动。关于怎样进行利大于弊的重构，作者给出了以下提示：1.不要试图在重构的同时增加功能。2.在开始重构之前， 确保你拥有良好的测试。尽可能经常进行这些测试。这样，如果你的改动破坏了任何东西，你就能很快知道。3.采取短小，深思熟虑的步骤。如果你使你的步骤短小，并在每个步骤之后进行测试，你将能够避免长时间的调试。

　　这学期大部分大作业都是团队完成，不管是两人合作还是三人四人小组，都可以叫做团队。作者在最后一章，简要的考查怎么样把各种注重实效的技术应用于作为整体团队，这些说明只是一个起点。质量是一个团队问题，如果团队主动鼓励开发者不要把时间花费在这样的修正上，问题就会进一步恶化。显然，团队中的开发者必须相互交谈。之前作者谈过交流的问题，但是人们很容易忘记，团队本身也存在于更大的组织中，团队作为实体需要同外界明晰的交流。对外界而言，看上去沉闷寡言的项目团队是最糟糕的团队，他们举行无章次的会议，在会上没有人想说话，他们的文档混乱；没有两份文档有相同的外观，每一份都使用不同的术语。

　　确保一致和准确的一种很好的方式是使团队所做的每件事情自动化，如果你编辑器能够自动在你输入时安排代码的布局，为什么要手工进行呢？如果夜间构建能够自动运行各种测试，为什么要手工完成测试表单呢？许多开发团队用内部网站来进行项目交流、我们认为这是一个很好的想法，但我们不想花太多时间维护网站，也不想让它变得陈旧和过时。

　　软件测试必不可少，但对于我或者大多数开发者来说，我们都讨厌测试。大家往往温和的测试，下意识的知道代码会在那里出问题，并且避开那些薄弱的地方。注重实效的程序员与此不同，我们收到驱迫，现在就要找到我们的bug，以免以后经受由别人找到我们bug所带来的羞耻。一旦我们有了代码，我们就想开始测试。许多团队会为他们的项目精心制定测试计划。有时他们甚至会使用这些计划。但我们发现，使用自动测试的团队成功的机会会大很多。你写出了一段代码，并不意味着你可以告诉你的老板或者客户，说它已经完成，不是这样。首先，代码从不会真正完成，更重要的是，在它通过所有可用的测试之前，你不能声称它可以使用。