原则#1：存在的原因

软件系统存在的原因：为用户提供价值。所有的决定都应该考虑到这一点。在指定系统需求之前，在关注系统的各个功能之前，在确定硬件平台或开发过程之前，问问自己以下问题：这是否能为系统真正增加价值？如果答案是否定的，那就不要去做。所有其他原则都以这一条为先。

原则#2：KISS

软件设计不是一个偶然的过程。任何设计工作都需要考虑许多因素。所有的设计应该尽可能简单，但不要过于简化。

复杂性是你的敌人。任何傻瓜都能让事情变得复杂。反之则很难。

——Richard Branson

这有利于拥有更易于理解和易于维护的系统。但并不是说应该以简单的名义抛弃功能，甚至是内部功能。当然，通常而言，更优雅往往意味着更简单。

简单是终极的复杂。

——Leonardo Da Vinci

简单也并不意味着快速和肮脏。事实上，为了简化，我们经常需要大量思考和多次迭代工作。收获是更易于维护且不易出错的软件。

这一直是我的一个座右铭——集中和简单。简单或许会比复杂更难；你必须花很多力气使自己的思维变得简单、有条理。

——Steve Jobs

原则#3：维护愿景

明晰的愿景对于软件项目的成功至关重要。否则，项目最终基本上都将陷入左右摇摆的境地。没有概念的完整性，系统就很有可能成为不兼容设计的拼凑物——被错误的螺丝钉连接在一起。

概念完整性是系统设计中要考虑的最重要因素。

——Fred Brooks

建立一个干净的内部结构对构建一个易于理解、可扩展和重组、并且可维护和可测试的系统而言至关重要。

——Stroustrup

只有清晰认识系统架构，才有可能发现常见的抽象和机制。利用这种通用性最终将使得系统更简单，因此也会更轻巧、更可靠。

- Grady Booch

妥协软件系统的架构愿景会削弱并将最终破坏系统，甚至是设计得尽善尽美的系统。拥有一个能够实现愿景和执行合规性的授权架构师有助于确保软件项目的成功。

原则#4：生产其他人消费的东西

很少有工业级的软件系统是在真空中构建和使用的。其他人将以某种方式，或者其他依赖于能够理解系统的方式使用、维护、记录。因此，始终指定、设计，以及实现了解他人将有助于了解你在做什么。任何软件开发产品的受众都可能很大。

指定用户。设计，牢记实施者。关注那些必须维护和扩展系统的代码。有的人可能需要调试你编写的代码，这使得他们成为你的代码用户。方便他们工作可以为你的系统增添价值。

原则#5：面向未来

寿命较长的系统具有更大的价值。在今天的计算环境中，当规格在刹那间发生变化并且硬件平台过几个月就变得过时时，软件寿命常常用月来衡量而不是用年。然而，真正的工业级软件系统必须能坚持更长时间。要做到这一点，系统必须能够适应这些改变。可以成功实现这些目标的系统都是从一开始就以这种方式而设计的。切勿在设计时自找麻烦。总是问“假使这样，那会怎么样”，并通过创建解决一般问题，而非仅仅是具体问题的系统来准备好所有可能的答案。这很可能促使整个系统的重用。

滥用这个原则是我看到很多开发者出错的地方。拥有多年的经验和其中许多人致力于单个项目的好处之一是你可以了解YouArentGonnaNeedIt的优点。作为开发者，除非我们也是该领域专家，否则我们经常会猜错系统将如何改变。

系统确实发生了变化，但通常会殊途同归，因而广义的解决方案就变成了包袱。

——Sal Mangano

原则#6：预先规划重用

重用可节省时间和精力。实现高水平的重用可以说是开发软件系统最难的目标。代码和设计的重用已被宣称为使用面向对象技术的主要优势。但是，这项投资的回报并不是自动的。为了利用面向对象编程提供的重用可能性，我们需要预先考虑和规划。在系统开发过程的每个级别都有很多技术可以用来实现重用。详细设计和代码级别的重用技术不但众所周知而且是有文档的。

新的文献正在以软件模式的形式寻觅设计的重用。然而，这只是战斗的一部分。与组织中的其他人交流重用的机会至关重要。如何重用你不知道的东西？提前规划重用可降低成本并提高可重用组件及其所在系统的价值。

原则#7：三思而后行！

这最后一条原则可能是最容易被忽视的。在行动之前形成一条清晰和完整的思路几乎总能够产出更好的结果。只有你考虑到了某个问题，你才更有可能解决它。你还可以从中获得有关如何再次正确做这件事的知识。

如果你确实考虑到了某件事情，但仍然做错了，那么这就是你宝贵的经验。思考还有一个成果是可以学习到当你不知道某个东西，此时该如何研究答案的过程。

明确的思想进入到系统，就会产出价值。应用前六个原则需要深入的思考，当然潜在的回报也是不可估量。

英文原文：Seven Principles of Software Development