百度 UEditor 编辑器创始人战毅专访

UEditor是一套开源的在线HTML编辑器，是由百度Web前端研发部开发所见即所得富文本Web编辑器。

UEditor在设计上采用了经典的分层架构设计理念，尽量做到功能层次之间的轻度耦合。具体来讲，整个系统分为了核心层、命令插件层和UI层这样三个低耦合的层次。其具有体积小巧、性能优良、使用简单、分层架构，方便定制与扩展等特点。

我们采访了UEditor项目的创始人和核心开发者战毅，请他来详细介绍一下UEditor。

ITeye期待并致力于为国内优秀的开源项目提供一个免费的推广平台，如果你和你的团队希望将自己的开源项目介绍给更多的开发者，或者你希望我们对哪些开源项目进行专访，请告诉我们，发站内短信给ITeye管理员或者发邮件到[e-mail]即可。

UEditor项目是怎么诞生的？

最早是起源于百科，是为百科用户书写百科词条开发的在线编辑器。那时还没有UEditor，就是直接拿CK（CKEditor）作为底层，在上边开发了UI展示组件。

但随着需求的变化，发现项目越来越不可控，因为CK过于复杂。2010年，代码已经有10万行了，做新的功能和修改bug都非常的困难，做编辑器项目的时间远远大于其他项目，而且因为用的是ck底层代码，他很多自身的bug我们无法修改，一旦有修改，可能会引起其他一系列的bug。

那时开会编辑组经常会被问到"bug收敛了吗"，尽管我们已经非常努力了。因为这样编辑器被冠以最费力不讨好的项目。做走了很多人，基本上能坚持1年的算很长了。我印象最深的是做空间编辑器项目时，有个QA的MM，一做完编辑器项目就辞职了，原因是太累了。编辑器项目那时完全没有自动化用例，全靠手动测试，我要是修改一个底层代码，那QA要把所有的手动用例都过一遍，可以想象那是多么的痛苦。

基于这些原因，UEditor诞生了，诞生它的想法很简单，就是我们要有一个我们自己完全可控的编辑器，可以满足pm的各种需求和修改各种bug。当时开源的目的就是想能从外部吸收更多的需求和bug，来更好的满足产品线，当时完全没想到，UEditor能做到今天这样，大家都在使用的局面。

目前已有一些优秀的编辑器，为什么还要开发一个？与它们相比，UEditor有哪些更贴近国人使用的特性？

主要是因为我们需要一个我们自己完全可控的编辑器。（例如，添加新功能和bug修改）。UEditor现在的功能比ck更加丰富，而且比他要小的多，整体的架构更加清晰。

UEditor的宗旨是打造“最佳的用户编辑体验”，我们在许多细节上完全是效仿Word的实现方式，比如对于多级列表、中文标示的列表、表格的操作、插入代码、粘贴过滤的支持、tab键的支持等等。

在UEditor开发过程中最难的地方是什么？你们是如何解决这一问题的？

最难的地方是应该是对range的封装，这是编辑器实现的基础，所有功能实现的核心。

要说解决，那就是自己实现一套，这样才能真正了解和掌握它。对于这块的实现，主要是参考了ck，因为到目前为止，对外的编辑器项目中只有ck和tinymce包括UEditor才是真正用JS实现range，而没有借助编辑器的原生接口。至于为什么不借助原生接口，大家可以看看5月份的程序员杂志，我写了篇《从UEditor谈Web编辑器技术》，详细介绍了这块。

UEditor在百度内部的使用情况如何？使用UEditor的其他公司或项目有哪些？

百度内部基本上是全线覆盖了所有对于富文本这块有需求的产品线，现在还在为最后一个产品线百度贴吧，做定制编辑器，做完这个项目，就是100%覆盖了百度的所有产品线了。

在外部，像奇虎、腾讯、盛大、网易、联想等大公司，都在他们的很多项目里使用了UEditor，像51cto、中关村在线、音悦台等主流网站也在使用。还有像很多cms系统也都集成了UEditor。现在，UEditor是国内使用量最多的富文本编辑器项目。

UEditor团队有哪些成员？你们之间是如何分工和协作的？

我们现在开发有3个，2个QA同学。上次发布1.2.6时，第一次发布了我们QA同学给我们发的bug列表，当时吓到了好多人，大家都觉得怎么这么多，其实这只是冰山一脚。大家要是看过我们git上的test目录，那里有好几千个自动化用例，这都是QA同学的心血。

一般我们开发一个版本后（包括新功能的测试用例），提交给QA，QA同学进行2-3轮的测试，在这过程中，我们也会对外发布一个线上的测试版本，让大家来帮我们一起测试，最后发布正式版本。

对于发版本的周期，基本上是没有的，就是产品线一闲下来，我们就把一些用户反馈的功能和问题，包括给产品线开发的功能，改造成通用的一起放到新版本里发布。