9月 162010
 

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一定能获得更大的成功。

 回复

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>