Comsenz质疑:Comsenz的7个短视之处

刚才写了一篇质疑的文章，本来准备接受一堆口水，没想到却大多数是支持的声音，着实让我感到意外。我这人就是骨头比较轻，既然有人支持，我对Comsenz的其他意见全都说出来吧。

强调一点，我写这些不是讨厌Comsenz，而是因为我欣赏Comsenz，希望它变得更好。

1.顽固坚持php4，迟迟不愿拥抱php5

其实这是我最不能理解的一点，Discuz现在的代码竟然还是以php4.3.0为最低标准的。

这种做法虽然说可以做到最大限度的兼容，php4的运行效率也确实比php5高不少。可是为了向下兼容，不得不牺牲很多高版本php的优秀特性。事实上，php5已经在各方面非常完善，面向对象方面的支持全面提升，PDO, json等类和函数相比php4强大太多了。

在CPU并行性能空前强大，内核数量4个8个12个递增的今天，php运行效率真的有那么重要吗？要知道现在web2.0网站的第一瓶颈是数据库服务器，而不是php服务器，即使php服务器压力较大，也有反向代理、动态DNS等各种各样简单有效的负载均衡方法解决。真的有必要为了些许的php运行效率，而放弃高版本php的强大功能吗？

2.代码架构混乱，不采用MVC框架，不面向对象

说实话，写了12年程序，Discuz代码我是下了十几次决心才敢开始阅读的。因为这套代码实在非常丑陋。

和我一起创业的同伴一直和我有一个争论，他坚持认为discuz发布出来的代码一定是生成出来的，内部开发的时候一定是另外一种结构。因为他认为discuz代码的可读性已经远远超过了正常人理解能力。

虽然康盛一直试图改进代码结构，在最新的Discuz!X中，我们看到他整齐的把function, class, plugins放在各自的目录里，但由于它不采用php5，也不采用MVC框架，因此代码中仍然充斥着global, require_once等等，和系统底层紧耦合且效率低下的糟糕写法。

由于没有运用MVC框架，也不面向对象，导致了插件机制难以实现，二次开发举步维艰。其实这对Comsenz自己开发团队成员，也造成了单元测试的困难。

3.缺乏国际化的眼光，偏爱gbk而不选择utf8

之前Discuz7.0beta发布的时候，有用户在论坛里问为什么只有GBK版本，没有utf8版本。当时有一个管理员回答：想不明白为什么有人不用GBK。

我当时就惊了。我自己做的网站，有很多留学生，动不动就会出现一些稀奇古怪的语言文字，如果没有utf8，可能有一半的文字表示不出来。

撇开我这种特殊案例不谈，utf8几乎从诞生之初，就成为了世界开源php界的标准。绝大多数的开源项目，wordpress, joomla, drupal, phpmyadmin, mediawiki都是只有utf-8版本的。

因为只有utf-8才能完美兼容多语言，并且可以实现用户界面的语言本地化。

其实按Discuz的实力，绝对不弱于国际上流行的phpbb，为什么comsenz不把眼光放长远一些，用心做一下多语言支持，抛出一个英文版让老外见识一下中国开源项目的实力呢？

4.插件机制落后

这两年来，我开始越来越多地使用wordpress建设各种CMS，越发体会到wordpress插件机制的好处。

虽然wordpress只是一个功能并不全面的博客程序，但是通过wordpress无处不在的插件机制，有数不清的开发者创造出了各种有想象力的插件，全方位地拓展了wordpress的功能。

现在每当我希望为wordpress程序增加什么功能，首先会去wordpress搜索相关插件，几乎每次都能找到满意的插件，省却了我大量二次开发的工作。同时，我至今仍然没有修改wordpress的一行代码。因为所有我的需求，都能通过插件，或者修改插件就能实现，不会污染wordpress核心代码。

而反过来看discuz，几乎每次discuz升级，都会是二次开发者的噩梦。因为他们总是被迫去修改discuz的核心代码。一旦discuz升级，那么这些二次开发代码就会被覆盖。这完全是因为discuz本身没有留下必要的插件接口，开发者才会被迫污染核心代码。

就算在Discuz当道，市场占有率超过75%的今天，Discuz插件依然少得可怜，不能不说是一个遗憾。

事实上，一个开源程序是否强大，并不在于它的功能有多丰富，而取决于它是否容易扩展，有丰富的第三方插件。

