必看，超实用开发原则（一）

作为一个资深开发者，今天给大家总结出来了10条有用的开发原则！

原则一 剔除无效状态

我把这一点排第一，是因为我认为它是最重要、最强大的原则之一。

你可能在定义类型时听到过这个词，但其实这个原则适用于所有与表示数据相关的地方——例如数据库设计。

它不仅可以减少系统的状态数量（从而变得更简单），还能减少无效状态的数量！你的系统不需要处理这些无效状态，因为它们在你的程序中实际上是不可表示的。

这不只是一个小技巧，它可以极大简化你的系统，并防止出现各种类型的 bug。

原则二 数据一致性让系统更简单

对数据施加一致性规则，减少了系统需要处理的状态数量。这是从上一个原则派生而来的。

定义

这里说的是一致性的普遍含义：即数据遵循某些规则，并且在任意时刻都始终遵循这些规则。这一定义与 ACID 有关，但不要与 CAP 混淆起来了。

规则可以是任何东西，例如，你的信用永远不能变成负数，或者私密的帖子不应该被其他人看到。它不仅限于外键或唯一索引，尽管它们也是有效的规则。

和数据库一样，应用程序也可以通过使用 ACID 事务来加强一致性。如果能在数据库级别强制保持一致性是最好的，但在实际中，对稍微复杂一点的东西来说，这样做并不常见。

实用建议

任何限制或损害一致性的行为都会导致复杂性。这就引出了以下这些实用的建议：

让系统更简单：

更少的数据库 (理想情况下是一个)

规范化，减少冗余数据

一个“好的”数据库设计

ACID 事务

更多的数据约束

让系统更复杂：

多个数据库

冗余或非正规化数据

糟糕的数据库设计

较少（或没有）数据约束

当然，有时候让系统变复杂也是有正当理由的，我并不想让复杂性变成一个“肮脏的”词。请参阅后面的一个原则“杀鸡不要用牛刀”。

我认为这个原则是当今软件工程中最被低估的原则之一。一致性问题经常被忽视。很多问题，我敢说大多数问题，基本上都是一致性问题——数据不符合某些期望。

原则三 数据设计先行

这个问题，“代码还是数据？”，哪一个在 10 年后更有可能继续存在。

代码可以被丢掉重写，但数据很少会这样。

数据比代码更重要。代码的唯一目的是转换数据。

在设计新系统时，最好先从数据库和数据结构开始，并在此基础上开发代码。要考虑可以在数据上施加的约束并实施它们，理想情况下是通过表示数据的方式进行的。

代码设计是数据设计的下一步。数据模型越简单、越一致，代码就会越简单。

你们把流程图给我看，但把表藏起来，我就一头雾水。你们把表给我看，通常我就不需要你们的流程图，它们会不言自明。—— Fred Brooks

糟糕的程序员关心代码。好的程序员关心数据结构和它们之间的关系。—— Linux 之父 Linus Torvalds

原则四 杀鸡不要用牛刀

这是软件开发人员最常犯的错误。

这个原则是说，当你在做需要付出复杂性代价的权衡时，要确保权衡的必要性得到经验证据的支持。

常见错误：

试图构建一个复杂的“可伸缩”系统，可以伸缩到你可能永远都不需要的规模。

在不考虑需求或成本的情况下，让服务尽可能地小。

在非性能瓶颈的地方优化性能，增加不一致性或复杂性。

建议：

尽可能从最简单、最正确的系统开始

对性能进行度量

如果不能解决实际问题，就不要付出复杂性代价或违反其他原则。

有些优化可以不进行度量，因为它们的成本非常低或为零。例如，为了保证你想要执行的操作具有你想要的性能，使用正确的数据结构。

的确，有时候经验本身就能告诉你是否做出了正确的权衡。但如果你能证明，那就更好了。

当你必须做出选择时，请选择正确性和简单性，而不是性能。

在某些情况下，正确而简单的代码是性能最好的代码！

真正的问题是程序员在错误的地方和错误的时间花了太多的时间在担心效率上。过早优化是编程中所有（或者至少是大部分）罪恶的根源。——计算机科学家 Donald Knuth

原则五 避免为了局部简单性而增加全局复杂性

也就是避免为了让系统的一部分变得更简单，而导致整个系统变得更复杂。

这种交换通常是不平等的。追求局部的简单性会导致全局复杂性的增加，而且是数量级的。

例如，使用较小的服务可以让这些服务变得更简单，但一致性的降低和对更多进程间通信的需求让系统变得更加复杂。