修改软件是危险的。在复杂的逻辑过程中，每一次修改都可能使潜在的错误增加。设计文档和细心的回归测试有助于消除错误，但仍然不可避免地出现维护的副作用。
修改代码的副作用
　　对于一个简单语句做一个简单的修改，有时都可能遭致灾难性的结局。虽然不是所有的副作用都有严重的后果，但修改容易招致错误，而错误经常造成各种问题。
　　使用程序设计语言修改源代码时，可能会引入错误，下述修改更容易引入错误：

　　修改代码的副作用，一般可在回归测试过程中对其造成软件故障的问题进行查明和改正。再一次强调Murphy的法则：如果一个源语句进行一个修改，它将可能导致新的错误。

修改数据的副作用
　　数据结构在软件设计中具有重要性。维护时，经常要对数据结构的个别元素或结构本身进行修改。当数据改变时，原有的软件设计可能对这些数据不再适用从而产生错误。数据的副作用产生于对软件数据结构的修改。
　　修改数据的副作用经常发生在下述的一些数据修改中：

　　完善的设计文档可以限制数据的副作用。这种文档描述了数据结构，并提供了一种将数据结构、记录、文件和其他结构与软件模块联系起来的交叉对照表。

修改文档的副作用
　　维护应该着眼于整个软件配置，而不只是源代码的修改。如果源代码的修改没有反映在设计文档或用户手册中，就会产生文档的副作用。
　　对数据流、设计体系结构、模块过程或任何其他有关特性进行修改时，必须对其支持的技术文档进行更新。设计文档不能正确地反映软件的当前状态，可能比完全没有文档更坏，因为在以后的维护工作中阅读这些技术文档时，将导致对软件特性的不正确评价，这样就会产生文档的副作用。
　　对用户来说，软件应该与描述它的用法的文档一样好。如果对可执行软件的修改没有反映在文档上，肯定会有副作用。例如，对交互式输入或格式的修改，若没有恰当地反映在文档上，可能会引起严重的问题。新的无文档错误信息可能导致人们摸不清头脑，这时的内容、索引和文本会使用户不便或不满。
　　在软件再次交付使用前，对整个软件配置进行评审将能大大减少文档的副作用。实际上，某些维护申请只是指出用户文档不够清楚，并不要求修改软件设计或源代码，此时只对文档进行维护即可。
维护"奇异码"
　　几乎每个成熟的软件开发机构都要维护15年或更多年以前开发的程序，这样的程序有时称作"奇异码"。其原因在于：
　　（1） 现在的技术人员中没有人曾经参与该程序的开发工作；
　　（2） 过去没有开发规范可用，因此数据和体系结构设计都有很大的差异；
　　（3） 文档不完整，修改记录简略。
Yourdon对维护"奇异码"的建议是：
　　（1） 在陷入"紧急状态"之前，研究该程序，力求得到尽可能多的背景知识；
　　（2） 力求熟悉该程序的整个控制流，先不管程序代码的细节。如果没有结构图或高层流程图，可以自己把它画出来，这是很有用的。
　　（3） 分析和评价现有文档的合理性，如果认为在源代码中有必要插入自己的注释时，那么就这么做。
　　（4） 充分使用由编译程序或汇编程序提供的交叉引用对照表、符号表以及其他说明；
　　（5） 要特别小心地进行程序的修改，如果可能的话，要考虑程序的风格和格式，要在程序清单上注出哪些指令已经做了修改；
　　（6） 除非确信该代码不再使用，一般不要删除它；
　　（7） 在插入自己的变量时，不要为了省事而共享程序中已有的临时变量和工作存储区；
　　（8） 保存维护活动及其结果的详细记录；
　　（9） 应避免抛弃该程序并重写该程序的不合理主张；
　　（10） 可插入错误检查。
　　上述各条原则都有助于"老"程序的维护，但是，如果有这样的程序，它的控制流图十分混乱，如一个模块有2000条语句，或在9000条语句中只有三条有意义的注释，而且再没有其他软件配置元素了，很难相信这样的程序已经工作好多年。但当要求对它们进行维护时，这样的任务是难以完成的。