5.功能设计庸俗化，就事论事

童虎在Discuz7.0.0发布之后，预告7.1.0的改进方向，说是强化道具中心。我当时就绝望了。

难道Comsenz真的相信，靠一个道具中心，几张卡片就能让社区活跃起来吗？用户参与社区的原因难道是因为它有好玩的道具，而不是社区的人和内容吸引他？

其实，论坛的骨架，discuz7.0就已经搭得非常好。7.1和7.2的功能，基本上都是一些附加额外的功能，且这些功能普遍很庸俗，只会让社区变得复杂，难以学习，并无法本质上提升用户黏性。

我觉得原因在于，Comsenz团队实在太为站长着想了，以至于站长有什么要求，就往什么方向改进。这种就事论事的做法，看起来是为站长着想，事实上效果并不理想。因为很多时候，站长出现“强化道具中心”、“强化任务系统”的需求，是因为更深层次的活跃社区的需求，而这种需求可以通过改进社区的交互机制来实现，不应该从表面上解决它。

再拿“回复可见”帖的功能来说，根本就是个自相矛盾的悖论，这种设计绝对是中国特色。国外论坛根本没有回复可见的功能。“我连你正文内容都没看到，你让我回复你些什么？”在没有看到内容的情况下，用户的回复，往往空洞没有营养，说一些无关痛痒的废话，或者是双手支持的话。这种跟贴，表面上活跃了论坛，实际上产生了很多无意义的回复，反而影响了正常的交流。本来后面跟贴可以讨论主题内容的，结果全变成了为看帖子而发的无意义帖子。

再换一种角度看，放眼望去现在成功的web2.0网站，人人、豆瓣、大众点评、facebook、twitter，有哪一个是依靠道具中心和任务系统成功的？如果这招数真的管用，他们为啥自己不用？

我完全理解中国国情，很多网民对这些功能确实乐在其中。但是道具中心、任务系统、勋章中心这类功能完全可以以插件形式和核心代码解耦，让站长自由选择装还是不装。为什么要给核心代码加上这些臃肿的累赘呢？

6.版本号混乱，发布仓促

每次Discuz发布新版本，都是一个非常惊心动魄的过程。因为很有可能，你抢先去下载的刚发布版本，在下一秒，就已经发现bug被官方更新了。于是我们在主题帖内会看到：x月x日15点30分以前下载代码的用户，请安装补丁包，之后下载的用户无需安装。

另一方面，Discuz的软件版本号，光用x.1.0是不能描述清楚的，因为后面还有一个更新日期。这个更新日期才是决定版本相同相同与否的关键所在。

我当然非常欣赏Comsenz从善如流，发现bug之后迅速反应的精神。但是，开源项目新版本发现bug很正常，用户会理解的，何必这么心急非要在当天就修正，搞出各种各样的补丁包，让用户困惑呢。事实上，即使修正了刚刚发现的bug，并且重新打包发布了，下一秒可能又有新bug发现了。于是每个新版本发布时，实际上都会有2-3个相同版本号，相同更新日期，但是打包发布时间不同的文件存在。

既然用了x.1.0这样的三位版本号，为什么不采用开源界通用的标准。第一位表示主版本，引入关键特性时增加，第二位表示小版本，引入次要特性时增加，第三位表示补丁，修正bug时增加。这样，即使频繁发布新版本，也不会让用户产生困惑。

7.开发过程封闭化，缺乏开源人士参与

虽然Discuz!是一个开源程序，但是实际上，它开放的只有源码而已。他的整个开发过程都是全封闭的，以至于站长们可能会有整整一年时间不知道Comsenz在干什么。bug反馈，到现在仍然在采用发帖的方式。

既然丑媳妇总要见公婆，为啥不把开发过程开放出来？让更多的开发者参与到Discuz的开发过程中，受益的肯定是Comsenz。

戴总可能会说，内部代码都是带注释的，每次出新版本才打个包放出来。那也没关系，把代码隐藏了，用trac做一个规范的bug提交反馈系统，允许用户给系统提建议也可以啊。

所谓“成也萧何，败也萧何”，Comsenz因为把握中国国情而获得了巨大成功，但不要因为中国国情而限制了自己的视野。多向国外成功项目学习，相信Comsenz一定能获得更大的成功。