修改代码的艺术读后感1
一、修改软件的起因及其本质。
修改软件是任何一个开发人员所面对的问题，软件是否容易修改，被修改后的软件是否变得更好，是每一个开发人员都知道必须关注但是在实际开发过程中却往往忽视的问题。有多少人在接手一个新项目时抱怨新项目的遗留代码质量太低？又有多少人愿意或者说有能力去将一个让人崩溃的代码逐步改善？
假如你面对着一份只能考虑修改，不能考虑重写的，但是混乱不堪的代码，需要将其逐步改善，可能需要细致的研究《修改代码的艺术》这本书，它的目的就在于：希望能够将一个已经非常庞大而且混乱不堪的项目从现状中摆脱出来，让为这个程序做开发的人员对开发感到安心，而不是担忧。
这里从书中列出的软件修改的四个主要起因开始：
1.添加新特性。
2.修正bug。
3.改善设计。
4.优化资源使用。
添加新特性和修正bug的含义不难理解，但是有时候因为对需求的理解不同，表面上看上去是修正bug的行为实际对于开发人员来说确实添加一个新特性。关于这一点，这里把这样一种行为划分到添加新特性的范围中，而不认为是修正bug。
改善设计指的是改变程序的结构，令软件更加容易维护，通常也意味着，我们希望改善设计的过程中不应该改变程序的行为。这种不改变程序行为而改善设计的举动称为重构。（书中指出重构背后的理念：如果我们编写测试确保现有行为不变，并在重构的每一步中小心验证其行为的不变性，我们就可以在不改变程序行为的前提下通过重构使其更具维护性）
优化和重构类似，但是目的却不同，重构的目标是程序的结构更容易维护，而优化的目标却是针对程序所使用的资源，比如CPU时间和内存占用等。
一般而言，当对一个系统做修改之后，有三个方面可能会发生改变：结构、功能以及资源占用。为了把上述的bug修改和添加新特性区分出来，我们把功能也分为对旧有功能的修改和新功能。于是综合起来，我们可以得到一个表格：
| 添加特性 | 修正bug | 重构 | 优化 | |
| 结构 | 改变 | 改变 | 改变 | —— |
| 新功能 | 改变 | —— | —— | —— |
| 功能 | —— | 改变 | —— | —— |
| 资源使用 | —— | —— | —— | 改变 |
当然，准确来说，前三种举动也可能会导致资源使用的改变，但是因这三种情况下资源使用的变化往往只是副作用，所以表中还是列为不变。
在这所有的情况里面，有一点是非常重要的：我们对程序的改动相比我们希望保持的程序行为相比，我们希望保持的程序行为要多得多。所以在对程序修改中，如何保证不导致不想改变的东西被改变，是重中之重。
二、修改中存在的问题
对大部分的开发人员来说，一般并不愿意对软件进行修改。有了新的需求，需要添加新特性；有了bug，需要做修正；这样的修改不得不做。但是改善设计提高维护性，大部分人是不愿意的做的。
为什么会这样？当然不是因为开发人员懒，那么多的代码都写了，没道理不愿意为了以后维护方便，多写一些。关键在于，我们都担心只是为了改善结构的修改行为，对系统造成了严重的破坏。
“避免修改”算是我们对于已经跑在线上的程序的一种降低软件问题的策略。“既然跑的好好的，那还是别改了”。如果一个程序永远不用改动，那或许这种策略有一定的可行性。但是，除非对于一个已死的项目，改动总是不可避免的。当团队每次都以看上去最简单的方式将新代码添加到系统中，原有的方法、原有的类就会越来越庞大，修改的难度也会越来越大，最终造成质量不断下滑。
参考资料：
