开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。这样才能少犯错误。
进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。
如果发现项目应交付的期限非常不合理，就要跟领导或跟客户据理力争，请求放宽期限、调整进度。当客户的需求发生变化时，就要对进度表作出相应的修正。不要觉得修改进度表很困难很麻烦，不修改才会产生真真的麻烦。
“零缺陷”质量管理的观念来源于一些国际上著名的硬件生产厂商。尽管软件的开发与硬件生产有极大的差别，但我们仍可以从“零缺陷”质量管理中得到启迪。“零缺陷”质量管理至少有两个核心内容：一是高目标，二是可执行的规范。如果没有“零缺陷”的质量目标，也许缺陷就会成堆。“零缺陷”质量目标不是随心所欲提出来的，做得到才有意义。实现高目标需要一套可执行的规范来保证。
“运行正确”的程序不见得就是高质量的程序。这个程序也许运行速度很低并且浪费内存；也许代码写得一塌糊涂，除了开发者本人谁也看不懂也不会使用。
在一些高风险的软件系统，如航空航天、武器、金融等系统中，容错性设计非常重要。
一个原始的应用问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。如果软件系统臃肿不堪，它迟早会出问题。简洁是人们对工作“精益求精”。
测试的目的是为了发现尽可能多的缺陷。
如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是虚假的。
一个成功的测试示例在于发现了至今尚未发现的缺陷。测试并不仅是个技术问题，更是个职业道德问题。
为了测试的真实性，对测试的心理要求是“无情”。开发人员不能很好地测试自己的程序是因为做不到无情。
测试只能证明缺陷存在，而不能证明缺陷不存在。
这个真理告诉我们，对于一个复杂的系统而言，无论采取什么样的测试手段都不能证明缺陷已经不复存在。“彻底地测试”只是一种理想。在实践中，测试要考虑时间、费用等限制，不允许无休止地测试。
测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。所以说，软件的高质量是设计出来的，而不是靠测试修补出来的。
自从 Microsoft 公司在 1984 年与1986 年之间扩大了测试小组后，开发人员开始“变懒”了。他们把代码扔在一边等着测试，忘了唯有开发人员自己才能阻止错误的发生、防患于未来。开发者在测试自己的程序时存在一些弊病：
（1）开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下隐患，那么他本人很难发现这类错误。
（2）开发者对程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以自己测试程序难以具备典型性。
（3）程序设计有如艺术设计，开发者总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。即便开发者非常诚实，但“珍爱程序”的心理让他在测试时不知不觉地带入了虚假成份。
（4）在改错之后一定要马上进行重新测试，以免引入新的错误。更加严格的要求是：不论原有程序是否绝对正确，只要对此程序作过改动（哪怕是微不足道的），都要进行重新测试。
序员应该把测试当成份内之事，不要依赖于外界的“黑盒测试”。再生工程的三种类型：重构（Restructure）、逆向工程（Reverse Engineering）和前向工
程（Forward Engineering）。
一些学者将软件维护划分为主要的三类：纠错性维护（Corrective maintenance）、适应性维护（Adaptive maintenance）和完善维护
（Perfectivemaintenance）：
（1）纠错性维护。由于前期的测试不可能揭露软件系统中所有替在的错误，用户在使用软件时仍将会遇到错误，诊断和改正这些错误的过程称为纠错性维护
（2）适应性维护。由于新的硬件设备不断推出，操作系统和编译系统也不断地升级，为了使软件能适应新的环境而引起的程序修改和扩充活动称为适应性维护
（3）完善性维护。在软件的正常使用过程中，用户还会不断提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。以下一些因素将导致维护工作变得困难：
（1）软件人员经常流动，当需要对某些程序进行维护时，可能已找不到原来的开发人员。只好让新手去“攻读”那些程序。
（2）人们一般难以读懂他人的程序。在勉强接受这类任务时，心里不免嘀咕：“我又不是他肚子里的虫子，怎么知道他如何编程。”
（3）当没有文档或者文档很差时，你简直不知道如何下手。
（4）很多程序在设计时没有考虑到将来要改动，程序之间相互交织，触一而牵百。即使有很好的文档，你也不敢轻举妄动，否则你有可能陷进错误堆里。
（5）如果软件发行了多个版本，要追踪软件的演化非常困难。
（6）维护将会产生不良的副作用，不论是修改代码、数据或文档，都有可能产生新的错误。
（7）维护工作毫无吸引力。高水平的程序员自然不愿主动去做，而公司也舍不得让高水平的程序员去做。带着低沉情绪的低水平的程序员只会把维护工作搞得一塌糊涂。
影响维护代价的非技术因素主要有：
（1）应用域的复杂性。如果应用域问题已被很好地理解，需求分析工作比较完善，那么维护代价就较低。反之维护代价就较高。
（2）开发人员的稳定性。如果某些程序的开发者还在，让他们对自己的程序进行维护，那么代价就较低。如果原来的开发者已经不在，只好让新手来维护陌
生的程序，那么代价就较高。
（3）软件的生命期。越是早期的程序越难维护，你很难想像十年前的程序是多么的落后（设计思想与开发工具都落后）。一般地，软件的生命期越长，维护
代价就越高。生命期越短，维护代价就越低。
（4）商业操作模式变化对软件的影响。比如财务软件，对财务制度的变化很敏感。财务制度一变动，财务软件就必须修改。一般地，商业操作模式变化越频繁，相应软件的维护代价就越高。
影响维护代价的技术因素主要有：
（1）软件对运行环境的依赖性。由于硬件以及操作系统更新很快，使得对运行环境依赖性很强的应用软件也要不停地更新，维护代价就高。
（2）编程语言。虽然低级语言比高级语言具有更好的运行速度，但是低级语言比高级语言难以理解。用高级语言编写的程序比用低级语言编写的程序的维护
代价要低得多（并且生产率高得多）。
（3）编程风格。良好的编程风格意味着良好的可理解性，可以降低维护的代价。
（4）测试与改错工作。如果测试与改错工作做得好，后期的维护代价就能降低。反之维护代价就升高。
（5）文档的质量。清晰、正确和完备的文档能降低维护的代价。低质量的文档将增加维护的代价（错误百出的文档还不如没有文档）。
--摘自《软件工程思想》林锐