《修改代码的艺术》读书笔记一

1、修改软件的原由及其本质。

       修改软件是任何一个开发人员所面对的问题，软件是否容易修改，被修改后的软件是否变得更好，是每个开发人员都知道必须关注可是在实际开发过程当中却每每忽视的问题。有多少人在接手一个新项目时抱怨新项目的遗留代码质量过低？又有多少人愿意或者说有能力去将一个让人崩溃的代码逐步改善？    

　　假如你面对着一份只能考虑修改，不能考虑重写的，可是混乱不堪的代码，须要将其逐步改善，可能须要细致的研究《修改代码的艺术》这本书，它的目的就在于：但愿可以将一个已经很是庞大并且混乱不堪的项目从现状中摆脱出来，让为这个程序作开发的人员对开发感到安心，而不是担心。    

　　这里从书中列出的软件修改的四个主要原由开始：  

　　　　1.添加新特性。  

　　　　2.修正bug。  

　　　　3.改善设计。  

　　　　4.优化资源使用。    

　　添加新特性和修正bug的含义不难理解，可是有时候由于对需求的理解不一样，表面上看上去是修正bug的行为实际对于开发人员来讲确实添加一个新特性。关于这一点，这里把这样一种行为划分到添加新特性的范围中，而不认为是修正bug。    

　　改善设计指的是改变程序的结构，令软件更加容易维护，一般也意味着，咱们但愿改善设计的过程当中不该该改变程序的行为。这种不改变程序行为而改善设计的举动称为重构。（书中指出重构背后的理念：若是咱们编写测试确保现有行为不变，并在重构的每一步中当心验证其行为的不变性，咱们就能够在不改变程序行为的前提下经过重构使其更具维护性）    

　　优化和重构相似，可是目的却不一样，重构的目标是程序的结构更容易维护，而优化的目标倒是针对程序所使用的资源，好比CPU时间和内存占用等。    

　　通常而言，当对一个系统作修改以后，有三个方面可能会发生改变：结构、功能以及资源占用。为了把上述的bug修改和添加新特性区分出来，咱们把功能也分为对旧有功能的修改和新功能。因而综合起来，咱们能够获得一个表格：

	添加特性	修正bug	重构	优化
结构	改变	改变	改变	——
新功能	改变	——	——	——
功能	——	改变	——	——
资源使用	——	——	——	改变

　　固然，准确来讲，前三种举动也可能会致使资源使用的改变，可是因这三种状况下资源使用的变化每每只是反作用，因此表中仍是列为不变。    

　　在这全部的状况里面，有一点是很是重要的：咱们对程序的改动相比咱们但愿保持的程序行为相比，咱们但愿保持的程序行为要多得多。因此在对程序修改中，如何保证不致使不想改变的东西被改变，是重中之重。

2、修改中存在的问题

　　对大部分的开发人员来讲，通常并不肯意对软件进行修改。有了新的需求，须要添加新特性；有了bug，须要作修正；这样的修改不得不作。可是改善设计提升维护性，大部分人是不肯意的作的。    

　　为何会这样？固然不是由于开发人员懒，那么多的代码都写了，没道理不肯意为了之后维护方便，多写一些。关键在于，咱们都担忧只是为了改善结构的修改行为，对系统形成了严重的破坏。    

　　“避免修改”算是咱们对于已经跑在线上的程序的一种下降软件问题的策略。“既然跑的好好的，那仍是别改了”。若是一个程序永远不用改动，那或许这种策略有必定的可行性。可是，除非对于一个已死的项目，改动老是不可避免的。当团队每次都以看上去最简单的方式将新代码添加到系统中，原有的方法、原有的类就会愈来愈庞大，修改的难度也会愈来愈大，最终形成质量不断下滑。