【易龙天】5个有用的软件开发原则
我总结了一些软件开发原则。在这些原则中,大多数都是以简化系统为核心。在我看来,简单的系统会更可靠,更容易修改,而且一般更容易使用。当观念发生改变时,我希望更新它们。对数据施加一致性规则,减少了系统需要处理的状态数量。这是从上一个原则派生而来的。这里说的是一致性的普遍含义:即数据遵循某些规则,并且在任意时刻都始终遵循这些规则。这一定义与 ACID 有关,但不要与 CAP 混淆起来了。规则可以是任何东西,例如,你的信用永远不能变成负数,或者私密的帖子不应该被其他人看到。它不仅限于外键或惟一索引,尽管它们也是有效的规则。和数据库一样,应用程序也可以通过使用 ACID 事务来加强一致性。如果能在数据库级别强制保持一致性是最好的,但在实际中,对稍微复杂一点的东西来说,这样做并不常见。任何限制或损害一致性的行为都会导致复杂性。这就引出了以下这些实用的建议:
更少的数据库 (理想情况下是一个)
规范化,减少冗余数据
一个“好的”数据库设计
ACID 事务
更多的数据约束
多个数据库
冗余或非正规化数据
糟糕的数据库设计
较少(或没有)数据约束
当然,有时候让系统变复杂也是有正当理由的,我并不想让复杂性变成一个“肮脏的”词。请参阅后面的一个原则“杀鸡不要用牛刀”。我认为这个原则是当今软件工程中最被低估的原则之一。一致性问题经常被忽视。很多问题,我敢说大多数问题,基本上都是一致性问题——数据不符合某些期望。这个原则是说,当你在做需要付出复杂性代价的权衡时,要确保权衡的必要性得到经验证据的支持。
尽可能从最简单、最正确的系统开始
对性能进行度量
如果不能解决实际问题,就不要付出复杂性代价或违反其他原则。
有些优化可以不进行度量,因为它们的成本非常低或为零。例如,为了保证你想要执行的操作具有你想要的性能,使用正确的数据结构。
的确,有时候经验本身就能告诉你是否做出了正确的权衡。但如果你能证明,那就更好了。
当你必须做出选择时,请选择正确性和简单性,而不是性能。
在某些情况下,正确而简单的代码是性能最好的代码!
真正的问题是程序员在错误的地方和错误的时间花了太多的时间在担心效率上。过早优化是编程中所有(或者至少是大部分)罪恶的根源。——计算机科学家 Donald Knuth
不要太关心技术的复杂细节,因为你可以随时查阅它们。你要学习底层的基本概念。技术会变化,概念却是永恒的。你学到的概念将被用在更新的技术中,你就可以更快地学会新技术。例如,不要太关注 React、Kubernetes、Haskell、Rust 的表面细节。
纯函数式编程
关系型模型
规范的方法
逻辑编程
代数数据类型
类型类 (通用的和特定的)
借位检查器 (仿射 / 线性类型)
依赖类型
Curry-Howard 同构
宏
同像性(Homoiconicity)
VirtualDOM
线性回归
......
如果你和队友之间的共同原则越多,就能越好地在一起工作,而且你会越喜欢和他们在一起工作。这是我能想到的最简单的例子,希望能毫不费力地与现实问题联系起来。假设一个数据库有两个布尔变量 x 和 y,你的应用程序有一个规则,即 x = y,可以通过使用一个事务修改这两个变量来执行这个规则。如果这个规则被正确执行,那么数据只有两种状态:(x = True,y = True) 或 (x = False,y = False)。基于这个规则的函数“toggle”就非常简单。你可以读取其中一个值,并将两个值都设置为反向值。现在,假设你将这两个变量放到不同的数据库中,并且不能再被一起修改,那么会发生什么?因为你不能确保 x = y 的一致性,所以数据可以有两种以上的状态:(x = True,y = False) 或 (x = False,y = True)。
当然,如果我们一开始就遵循“剔除无效状态”的原则,那么将只有一个变量!