我总结了一些软件开发原则。这些原则中的大多数都以简化系统为中心。在我看来，更简单的系统会更可靠，更容易修改，而且通常更容易使用。当观念改变时，我想更新它们。1消除无效状态我把这个放在第一位是因为我认为它是最重要和最强大的原则之一。你可能在定义类型时听说过这个术语，但这个原则适用于所有与表示数据有关的事情——比如数据库设计。它不仅减少了系统中的状态数量（从而使其更简单），还减少了无效状态的数量！您的系统不需要处理这些无效状态，因为它们实际上无法在您的程序中表示。这不仅仅是一个小技巧，它可以大大简化您的系统并防止各种类型的错误。这里有些例子。2.数据一致性让系统更简单。将一致性规则应用于数据可以减少系统需要处理的状态数量。这是从前面的原理推导出来的。这里的定义是一致性的一般含义：即数据遵循一定的规则，并且在任何时候都始终遵循这些规则。此定义与ACID有关，但不要与CAP混淆。规则可以是任何内容，例如，您的信用永远不应该变成负数，或者私人帖子不应该被其他人看到。它不限于外键或唯一索引，尽管这些也是有效的规则。与数据库一样，应用程序可以通过使用ACID事务来强制一致性。能够在数据库级别强制执行一致性会很好，但在实践中，稍微复杂一点的事情很少会这样做。实用建议任何限制或损害一致性的事情都会带来复杂性。这导致了这些实用的建议：使系统更简单：更少的数据库（最好是一个）规范化，减少冗余数据“好的”数据库设计ACID事务更多的数据约束使系统更复杂：多个数据库冗余或非规范化数据糟糕的数据库设计很少（或没有）数据约束当然，有时有充分的理由使系统复杂化，我不希望复杂性成为一个“一团糟”的词。请参考以下原则“不要使用大锤来killachicken”。我认为这个原则是当今软件工程中最被低估的原则之一。一致性问题经常被忽视。我敢说，很多问题基本上都是一致性问题——数据不符合某些期望。3数据设计是第一位的带着这个问题，“代码还是数据？”，哪一个更有可能在10年后存活下来。代码可以被丢弃和重写，但数据很少。数据比代码更重要。唯一的目的是f代码是转换数据。设计新系统时，最好从数据库和数据结构开始，并在此基础上开发代码。考虑可以对数据施加的约束并强制执行它们，最好是通过数据的表示方式。代码设计是数据设计的下一步。数据模型越简单、越一致，代码就会越简单。你给我看流程图，却把表藏起来，我手足无措。你给我看表格，通常我不需要你的流程图，它们会自己说话。—FredBrooks糟糕的程序员关心代码。优秀的程序员关心数据结构以及它们之间的关系。——Linux4之父LinusTorvalds不要用大锤杀鸡这是软件开发者最常犯的错误。该原则表示，当您进行以复杂性为代价的权衡时，请确保权衡的必要性得到经验证据的支持。常见错误：试图构建一个复杂的“可扩展”系统，该系统可以扩展到您可能永远不需要的大小。在不考虑需求或成本的情况下，使服务尽可能小。在不是性能瓶颈的地方优化性能，增加不一致或复杂性。建议：从最简单和最正确的系统开始，并衡量性能。如果它不能解决真正的问题，请不要付出复杂性的代价或违反其他原则。一些优化可能无法测量，因为它们的成本非常低或为零。例如，要确保您要执行的操作具有您想要的性能，请使用正确的数据结构。事实上，有时经验本身可以告诉你是否做出了正确的权衡。但如果你能证明这一点，那就更好了。当你必须选择时，选择正确性和简单性而不是性能。在某些情况下，正确且简单的代码是性能最好的代码！真正的问题是程序员在错误的地方和错误的时间花太多时间担心效率。过早的优化是编程中所有（或至少是大多数）罪恶的根源。—计算机科学家DonaldKnuth5为了局部简单而避免全局复杂性就是避免使整个系统变得更复杂以便使系统的一部分更简单。这种交换通常是不等价的。追求局部的简单性会导致全局复杂性的增加，而且是数量级的。例如，使用更小的服务可以使这些服务更简单，但一致性的丧失和更多进程间通信的需要使系统更复杂。6.认识内在的复杂性有时候事情太复杂了，你无法简化它们。任何此类尝试只会使系统进一步复杂化。7使用的技术越少，系统就越简单。深入了解一小部分技术，总比肤浅地了解许多技术要好。更少的技术意味着更少的学习和更少的操作复杂性。8.专注于学习概念，而不是技术不要太担心技术的复杂细节，因为你总是可以参考它们。您必须学习底层的基本概念。技术在变，但理念是永恒的。你学到的概念会用在更新的技术中，所以你可以更快地学习新技术。比如不要太在意React、Kubernetes、Haskell、Rust这些表面的细节。主要学习内容：纯函数式编程关系模型规范逻辑编程代数数据类型类型类（通用和特定）借用检查器（仿射/线性类型）依赖类型Curry-Howard同构宏同构（同象性）VirtualDOM线性回归...9代码一致性重要有时，拥有一致的代码比“正确”的代码更重要。如果要更改代码库中某些代码的行为，则必须修改它的所有实例。否则，就只能忍着了。代码可读性更多地与一致性而非简单性有关。人们通过模式识别来理解代码，所以重复（和记录）模式！10共同原则很重要你与队友的共同原则越多，你们就能更好地一起工作，你也会越喜欢与他们一起工作。11附录：不一致导致的复杂性这是我能想到的最简单的例子，希望能毫不费力地与实际问题联系起来。假设一个数据库有两个布尔变量x和y，您的应用程序有一个规则x=y，可以通过使用事务修改这两个变量来强制执行。如果正确执行此规则，则数据只有两种状态：(x=True,y=True)或(x=False,y=False)。基于这个规则的函数“toggle”非常简单。您可以读取其中一个值并将两个值设置为相反。现在，如果将这两个变量放入不同的数据库并且不能再一起修改，会发生什么情况？因为您无法确保x=y是一致的，所以数据可以有两种以上的状态：(x=True,y=False)或(x=False,y=True)。如果您的系统处于这些状态之一，您应该使用哪个值？当处于这些状态之一时，“切换”功能如何表现？写入新值时，如何确保两次写入都成功？这些问题没有正确答案。当然，如果我们一开始就遵循“消除无效状态”的原则，那么变量就只有一个了！以上就是本次分享的全部内容。想了解更多python知识，请前往公众号：Python编程学习圈，发“J”免费领取，每日干货分享
