在腾讯8年多，我做过很多”发光发热了一段时间”的项目，比如 webqq、qq群空间等等。

腾讯文档是第一个从0到1，且目前看起来还保持着良好生命力的业务。

作为一个天赋平平，也不算特别努力的普通开发人员，能从员工成⻓到 tech lead 还通过了T12和T13的晋级答辩，如果不是跟随腾讯文档一起成长，我想这些对我来说是不可能的事情。

也从心底感谢腾讯文档项目，让我这种对架构设计有一些兴趣的前端开发有了一些用武之地。希望在不久的将来，能让更多人认可腾讯文档。

十年架构：

在线文档是一个生命周期很长，且相当复杂的项目，office和wps都已经有30多年历史，腾讯文档到目前经历了3年的迭代开发，对于有些项目而言也算一个不短的时间了，但在在线文档行业内似乎还处在婴儿阶段。在往后漫长的时间内，除了繁杂而艰难的日常维护工作之外，也许还会经历很多次大型技术升级，为了减少这些时候付出的代价，我们希望整个系统是构建在抽象之上的。在线文档的业务和技术特点，决定了它需要具有非常抽象和稳定的底层架构。

底层架构的打磨和暂时的产品功能一样重要。随着用户数量的增加，几百万用户和几亿用户面临的问题域与问题难度也完全不一样，只有当底层足够合理和扎实，产品的优势才会随着时间流逝慢慢体现出来。

腾讯文档从一开始就比较注重底层架构的健壮性，在架构打磨上花了一些时间和精力，比如底层的协同处理我们一开始就选择了业界最复杂和难度最大的方案，效果也是明显领先竞品的，前段时间河南灾情也承担住了400人同时协同编辑。再比如渲染层方面，我们一开始就选择自研canvas渲染层，竞品都是在用了2年商业库之后再转向自研canvas，这方面先积累下来的经验也是我们的优势。

所以，相信前期花在架构打磨上的时间是值得的。也许这个产品在我们这批人的手中始终不足以做到90分，但我们依然想保留它在将来能达到90分的可能性。

重视竞品技术分析的重要性：

在线文档是个既很旧又很新的领域， 旧是因为本地文档，如office、wps已经有30多年的历史，在线文档的优秀代表谷歌文档也面世已经20年，新是因为市面上几乎没有在线文档相关的技术资料积累，对于每个进入在线文档领域的团队来说，很多技术方案都需要从0开始摸索。

而且在线文档的技术方案是具有很强延续性的，今天的一个技术方案的决策，可能会影响到3年之后的某个需求，如果这个决策是错的，对业务就会造成难以回滚的伤害。

所以团队平时也非常重视竞品技术分析和调研的重要性，在一些复杂需求中，竞品技术分析调研花掉的时间可能比正常的需求开发时间要长。一般我们会把竞品分成谷歌文档和其他文档。根据经验，前者能让我们知道这个需求的上限在哪，后者可以让我们知道下限在哪，清楚上限和下限之后，对自己的选择也更有信心。

团队规模这一年扩张了很多，许多新同学还不太理解竞品分析的意义。希望这些同学看到这一段之后，能够多多理解，把竞品分析摆在一个非常重要的位置。

站在巨人的肩上

从进入腾讯文档项目第1个月起，我就明白以我们这批人的经验和智商，在几年的时间内，无论如何是追不上微软，谷歌这么多年的积累的。这是客观现实规律，不是喊喊口号就能解决的问题。

但好在我们是后发者，即使缺少文档或者代码，我们也可以根据一些产品表现，来猜测和反复验证什么方法大概率是最正确的。实际上这几年腾讯文档的业务的很多技术方案，都是仔细研究过谷歌文档、office、vscode等这些优秀项目之后的决策，站在巨人的肩上能看的更远，相信能帮助我们少走很多弯路。

针对自身业务特性进行创新

office和谷歌文档这样的项目固然很优秀，但一方面，它们毕竟也是30年多就已经上线的产品，到现在其实也存在不少历史包袱。另一方面，腾讯文档和它们的业务特性还是有不少区别。我们可以结合自己的业务特性和技术强项，做许多的创新工作，比如腾讯文档doc，在业界第一个使用了自研canvas渲染层，sheet也是国内第一个使用了自研canvas渲染层，都取得了不错的业务收益。我们在架构上参考了许多vscode的方案，也在解决在线特性上做了许多技术上的创造和优化。

架构优化要和产品节奏配合

架构优化总会占用很多时间和人力，而产品迭代速度是一直要往前奔跑的。产品同学有时候能理解架构优化带来的作用，但有时候又没那么容易理解。

这不是技术架构师和产品负责人的战争，我们最终共同目标还是希望在激烈的市场竞争环境下，我们的产品有机会提供给更多人使用。

要平衡好架构优化和产品迭代之间的关系并不是特别容易。一味的追求架构优化、代码优化是不划算的，在什么时候，以什么方式来提升业务技术架构，是拆迁式重构、还是渐进式重构，都根据不同的产品和技术的不同阶段，结合内外部许多因素综合考虑。