Question

约束是强加于你的，而原则是你为了将标准方法和一致性引入构建软件的方式而想采用的。通用的原则很多，有些跟开发相关，其他则跟架构相关。

开发原则

说到原则，很多软件开发者立刻想到的都是关于软件应该如何开发。比如下面这些。

编码标准和规范：“我们将采用内部的[Java|C#|其他]语言编码规范，这可以在我们公司wiki找到。”

自动化单元测试：“我们的目标是核心库的自动化单元测试达到80%的代码覆盖率，无论代码开发是先测试还是后测试。”

静态分析工具：“所有的生产和测试代码在提交到源代码管理之前，必须通过[Checkstyle|FxCop|其他]定义的规则。”

等等。

架构原则

还有一些原则是关于软件结构应该如何安排的。比如下面这些。

分层策略：因为每一层都独立于周围，分层架构通常出现在有高度灵活性的软件系统中。比如，你可以把软件系统解构为UI（User Interface，用户界面）层，业务层和数据访问层。使业务层完全独立于数据访问层意味着（通常）可以实现在不影响业务或UI层的情况下切换数据访问。能这样做是因为数据访问层向业务层呈现了抽象，而不是业务层自己直接处理数据存储机制。如果想以这种方式安排软件结构，你就应当确保开发团队里每个人都明白这个原则。“UI组件或域对象里没有数据访问逻辑”是该原则在实践中的一个具体例子。

业务逻辑的位置：有时候，出于性能或可维护性的原因，你要确保业务逻辑总是驻留在一个地方。对于连接互联网的移动应用程序，你可能想要确保服务器尽可能多地处理发生的请求。或者如果你在整合一个已经包含了大量业务逻辑的遗留后端系统，可能想要确保团队里没有人打算复制它。

高内聚、低耦合、SOLID1等：有很多关注点分离相关的原则，专注于构建不需要太多依赖就能完成工作的高内聚的小结构单元。

无状态组件：如果你在构建一个需要很强可伸缩性的软件，那么尽可能把组件设计得无状态，就是一种确保可以通过复制组件来对系统进行横向扩展从而分担负载的方式。如果这是你的可伸缩性策略，每个人都需要明白他们必须使用相同的模式来构建组件。这有助于避免将来出现任何讨厌的意外和可伸缩性瓶颈。

存储过程：关系型数据库的存储过程就像马麦酱2——你对它们不是爱就是恨。用不用存储过程都各有优缺点，但当团队只是选择一种数据访问的方法并坚持，我还是倾向于存储过程。然而，每条原则都有例外。

域模型：丰富与贫瘠：有些团队喜欢在自己的代码中有很丰富的域模型，构建本质上非常面向对象的系统。另一些则倾向于更贫瘠的域模型，对象只是被粗粒度组件和服务使用的数据结构。方法的一致性有很长的路要走。

HTTP会话的使用：如果你在构建一个网站，可能想或者不想用HTTP会话来存储请求间的临时信息。这通常取决于很多事情，包括你的伸缩策略是什么，会话支持对象到底存储在哪里，服务器出现故障时会发生什么，你是否使用粘性会话，会话复制的成本，等等。再次，开发团队的每个人都应该明白想要的方法，并坚持下去。

始终一致与最终一致：很多团队都发现，他们往往需要为满足复杂非功能需求做出权衡。比如：有些团队用数据一致性换取性能或可伸缩性。我们能看到所有的Facebook3状态更新，但是否都能立即看到真的重要吗？你的语境将决定立即或延迟的一致性是否妥当，但一致的方法很重要。

1http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

2http://en.wikipedia.org/wiki/Marmite，一种黏稠状、深棕色并且有鲜明特色风味的酱，通常抹在面包等食品上食用。——译者注

3http://facebook.com/，著名社交网站。——译者注

谨防最佳实践

如果你经常构建大型企业软件系统，可能考虑过大多数我刚才列出的“最佳实践”原则。但要小心。即使是最善意的原则，有时候也会产生意想不到的负面影响。如果只是构建一个快速的战术方案，为确保完整的关注点分离而采用复杂的分层策略，也能耗费你大量时间。原则通常是因为好的理由才引入，但它们并不是任何时候都有好处。

构建软件的大小和复杂度，加上环境的约束，会帮助你决定采用哪些原则。语境一如既往是关键。一份明确的原则清单有助于确保团队中每个人都以相同的方式工作，但你要确保这些原则是帮助而非阻碍。倾听团队成员的反馈会帮助你认清你的原则是否奏效。