唯一不变的就是变化本身，对于大多数项目第一个开发的系统并不合用，为舍弃而计划。要为变更设计系统，计划组织架构。设计可替代的，易修改的接口，程序更能减少维护的成本。即使最熟练的软件维护工作也只是放缓系统退化的进程，因此要时刻未雨绸缪。对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的需求变更。目标上（和开发策略上）的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。当系统发生变化时，管理结构也需要进行调整。只要管理人员和技术人才的天赋允许，老板必须对他们的能力培养给予极大的关注，使管理人员和技术人才具有互换性。看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级别的问题，通常这不是很明显。设计实现的人员越少、接口越少，产生的错误也就越少。所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。用在修复原有设计上瑕疵的工作量越来越少，而早期维护活动本身的漏洞所引起修复工作越来越多。随着时间的推移，系统变得越来越无序，修复工作迟早会失去根基 ，尽管理论上系统一直可用，但实际上，整个系统已经面目全非，无法再成为下一步进展的基础。机器在变化，配置在变化，用户的需求在变化，所以现实系统不可能永远可用。崭新的、对于原有系统的重新设计是完全必要的。
干将莫邪强调了软件开发项目所选择的技术和工具对保障项目能否令人满意地如期完成的重要性。我们应当同时合理运用个性化和公共通用编程开发工具、评测技术，为此需要制定一套合理的策略。本章提供了当年软件开发项目选择技术和工具的重要原则和建议。
整体部分细致介绍了如何开发一个可运行系统，测试系统，系统集成。我应当具体深入了解系统所有的局部设计的精确定义和技术，采用测试规格说明，自上而下的设计，结构化编程，构件单元测试等技术开发系统。实际工作中测试越早，集成越早代价更小，更早消灭隐患。采用一次添加一个构件。 标签：读后感,神话,系统,技术,测试,设计,变化 From： https://www.cnblogs.com/liurujun/p/17421248.html