本节书摘来自华章出版社《实践者的研究方法》一书中的第2章，第2.3节，作者罗杰 S. 普莱斯曼（Roger S. Pressman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.3　软件工程实践

在2.2节中，曾介绍过一种由一组活动组成的通用软件过程模型，建立了软件工程实践的框架。通用的框架活动——沟通、策划、建模、构建和部署——和普适性活动构成了软件工程工作的体系结构的轮廓。但是软件工程的实践如何融入该框架呢？在以下几节里，读者将会对应用于这些框架活动的基本概念和原则有一个基本了解。

 

2.3.1　实践的精髓

在现代计算机发明之前，有一本经典著作《How to Solve it》，在书中，George Polya[Pol45]列出了解决问题的精髓，这也正是软件工程实践的精髓：

1.理解问题（沟通和分析）。

2.策划解决方案（建模和软件设计）。

3.实施计划（代码生成）。

4.检查结果的正确性（测试和质量保证）。

在软件工程中，这些常识性步骤引发了一系列基本问题（与[Pol45]相对应）：

理解问题。虽然不愿承认，但生活中的问题很多都源于我们的傲慢。我们只听了几秒钟就断言，好，我懂了，让我们开始解决这个问题吧。不幸的是，理解一个问题不总是那么容易，需要花一点时间回答几个简单问题：

谁将从问题的解决中获益？也就是说，谁是利益相关者？

有哪些是未知的？哪些数据、功能和特性是解决问题所必需的？

问题可以划分吗？是否可以描述为更小、更容易理解的问题？

问题可以图形化描述吗？可以建立分析模型吗？

策划解决方案。现在你理解了要解决的问题（或者你这样认为），并迫不及待地开始编码。在编码之前，稍稍慢下来做一点点设计：

以前曾经见过类似问题吗？在潜在的解决方案中，是否可以识别一些模式？是否已经有软件实现了所需要的数据、功能和特性？

类似问题是否解决过？如果是，解决方案所包含元素是否可以复用？

可以定义子问题吗？如果可以，子问题是否已有解决方案？

能用一种可以很快实现的方式来描述解决方案吗？能构建出设计模型吗？

实施计划。前面所创建的设计勾画了所要构建的系统的路线图。可能存在没有想到的路径，也可能在实施过程中会发现更好的解决路径，但是这个计划可以保证在实施过程中不至迷失方向。需要考虑的问题是：

解决方案和计划一致吗？源码是否可追溯到设计模型？

解决方案的每个组成部分是否可以证明正确？设计和代码是否经过评审？或者采用更好的方式，算法是否经过正确性证明？

检查结果。你不能保证解决方案是最完美的，但是可以保证设计足够的测试来发现尽可能多的错误。为此，需回答：

能否测试解决方案的每个部分？是否实现了合理的测试策略？

解决方案是否产生了与所要求的数据、功能和特性一致的结果？是否按照项目利益相关者的需求进行了确认？

不足为奇，上述方法大多是常识。但实际上，有充足的理由可以证明，在软件工程中采用常识将让你永远不会迷失方向。

2.3.2　通用原则

原则这个词在字典里的定义是“某种思想体系所需要的重要的根本规则或者假设”。在本书中，我们将讨论一些不同抽象层次上的原则。一些原则关注软件工程的整体，另一些原则考虑特定的、通用的框架活动（比如沟通），还有一些关注软件工程的动作（比如架构设计）或者技术任务（比如编制用例场景）。无论关注哪个层次，原则都可以帮助我们建立一种思维方式，进行扎实的软件工程实践。因此，原则非常重要。

David Hooker[Hoo96]提出了7个关注软件工程整体实践的原则，这里复述如下。

第1原则：存在价值

一个软件系统因能为用户提供价值而具有存在价值，所有的决策都应该基于这个思想。在确定系统需求之前，在关注系统功能之前，在决定硬件平台或者开发过程之前，问问你自己：这确实能为系统增加真正的价值吗？如果答案是不，那就坚决不做。所有的其他原则都以这条原则为基础。

第2原则：保持简洁

软件设计并不是一种随意的过程，在软件设计中需要考虑很多因素。所有的设计都应该尽可能简洁，但不是过于简化。这有助于构建更易于理解和易于维护的系统。这并不是说有些特性（甚至是内部特性）应该以“简洁”为借口而取消。的确，优雅的设计通常也是简洁的设计，但简洁也不意味着“快速和粗糙”。事实上，它经常是经过大量思考和多次工作迭代才达到的，这样做的回报是所得到的软件更易于维护且错误更少。

第3原则：保持愿景

清晰的愿景是软件项目成功的基础。没有愿景，项目将会由于它有“两种或者更多种思想”而永远不能结束；如果缺乏概念的一致性，系统就好像是由许多不协调的设计补丁、错误的集成方式强行拼凑在一起……如果不能保持软件系统体系架构的愿景，就会削弱甚至彻底破坏设计良好的系统。授权体系架构师，使其能够持有愿景，并保证系统实现始终与愿景保持一致，这对项目开发的成功至关重要。

第4原则：关注使用者

有产业实力的软件系统不是在真空中开发和使用的。通常软件系统必定是由开发者以外的人员使用、维护和编制文档等，因此必须要让别人理解你的系统。在需求说明、设计和实现过程中，牢记要让别人理解你所做的事情。对于任何一个软件产品，其工作产品都可能有很多用户。需求说明时应时刻想到用户，设计中始终想到实现，编码时想着那些要维护和扩展系统的人。一些人可能不得不调试你所编写的代码，这使得他们成了你所编写代码的使用者，尽可能地使他们的工作简单化会大大提升系统的价值。

第5原则：面向未来

生命周期持久的系统具有更高的价值。在现今的计算环境中，需求规格说明随时会改变，硬件平台几个月后就会淘汰，软件生命周期都是以月而不是以年来衡量的。然而，真正具有“产业实力”的软件系统必须持久耐用。为了成功地做到这一点，系统必须能适应各种变化，能成功做到这一点的系统都是那些一开始就以这种路线来设计的系统。永远不要把自己的设计局限于一隅，经常问问“如果出现……应该怎样应对”，构建可以解决通用问题的系统，为各种可能的方案做好准备，这很可能会提高整个系统的可复用性。

第6原则：提前计划复用

复用既省时又省力。软件系统开发过程中，高水平的复用是很难实现的一个目标。曾有人宣称代码和设计复用是面向对象技术带来的主要好处，然而，这种投入的回报不会自动实现。为达到面向对象（或是传统）程序设计技术所能够提供的复用性，需要有前瞻性的设计和计划。系统开发过程中的各个层面上都有多种技术可实现复用……提前做好复用计划将降低开发费用，并增加可复用构件以及构件化系统的价值。

第7原则：认真思考

这最后一条规则可能是最容易被忽略的。在行动之前清晰定位、完整思考通常能产生更好的结果。仔细思考可以提高做好事情的可能性，而且也能获得更多的知识，明确如何把事情做好。如果仔细思考过后还是把事情做错了，那么，这就变成了很有价值的经验。思考就是学习和了解本来一无所知的事情，使其成为研究答案的起点。把明确的思想应用在系统中，就产生了价值。使用前六条原则需要认真思考，这将带来巨大的潜在回报。

如果每位工程师、每个开发团队都能遵从Hooker这七条简单的原则，那么，开发复杂计算机软件系统时所遇到的许多困难都可以迎刃而解。