程序员架构修炼之道：软件架构设计的37个一般性原则

原则37&＃xff1a;不要有任何借口。如果你是一个系统的开发者&＃xff0c;把它做好是你的责任。要承担这个责任。要么做好&＃xff0c;要么就压根不做。

如果&＃xff0c;软件工程真的是一门工程学科&＃xff0c;那么它是对经过验证的“原则、技术、语言和工具”的智慧的运用&＃xff0c;用于创造和维护能够满足用户需求的软件。原则是关于软件工程的基本原理、规则或假设&＃xff0c;不管所选的技术、工具或语言是什么&＃xff0c;其都有效。

当桥梁或建筑物倒塌时&＃xff0c;调查人员会尝试确定是什么地方出了问题。通常&＃xff0c;是因为建筑商未能遵守建筑规范&＃xff08;即施工期间要遵循的一套规则或原则&＃xff09;&＃xff0c;或者检查员未能找到物理损坏的位置。当软件失败时&＃xff0c;通常是因为软件工程组织没有遵守某个原则。

理解和实践一门学科的所有原则是否可以预防所有灾难&＃xff1f;绝对不是。它只会大大降低因你而导致灾难的可能性。正如亚历山大·波普所说&＃xff0c;“犯错是人之常情。”只有通过犯错&＃xff0c;我们才能学习&＃xff0c;并制定新的原则。

软件工程的基本原则和人类探索的其他领域的基本原则存在根本性的不同。我们没有理由期待软件工程的原则具备和&＃xff08;例如&＃xff09;物理学原理一样的精确性和可预测性。原因是&＃xff0c;一方面不像物理学或生物学&＃xff0c;软件开发过程是由人来管理和实现的&＃xff1b;这样&＃xff0c;从长远看&＃xff0c;软件开发的行为是不可预测的&＃xff0c;它依赖于人的判断、奇想和行动。另一方面&＃xff0c;软件似乎展现出很多有规律和可预测的特征。这使得很多基本原理可以被列出&＃xff0c;并可以被没有经验的或有经验的软件工程师和管理者使用&＃xff0c;以增强软件工程过程和软件产品的质量。

原则是指经过长期经验总结所得出的合理化的现象。在软件工程领域&＃xff0c;原则是关于软件工程的基本原理、规则或假设&＃xff0c;不管所选的技术、工具或语言是什么&＃xff0c;其都有效。

其他工程领域有基于物理学、生物学、化学或数学定律的原则&＃xff0c;然而&＃xff0c;由于软件工程的产物是非实体的&＃xff08;nonphysical&＃xff09;&＃xff0c;所以实体的定律&＃xff08;laws of the physical&＃xff09;并不能轻易地成为软件工程领域坚实的基础。

原则、技术、语言、工具的关系如下图。

• 原则&＃xff08;Principle&＃xff09;是工作的准则&＃xff1b;原则代表了许多人从经验中总结出来的集体智慧。它们往往被描述为绝对真理&＃xff08;总是正确的&＃xff09;或用作推论&＃xff08;当X发生时&＃xff0c;Y将会发生&＃xff09;。

• 技术&＃xff08;Technique&＃xff09;是一种按部就班的流程&＃xff0c;它帮助软件开发者执行一部分软件工程过程。技术倾向于强制遵循基本原则的一个子集。大部分技术会创建文档和&＃xff08;或&＃xff09;程序。许多技术也会分析现有的文档和&＃xff08;或&＃xff09;程序&＃xff0c;或将其转变为产品。

• 语言&＃xff08;Language&＃xff09;由一组基本元素&＃xff08;如单词或图形符号&＃xff09;、规则和语义组成。规则可以让人们用基本元素构造出更复杂的实体&＃xff08;如句子、图表、模型&＃xff09;&＃xff0c;语义则赋予每个实体组合以意义。语言用于表达所有软件工程的产出&＃xff0c;无论是过程中的还是最终的。那些通过技术创建或分析的文档和程序通常也会用某种语言来表达。

• 工具&＃xff08;Tool&＃xff09;是软件程序&＃xff0c;可帮助软件工程师执行软件工程中的某些步骤。它们可以&＃xff1a;

■ 作为工程师的顾问&＃xff08;例如&＃xff0c;基于知识的需求助理&＃xff09;。
■ 分析某些内容是否符合某种技术&＃xff08;例如&＃xff0c;数据流图检查器&＃xff09;或原则的子集。
■ 使软件工程中的一些工作实现自动化&＃xff08;例如&＃xff0c;编译器&＃xff09;。
■ 辅助工程师完成一些工作&＃xff08;例如&＃xff0c;编辑器&＃xff09;。

一个学科的原则集合&＃xff0c;会随着学科的发展而发展。现存的原则会发生改变&＃xff0c;新的原则会被加进来&＃xff0c;旧的原则将不再适用。实践和从实践中获得的经验&＃xff0c;促使我们发展了那些原则。如今&＃xff0c;当我们去审视一些1964年的软件工程原则时&＃xff0c;会觉得它们看起来很傻&＃xff08;例如&＃xff0c;总是使用简短的变量名&＃xff0c;或者尽可能让程序体积更小&＃xff09;。三十年后&＃xff0c;如今的一些原则也会如此。

(美)Alan M· Davis(艾伦·M·戴维斯). “软件开发的201个原则 2021。