92＇。上述调查已是20年前的事了，我们不必太关心具体的比例，心里有数即可。
以下一些因素将导致维护工作变得困难：
（1）软件人员经常流动，当需要对某些程序进行维护时，可能已找不到原来的开发人员。只好让新手去“攻读”那些程序。
（2）人们一般难以读懂他人的程序。在勉强接受这类任务时，心里不免嘀咕：“我又不是他肚子里的虫子，怎么知道他如何编程。”
（3）当没有文档或者文档很差时，你简直不知道如何下手。
（4）很多程序在设计时没有考虑到将来要改动，程序之间相互交织，触一而牵百。即使有很好的文档，你也不敢轻举妄动，否则你有可能陷进错误堆里。
（5）如果软件发行了多个版本，要追踪软件的演化非常困难。
（6）维护将会产生不良的副作用，不论是修改代码、数据或文档，都有可能产生新的错误。
（7）维护工作毫无吸引力。高水平的程序员自然不愿主动去做，而公司也舍不得让高水平的程序员去做。带着低沉情绪的低水平的程序员只会把维护工作搞得一塌糊涂。
8。2 维护的代价及其主要因素
软件维护是既破财又费神的工作。看得见的代价是那些为了维护而投入的人力与财力。而看不见的维护代价则更加高昂，我们称之为“机会成本”，即为了得到某种东西所必须放弃的东西＇Mankiw 1999＇。把很多程序员和其它资源用于维护工作，必然会耽误新产品的开发甚至会丧失机遇，这种代价是无法估量的。
影响维护代价的非技术因素主要有：
（1）应用域的复杂性。如果应用域问题已被很好地理解，需求分析工作比较完善，那么维护代价就较低。反之维护代价就较高。
（2）开发人员的稳定性。如果某些程序的开发者还在，让他们对自己的程序进行维护，那么代价就较低。如果原来的开发者已经不在，只好让新手来维护陌生的程序，那么代价就较高。
（3）软件的生命期。越是早期的程序越难维护，你很难想像十年前的程序是多么的落后（设计思想与开发工具都落后）。一般地，软件的生命期越长，维护代价就越高。生命期越短，维护代价就越低。
（4）商业操作模式变化对软件的影响。比如财务软件，对财务制度的变化很敏感。财务制度一变动，财务软件就必须修改。一般地，商业操作模式变化越频繁，相应软件的维护代价就越高。
影响维护代价的技术因素主要有：
（1）软件对运行环境的依赖性。由于硬件以及操作系统更新很快，使得对运行环境依赖性很强的应用软件也要不停地更新，维护代价就高。
（2）编程语言。虽然低级语言比高级语言具有更好的运行速度，但是低级语言比高级语言难以理解。用高级语言编写的程序比用低级语言编写的程序的维护代价要低得多（并且生产率高得多）。一般地，商业应用软件大多采用高级语言。比如，开发一套Windows环境下的信息管理系统，用户大多采用Visual Basic、Delphi或Power Builder来编程，用Visual C＋＋的就少些，没有人会采用汇编语言。
（3）编程风格。良好的编程风格意味着良好的可理解性，可以降低维护的代价。
（4）测试与改错工作。如果测试与改错工作做得好，后期的维护代价就能降低。反之维护代价就升高。
（5）文档的质量。清晰、正确和完备的文档能降低维护的代价。低质量的文档将增加维护的代价（错误百出的文档还不如没有文档）。
8。3 再生工程
再生工程主要出于如下愿望：（1）在商业上要提高产品的竞争力；（2）在技术上要提高产品的质量。但这种愿望无法靠软件的维护来实现，因为：（1）软件的可维护性可能极差，实在不值得去做；（2）即使软件的可维护性比较好，但也只是治表不治本。再生工程干脆对已有软件进行全部或部分的改造，赋予软件新的活力。
在对待一个不良之徒时，可以进行思想教育并给予他关心和帮助，这种方式类似于“软件维护”；也可以把他关进监狱，送去劳改，这种方式相当于软件的“再生工程”；如果此人坏透顶了，就毙掉算了。
再生工程与维护的共同之处是没有抛弃原有的软件。如果把维护比作“修修补补”，那么再生工程就算是“痛改前非”。再生工程并不见得一定比维护的代价要高，但再生工程在将来获取的利益却要比通过维护得到的多。
再生工程主要有三种类型：重构、逆向工程和前向工程。
8。3。1 重构
重构一般是指通过修改代码或数据以使软件符合新的要求。重构通常并不推翻原有软件的体系结构，主要是改造一些模块和数据结构。重构的一些好处如下：
（1）使软件的质量更高，或使软件顺应新的潮流（标准）。
（2）使软件的后续（升级）版本的生产率更高。
（3）降低后期的维护代价。
要注意的是，在代码重构和数据重构之后，一定要重构相应的文档。
8。3。2 逆向工程
逆向工程来源于硬件世界。硬件厂商总想弄到竞争对手产品的设计和制造“奥秘”。但是又得不到现成的档案，只好拆卸对手的产品并进行分析，企图从中获取有价值的东西。我的很多同学从事集成电路设计工作，他们经常解剖国外的集成电路，甚至不作分析就原封不动地复制该电路的版图，然后投入生产，并美其名曰“反向设计”（Reverse Design）。
软件的逆向工程在道理上与硬件的相似。但在很多时候，软件的逆向工程并不是针对竞争对手的，而是针对自己公司多年前的产品。期望从老产品中提取系统设计、需求说明等有价值的信息。
8。3。3 前向工程
前向工程也称预防性维护，由Miller倡导。他把这个术语解释成“为了明天的需要，把今天的方法应用到昨天的系统上”。＇Pressman 1999＇
乍看起来，主动去改造一个目前运行得正常的软件系统简直就是“惹事生非”。但是软件技术发展如此迅速，与其等待一个有价值的产品逐渐老死，还不如主动去更新，以获取更大的收益。其道理就同打预防性针一样。所以，预防性维护是“吃小亏占大便宜”的事。
8。4 小 结
大学科研机构里的软件维护工作恐怕是做得最差的了。几乎每一批新的研究生都会把毕业生留下的软件臭骂一通，然后全部推到重做。到他毕业该走时，就轮到别人骂他的工作了。如此轮回，最终没有什么成果留下。
如果希望软件系统能活下，必须要对它进行维护。如果希望软件系统有效益，则必须设法降低维护的代价。
参 考 文 献
＇Abrash 1998＇ Michael Abrash； 图形程序开发人员指南（前导工作室译），机械工业出版社，1998
＇Cline 1995＇ Marshall P。 Cline； Greg A。 Lomow； C＋＋ FAQs； Addison…Wesley； 1995
＇er 1996＇ Douglas E。 er； David L。 Stevens； Interworking With TCP/IP； Vol III； Prentice…Hall；1996
＇Cusumano 1995＇ Michael A。 Cusumano； Richard W。 Selby； 微软的秘密（程化 等译），北京大学出版社，1995
＇Jacobson 1997＇ Ivar Jacobson； Martin Griss； Software Reuse； 世界图书出版公司，1997
＇James 1999＇ Geoffery James； 编程之道（郭海 等译），清华大学出版社，1999
＇Kruglinski 1999＇ David J。 Kruglinski； Scot Wingo； Programming Visual C＋＋； 北京希望电子出版社； 1999
＇林锐 1996＇ 林锐，蔡文立，微机科学可视化系统设计，西安电子科技大学出版社，1996
＇林锐 1997＇ 林锐，戴玉宏，图形用户界面设计与技术，西安电子科技大学出版社，1997
＇林锐 2000＇ 林锐，支持协同工作的交互式三维图形软件开发系统与可视化平台，浙江大学博士论文，2000
＇Maguire 1993＇ Steve Maguire； Writing Clean Code（姜静波 等译），电子工业出版社，1993
＇Mankiw 1999＇ N。 Gregory Mankiw； 经济学原理（梁小明译），北京大学出版社，1999
＇Norman 1996＇ Ronald J。 Norman； Object…Oriented Systems Analysis And Design； Prentice…Hall； 1996
＇Pressman 1997＇Roger S。 Pressman； Software Engineering： A Practitioner’s Approach （ Fourth Edition）；
McGraw…Hill； 1997
＇Rogerson 1999＇Dale Rogerson； 技术内幕（杨秀章 译），清华大学出版社，1999
＇Shaffer 1999＇ Clifford A。 Shaffer； 数据结构与算法分析（张铭，刘晓丹译），电子工业出版社，1999
＇Sommerville 1992＇ Ian Sommerville； Software Engineering； Addison…Wesley； 1992
＇Summit 1996＇ Steve Summit； C Programming FAQs； Addison…Wesley； 1996
＇杨文龙 1997＇ 杨文龙，姚淑珍，吴云，软件工程，电子工业出版社，1997
＇Shaw 1996＇ Mary Shaw； David Garlan； Software Architecture； Prentice…Hall； 1996
＇Tanenbaum 1998＇ Andrew S。 Tanenbaum ；计算机网络（第三版，熊桂喜等译），清华大学出版社，1998
第二章 程序员与程序经理
工作在第一线的软件开发人员是程序员和程序经理，他们决定着软件的命运。良好的程序员队伍和出色的管理是软件项目成功的必要条件。管理不是管制，不是去卡住人家的脖子，因为程序员不是一群野鸭子。管理的目的是让大家一起把工作做好，并且让各人获得各自的快乐和满足。当一个组织被出色地领导时，雇员甚至不知道他们已被领导。在项目完成时，他们会自豪地说：“看看我们通过努力取得的成绩吧”。所以管理者不能老惦记着自己是一个官，而应时刻意识到自己是责任的主要承担者。
我们经常会听到有经理头衔的人在高谈阔论：“编程我不会，做个项目还不easy？派个人去搞系统分析，回头再叫几个程序员把需求译成程序，不就OK了吗？”
不懂英语的人准以为easy和OK是贬义词。要让软件项目失败很容易，只要符合下列条件之一即可：
（1）项目经理对软件一无所知；
（2）技术负责人对编程不感兴趣；
（3）真真编写代码的程序员是临时雇用的。
如果上述三个条件同时具备，就请放心失败好了。
让我们少幻想自己是比尔·盖茨，先当好程序员和程序经理再说。
2。1 了 解 程 序 员
早期的程序员干活能从软件直通硬件，个个生猛无比。又因他们的作息时间、言行举止与常人不太一样，久而久之就给人们留下了“神秘”、“孤僻”的印象。如今软件行业被炒得热火朝天，有能耐的程序员即便躲在大山岙的军工厂里也能被挖出来。而更多原本不是程序员的人操起几本“速成”、“二十一天通”等书籍也加入了这个行业。现在国内号称有上百万程序员，这支大军鱼龙混杂，已搞不清那些是正规军，那些是民兵游击队了。
真正的程序员都有如下秉性：
一、诚实
程序员在学习与工作期间几乎天天与机器打交道，压根就没有受欺骗或欺骗人的机会。勤奋的程序员在调试无穷多的程序Bug时，已经深深地接受了“诚实”的教育。不诚实的人，他肯定不想做、也做不好程序员。
有一名市场营销员和一名程序员都在新闻发布会上发言，将一项新技术的消息公布于众。
市场营销员说：“这项技术比电话、晶体管和原子弹三项发明加起来对世界文明的影响都要大。”
程序员说：“这项技术在有限的领域内，在有限的程度上，解决了一些技术性的问题。”
看来为了让我们的民族更加诚实，学电脑真的要从娃娃抓起。
二、简单——实用主义
有人问一个数学家，一个物理学家和一名程序员：“一个盒子有几个面？”
数学家回答说：“有六个面，因为盒子是长方体。”
物理学家回答说：“有12个面，分为6个外表面和6个内表面 。”
程序员回答说：“只有两个面，里面放电路板和硬盘，外面放显示器和键盘。”
目前即使最先进的计算机也不具备智能，程序员的基本工作就是把复杂的问题转化为计算机能处理的简单的程序。如果一个问题复杂到连程序员自己都不能理解，他就无法编出程序让更笨的计算机来处理。所以程序员信奉“简单——实用”主义。
也有不少做计算机“学问”的人颠倒行事。本来几句话、几行程序就能说明白的事，非得要抬高到理论创新的程度，写成玄乎的文章去评教授或者弄个博士学位。所幸在第一线工作的程序员大多是实干的。
三、爱憎分明
程序员大都喜欢技术挑战，不喜欢搞测试与维护。高水平的程序员喜欢与高水平的程序员一起工作，因为他们怕“与臭棋佬下棋，棋越下越臭”。程序员大都厌恶拉帮结派、耍政治手腕。不信，数一数你认识的程序员，有几个是党派人士？
四、工作单调但不乏味
有人问编程大师：“程序设计的真正含义是什么 ？”
大师回答说：“饿了的时候就吃，困的时候就睡，只要时机恰当就进行程序设计。”
其实程序员的生活和工作已融为一体，尽管单调却不乏味，还能独享孤独。有诗为证：
我编程三日
两耳不闻人声
只有硬盘在歌唱
结论：优秀的程序员没有理由不让人喜欢，他们远比怪僻来得可爱。
2。2 了 解 程 序 经 理
这里程序经理是指一支程序员队伍的领导者，不管他的职务是开发组长，项目经理，还是部门经理。程序经理是技术性的基层或中层干部，是软件企业得以发展的生力军。程序经理的选拔是不容