编程与软件工程ckeditor.com
打造实时协作富文本编辑器的经验教训
Lessons learned from creating a real-time collaborative rich-text editor
2018 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
CKEditor 团队复盘开发实时协同富文本编辑器的经验教训：包括为何选择 OT 而非 CRDT、重写旧版编辑器的风险（避免重蹈 Netscape 覆辙），以及项目惊人的投入规模（42 人年、12500 个测试、100% 覆盖率）。文章也解释了为什么富文本的实时协同比一般场景复杂得多。
为什么经久不衰：协同编辑是分布式系统的经典难题，这篇来自一线团队的深度复盘在 OT/CRDT 之争持续多年的背景下始终有参考价值。
HN 评论精选
赞赏团队成功完成重写，并期待 OT 与 CRDT 对比的分析
「我们曾非常担心重蹈 Netscape 的覆辙——那是决定从零重写热门软件却未能成功发布新版本的著名案例。幸运的是我们没有重蹈覆辙。」向成功做到这一点致敬！另外期待你们写下对 OT vs CRDT 之争的看法。
codetrotter查看英文原文
> We were quite seriously scared of repeating the infamous history of Netscape which was a well-known example of failing to successfully release a newer version of a popular software after deciding to rewrite it from scratch. Fortunately it did not happen in our case. Big kudos for pulling it off! > Two main candidates are Operational Transformation (OT) and Conflict-Free Replicated Data Type (CRDT). We chose OT and perhaps one day we will write down our thoughts on the ongoing OT vs. CRDT battle. Please do, I would love to hear your thoughts on OT vs CRDT!
用项目数据说明高质量软件的成本之高
测试数量：12500；代码覆盖率：100%；开发团队：25+ 人；预估工时：42 人年（截至 2018 年 9 月），还包括开发 mgit 和文档生成器 Umberto 等配套工具的时间。软件真贵。
fabricexpert查看英文原文
> The number of tests: 12500 > Code coverage: 100% > Development team: 25+ > Estimated number of man-days: 42 man-years (until September 2018), including time spent on writing tools to support the project like mgit and Umberto (the documentation generator used to build the project documentation) Software is expensive
推荐更轻量的差分同步方案，称其实现成本低得多
对这个问题感兴趣的人建议看看 Neil Fraser 的「差分同步」（Differential Synchronization）。我作为独立开发者只花了两周就用这个方法给产品加上了实时协同编辑。
pg_bot查看英文原文
For anyone interested in this issue I would suggest taking a look a Neil Fraser's Differential Synchronization.[0] It took me 2 weeks as a solo developer to add real time collaborative editing to our product using that method. [0]: https://neil.fraser.name/writing/sync/
认同 CKEditor 的设计质量，并指出协同问题空间比想象中更深
CKEditor 做得很出色，尤其是协同方面的设计。文本编辑器的设计会直接影响接入协同的难易度。很多人并不直观理解为什么实时协同是个难题：对很多场景 websocket + last-write-wins 就够了；富文本为何需要更复杂的冲突解决并不显而易见；解决了富文本问题也不意味着能直接推广到其他问题。我们在 2017 年底开始时选了 CRDT，因为那时 CRDT 刚开始能与 OT 匹敌。
sambroner查看英文原文
Disclosure: I work on a related project (Fluid Framework) that makes application agnostic CRDTs easily available. The CKEditor folks did a great job building an OSS text editor and they did an especially strong work building a text editor that works well with collaboration. I've made a few OSS rich text editors work (mostly) with Fluid [0, 1] and the design of the text editor really changes how easily collaboration can be added. Luckily the text editor accepts remote changes, integrating an OT or CRDT solution is approximately the same. They also did a great job explaining the problem. My experience has been that people don't intuitively understand why real time collaboration is a tricky problem. I didn't. First of all, for a bunch of use cases websockets + redis + a last write wins conflict resolution (or some similar solution) is totally enough. Second, it's not immediately obvious why rich text editing requires more complex conflict resolution. Third, it's not obvious why solving the RTE problem doesn't immediately lend itself to other problems [2]. Because we started building in mid-late 2017, right as CRDTs really started to get competitive with OT, we chose a CRDT approach, but the collab problem space in general is much deeper I realized before getting into it. Anyway, I always appreciate seeing people explain their journey. Especially when it has to do with collaboration. [0] https://fluidframework.com/playground/?path=/docs/react-demos-draft-js--demo [1] https://github.com/microsoft/FluidFramework/tree/main/examples/data-objects/prosemirror [2] https://www.youtube.com/watch?v=x7drE24geUw
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选