软件开发的基本策略

                                      

人们在探索软件工程方法的几十年里，提出了许多软件开发的方法，但这些方法都不是严密的理论。我们不应该教条地套用方法，更重要的是学会"选择合适的方法"和"产生新方法"。
　 软件开发中的三种基本策略：复用、分而治之、优化与折衷。

1.复用

   对于建立软件系统而言，所谓复用就是利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统。在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地，可以相信成熟的东西总是比较可靠的，而大量成熟的工作可以通过复用来快速实现，人们应该把大部分的时间用在小比例的创新工作上，而把小部分的时间用在大比例的成熟工作中，这样才能把工作做得既快又好。
　　我们将具有一定集成度并可以重复使用的软件组成单元称为软构件（Software Component），软件复用就是直接使用已有的软构件，即可组装（或加以合理修改）成新的系统，而可以不必每次从零做起。一方面，软件复用方法合理化并简化了软件开发过程，减少了总的开发工作量与维护代价，既降低了软件的成本又提高了生产率。另一方面，由于软构件是经过反复使用验证的，自身具有较高的质量，因此由软构件组成的新系统也具有较高的质量。

2.分而治之

　分而治之是指把大而复杂的问题分解成若干个简单的小问题，然后逐个解决。这种朴素的思想来源于人们生活与工作的经验，也完全适合于技术领域。诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。

3.优化与折衷

软件的优化是指优化软件的各个质量因素，如提高运行速度、提高对内存资源的利用率、使用户界面更加友好、使三维图形的真实感更强等等。我们应该树立这样的正确认识：优化工作不是可有可无的事情，而是必须要做的事情。

　　当优化工作成为一种责任时，程序员才会不断改进软件中的算法，数据结构和程序组织，从而提高软件质量。著名的3D游戏软件Quake，能够在PC机上实时地绘制高度真实感的复杂场景。Quake的开发者能把很多成熟的图形技术发挥到极致，例如把Bresenham画线、多边形裁剪、树遍历等算法的速度提高近一个数量级，其技术水平已经远胜于目前国内领先的图形学相关科研成果。
　　优化工作是十分复杂的，有时很难实现所有目标的优化，这时就需要"折衷"策略。软件的折衷策略是指通过协调各个质量因素，实现整体质量的最优。
　　软件折衷的重要原则是不能使某一方损失关键的职能，更不可以象"舍鱼而取熊掌"那样抛弃一方。例如3D动画软件的瓶颈通常是速度，但如果为了提高速度而在程序中取消光照明计算，那么场景就会丧失真实感，3D动画也就不再有意义了。

　　折衷是有原则的，如果滥用折衷的话，那么一旦碰到困难，人们就会用拆东墙补西墙的方式去折衷，不再下苦功去做有意义的优化。所以，我们应当坚持这样的折衷立场：在保证其它因素不差的前提下，使某些因素变得更好。

人们对软件存在着许多错误的观点，这些观点表面上看起来很有道理，符合人们的直觉，但实际上给管理者和开发人员带来了严重的问题。许多人认识到下述观点是错误的，但遗憾的是旧的观念和方法培植了拙劣的管理和技术习惯。

观点之一	我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。
客观事实	好的参考书无疑能指导我们的工作，充分利用书籍中的方法、技术和技巧，可以有效地解决软件开发中大量常见的问题。但实践者并不能依赖于书籍，因为在现实工作中，由于条件千差万别，即使是相当成熟的软件工程规范，常常也无法套用。另外，软件技术日新月异，没有哪一种软件标准能长盛不衰。
观点之二	如果我们已经落后于计划，可以增加更多的程序员来赶上进度。
客观事实	软件开发不同于传统的机械制造，人多不见得力量大。如果给落后于计划的项目增添新人，可能会更加延误项目。因为新人会产生很多新的错误，使项目混乱，并且原有的开发人员向新人解释工作和交流思想都要花费时间，使实际的开发时间更少，所以制定恰如其分的项目计划是很重要的。
	【讲解】 　　假设一个项目估计需要12人月工作量，指定由3个人在4个月内完成，如果第一个月的任务花了两个月才完成，那么增加人力的结果如何？假设增加2个人参加项目，不论新增加的人适应能力有多强，总需要有人去帮助了解熟悉情况，如果这些工作占用了一个月的时间，这样又有3个人月工作量在新计划之外。由于人员增加，工作任务需要重新划分，到第3个月结束时虽然有5个人在工作，实际上余留下7个人的工作量。
观点之三	项目需求总是在不断变化，但这些变化能够很容易地满足，因为软件是灵活的。
客观事实	软件需求确实是经常变化的，但这些变化产生的影响会随着其引入时间的不同而不同。对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代价越少，修改越晚代价越大，就跟治病一样道理。
观点之四	有了对目标的一般描述就足以开始写程序了，我们以后可以再补充细节。
客观事实	不完善的系统定义是软件项目失败的主要原因。关于待开发软件的应用领域、功能、性能、接口、设计约束和标准等需要详细的描述，而这些只有通过用户和开发人员之间的通信交流才能确定。越早开始写程序，就要花越长时间才能完成它。
观点之五	一旦我们写出了程序并使其正常运行，我们的工作就结束了。人们有时认为，只有差的软件产品才需要维护。
客观事实	从如图1.12所示的统计数据来看，软件投入的50%～70%是花费在交付给用户之后。品质差的产品被丢弃，只有好的产品才需要维护和改进。
观点之六	一个成功的项目唯一应该提交的就是运行程序。
客观事实	软件包括程序、数据和文档，其中文档是成功开发的基础，为软件维护提供了指导。