程序员在软件优化中有个通病，就像身在山中，当局者迷一样。如果你能意识到优化是必不
可少且很重要的，你就应当试着用它。软件优化的中心规则是提高程序的内在质量，下面是几
条原则:
[SHADOW=255,RED,2]多设计子程序 [/SHADOW]
提高程序质量的一条标准就是模块化；多设计些好的子程序。程序中有变化时，模块化就方
便得多。如果程序中某一段编成子模块会使之更清晰，就再划出子模块。这一点在 30.3 节“编
制新子程序”中详细讨论。
[SHADOW=255,RED,2]减少全局变量 [/SHADOW]
当你用到程序中的全局变量时，注意检查一下它们。在编过某段程序后，你可能想出避免再
用到某全局变量的方法。在刚开始设计程序时，可能你容易弄混全局变量；这样，你希望用更
简洁的方案。你也可能因为忘记分离全局变量而备受其苦，应该将它们局限在分段的程序中，
吃一堑长一智吧。只要你记得那些应该修订的部分就行了。应指出修改程序应在最初几版进行，
这时最合适。
[SHADOW=255,RED,2]改进你的编程风格 [/SHADOW]
当你回过头来修改时，正是整理变量、旧布局注释的好机会，此时记住把一切好的编程风格
都用上。
[SHADOW=255,RED,2]改变管理[/SHADOW]
编程中你可能遇到新的要求及改错方案，使得你得修改代码。如果你改完程序而跟你的改动
无关的新错出现了，你就会想到比较新旧两版进而找出错误之源。要是这不奏效，大概你就倾
向于用老版本了。你可以使用版本控制工具，跟踪多版源程序来达到比较版本的目的。在第二
十二章，结构管理一节中，有详尽的讨论。
[SHADOW=255,RED,2]重审修订后的程序[/SHADOW]
如果一次重审显得很重要，就更有第二次的必要，Ed Yourdon 说，程序员在初次编程时，
要作50％以上的修改。有趣的是，如果程序员针对一大段程序而不是仅仅几行着手工作，要作
修改的机会就大得多。特别地，当修改的行数从一行变为5 行，是越改越糟的可能性也大了。
在这以后，改坏的可能就小了。
程序员小心地进行着修改。他们不应仅在办公室上修改程序。而应当试着运行一下来检证工
作是否有效。
规则很简单，像对付复杂改动那样对付简单改动，有一个组织作过研究，审核前后错误率可
能由55％降到2％。
[SHADOW=255,RED,2]重测试[/SHADOW]
应当用测试来验证修改的效果。在二十五章中，这种回归测试有详尽描述。Gerald Werberg
说，十个最昂贵的编程错误都涉及修改现存的程序。最贵的几个每个都值上千万美元，尽管
只需改动一行。
[SHADOW=255,RED,2]软件优化的哲学 [/SHADOW]
优化既是危险的又是趋向完善的机会，当你作了改动时，力图使以后修改变得更容易。在
刚开始设计时，你可能不会想到遗留的问题有多少。有机会修改程序时，就尽你所学去做。在
头脑中记住你的源程序及所做的修改。

出自《代码大全》