Go rqlite 作者：7 年的开源数据库开发经验总结

那是 2016 年 4 月 9 日，我标记了 我的第一个正式版本 的 rqlite —— 在真正开始编写它的两年后。
从那时起，已经有 58 个版本、277 个已关闭问题、416 个关闭的拉取请求、32,785 个插入、1954 个删除和 100 个文件已更改。

rqlite是什么？

rqlite 是一个用 Go 编写的轻量级开源分布式关系数据库，使用 SQLite 作为其存储引擎。我 开始编写它的时候只是为了好玩，但后来慢慢的发现它变得越来越重要了。那么在过去的 7 年里，我从开源 数据库开发 中学到了什么呢？

一次一个功能

当我试图重写 HTTP 服务层 并 替换 Raft 共识 子系统时。 然而。

工作量太多了, 带来了 第二系统效应 , 然后我放弃了这样做。 在我意识到实现变得臃肿之前，开发工作花费了我好几个星期的时间。因此我学到了宝贵的一课 — 将更改保持在较小的范围内，一次只专注一个功能。

尝试绘制任何新设计和实施的增量路径。尽可能定期发布，并尽快将更改返回主线。并且要警惕没有明确的中间交付物的大规模重写， 这不能满足实际需要。

创造力是不稳定和不可预测的

我在一个周末就添加了一些最重要的功能.

最好的时刻往往是连续的、高强度的多日时段，在编写一行代码之前，我可以在脑海中看到新系统的形状。我曾经完全重新设计并重新实现了HTTP API在一个周末，它推出了rqlite 2.0版——而且比以前好多了.

又是一个周末我迁移了Raft log使用Protobuf编码而不是JSON.接下来的一周，我添加了压缩功能-这一切都很完美.

但有时几个月过去了，我什么也不做。这至今仍是一种模式。我经常想，如果我在数据库上扎实地工作一年，我会取得多大的进步。

测试的重要性

我确信是广泛的测试覆盖率保持了代码的高质量。我从用户那里收到报告说，rqlite实例已经运行了一年多，而不需要重新启动。

我非常坚持测试金字塔哲学。编写尽可能接近实际代码的测试用例——这会产生巨大的差异。不要忽略测试失败或尝试对其进行编码测试不会因为神奇的原因而失败——它们告诉你你没有完全理解你所构建的东西。

继续进行冒烟测试的集成测试，以确保数据库实际启动，并且没有遗漏任何基本内容. 只有当无法执行代码时，才应使用端到端测试，除非软件的实际完整实例正在运行。即使是这样, 它可能会告诉您一些关于您的实现的信息——您的软件不够模块化, 或者您的接口不够正交。

单元测试一直是关键。如果在单元测试级别没有出色的覆盖率，您的软件将永远不会是高质量的。

Go 经受住了时间的考验

我一直对Go)印象深刻-它一直是我最喜欢的编程语言。 而且我一直很有效率 差不多7年过去了，我仍然喜欢它。rqlite开发周期之间的时间间隔是几个月，当我回到代码中时，我发现我仍然没有忘记我的Go使用风格和模式。

宣传很难

我为这个挑战编写了数据库——我能否创建一个有趣的系统，以维护一个干净的设计和连贯的实现？并保持高质量？我想我可以，这样做表明我可以——而且这通常就足够了。但当人们使用它时，它也会令人满意。

但宣传是困难的。它已经在Hacker News上出现过好几次了。我已经在Meetups谈过了.在GitHub上，我们花了7年的时间获得了8000颗星星,这很好吗？我不知道我是否应该关心？我也不知道。

编程是最重要的

我以管理程序员为生 这是一个有趣的工作,但与自己编写代码不同. 作为一个团队编程 需要就编码风格、错误解决策略达成一致, 代码审查, 以及功能优先级。作为一个团队构建软件需要很多非编码活动。

因此，从事自己的项目是一种解放。由您决定编码样式。由您决定功能。您可以决定修复哪些bug。你不去开会

这也说明了为什么跨入多个开发人员的世界会减慢进度。当涉及到设计的连贯性和清晰性时，没有什么能打败单一的思维和单一的愿景

7年了，还有很多事情要做

rqlite已经存在了7年，还有很多事情要做

事务，更好地使用 客户端库,本身支持 Kubernetes ，性能—软件的吸引力在于无限的可扩展性，总是可以改进的。我相当肯定，它永远不会到达我会说“完成了”的地方。

相反，就像一个老兵, 它可能会慢慢消失.

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://www.philipotoole.com/7-years-of-...

译文地址：https://learnku.com/go/t/64508