这又得提我强调的一句话了“软件是用来改的，而不是用来跑的”。软件工程项目不同于学生大作业的地方在于，学生的大作业写完之后，跑起来给老师看一把就完了。可是软件工程项目不同，让软件系统跑起来那才是噩梦的开始，而不是结束。为什么这么说呢？因为在软件跑起来的那一刻，注定了软件的运行已经不是重点了，而功能的扩容和实际运行中的bug才是接下来的重点。而在已经运行的庞大软件系统面前，这种任何一点点小的变动就足以让开发人员崩溃。这就是软件噩梦的第二个方面——修改难度大。
所有的东西都是小而简的时候难度不大，复杂往往伴随着庞大而产生。软件的修改和变更是存在于整个软件生命周期的。在软件项目的开发初期，修改是存在的，不过这个时候大多数修改不会产生多大影响，并且很多时候这个阶段的修改都不被认为是修改，而是属于正常的开发重构工作。修改代码的人分为两类，一类是修改自己代码的人，一类是修改他人代码的人。这两类人的痛苦程度看似有区别，其实区别并不是很大。修改自己代码的人，在开发初期，也就是代码量少的时候，修改很容易。第一，代码非常的熟悉，第二，项目代码量少，影响域很小。但是随着项目阶段的不断进行，这种困难就会不断的增加，并且大多数时候它不是线性增加的。很可能多写一行代码，其修改困难就会增加很多。为什么？因为第一，在项目代码量大的时候，你不可能非常清楚自己所有的代码，这就跟你不可能记住你所说的每句话一样。第二，代码量大的时候，不同代码之间的联系就会非常多，这就导致修改一行代码都是非常小心的事情。
归根结底，代码修改难度大的原因有很多，但是主要原因在于如下的两点：
第一， 难以读懂导致不容易修改。要修改一段软件项目中大代码，首先要做的就是要读懂代码。这种读懂表现在代码结构上，代码所表示的业务逻辑上，代码所蕴含的算法和规则等。软件项目是一个团队的产物，不是一个人的成果。所以在读懂代码的时候，就代码本身很多时候都是让人很困惑的。而这一切根源在前一节的代码不可读中已经分析过了。
第二， 代码耦合太强导致不敢修改。软件项目后期，尤其是系统上线之后的修改，是非常困难并且需要特别小心的一件事情。而代码修改的难度是随着项目的阶段进行而不断的增加的。尤其是设计不周，随心所欲写的代码，这样的代码到处都有联系，没有设计的随便复用，更有甚者代码片段的复制粘贴，这些坏的习惯都是给后面的修改种下的恶果。也许后面修改的人和前面写的人不是一个，这样的情况更是让人痛苦的一件事情。不管从质量上，还是从效率上来说，这种其实可以避免的事情都会给项目增加巨大的风险。随处耦合的代码，在修改的时候，让修改的开发人员往往不知道从何处开始修改。开发人员在修改的准备阶段首先要做的就是读懂代码，找出影响域。可是往往在这个阶段就足以让修改的开发人员望代码而兴叹了。因为当他读懂了代码之后，不是高高兴兴的去修改了，而是突然觉得即使读懂了又如何，读懂了之后的唯一收获就是，让他觉得这个代码无法修改而已。不过最后在经理和各方的压迫之下，也许开发人员选择的妥协，在这个已经烂的代码上补补让其更烂。
为了方便修改，全文的权威地址请猛击 http://blog.sina.com.cn/s/blog_4a2100f801013mko.html