原则#1：存在的理由一个软件系统存在的理由是：为用户提供价值。所有决定都应考虑到这一点。在明确系统要求之前，在关注系统的个别功能之前，在决定硬件平台或开发过程之前，问自己以下问题：这真的会增加系统的价值吗？如果答案是否定的，那就不要这样做。所有其他原则都优先于此原则。原则#2：KISS软件设计不是一个偶然的过程。在任何设计工作中都需要考虑许多因素。所有的设计都应该尽可能简单，但不要过于简单。复杂性是你的敌人。任何傻瓜都会使事情复杂化。反之则难。-RichardBranson拥有更易于理解和维护的系统是件好事。但这并不是说应该以简单的名义放弃功能，甚至内部功能。当然，更优雅往往意味着更简单。简单是最终的复杂。-LeonardoDaVinci简单并不意味着快速和肮脏。事实上，简化往往需要大量的思考和多次迭代的工作。回报是更易于维护且更不容易出错的软件。这一直是我的座右铭——专注和简单。简单比复杂更难；你必须努力使你的思维简单而有条理。—SteveJobs原则#3：保持清晰的愿景对于软件项目的成功至关重要。否则，项目基本上会陷入左右摇摆的局面。没有概念的完整性，系统就有可能成为不兼容设计的拼凑物——由错误的螺丝固定在一起。概念完整性是系统设计中要考虑的最重要因素。—FredBrooks建立一个干净的内部结构对于构建一个易于理解、可扩展和可重组、可维护和可测试的系统至关重要。——Stroustrup只有对系统架构有清晰的认识，才能发现共同的抽象和机制。利用这种通用性最终将导致更简单的系统，从而使系统更轻便、更可靠。–GradyBooch妥协软件系统的架构愿景会削弱并最终摧毁一个系统，即使是一个设计完美的系统。拥有能够实现愿景并强制合规的授权架构师有助于确保软件项目的成功。原则4：生产其他人消费的产品很少有工业强度的软件系统是在真空中构建和使用的。其他人将以某种方式使用、维护、记录或以其他方式依赖于能够理解系统。因此，在明确说明、设计和实施时，始终要知道其他人会帮助理解您正在做的事情。任何软件开发产品的受众都可能很大。指定用户。设计时考虑了实施者。关注必须维护和扩展系统的代码。有人可能需要调试您编写的代码，这使他们成为您代码的用户。让事情变得更容易为您的系统增加价值。原则5：未来寿命更长的系统具有更大的价值。在当今的计算环境中，软件寿命通常以月而不是年来衡量，而规格在眨眼之间就发生了变化，而硬件平台在几个月内就过时了。然而，真正的工业级软件系统必须持续更长时间。为此，系统必须能够适应这些变化。成功实现这些目标的系统是从头开始设计的。设计时不要自讨苦吃。始终问“如果……会怎样”，并通过创建解决一般问题而非特定问题的系统来为所有可能的答案做好准备。这可能会推动整个系统的重用。滥用这个原则是我看到很多开发人员犯错的地方。拥有多年经验并且其中许多人都在一个项目上工作的好处之一是您可以了解YouArentGonnaNeedIt的优点。作为开发人员，除非我们也是该领域的专家，否则我们经常会猜错系统将如何变化。系统确实会发生变化，但通常会朝着同一个方向发展，因此广泛的解决方案会成为包袱。-SalMangano原则#6：重用的预先计划重用可以节省时间和精力。实现高水平的重用可以说是开发软件系统最困难的目标。代码和设计重用已被宣布为使用面向对象技术的主要优势。然而，这项投资的回报不是自动的。为了利用面向对象编程提供的重用可能性，我们需要预先考虑和计划。在系统开发过程的每个级别，都有许多技术可用于实现重用。详细的设计和代码级重用技术是众所周知的并且有文档记录。一种新的文献正在寻找软件模式形式的设计重用。然而，这只是战斗的一部分。与组织中的其他人交流重用的机会是至关重要的。你如何重用你不知道的东西？提前计划重用可降低成本并增加可重用组件及其所在系统的价值。原则7：三思而后行！最后一条原则可能是最容易被忽视的。在行动之前形成清晰完整的思路几乎总是会产生更好的结果。如果您考虑过问题，您就更有可能解决问题。您还可以从中获得有关如何重新做正确的知识。如果你确实想过某件事，但仍然做错了，那就是你的教训。思考的另一个结果是当你不知道某事时，学习如何研究答案的过程。当清晰的想法进入系统，就会产生价值。应用前六项原则需要深思熟虑，当然潜在的回报是不可估量的。
