3月28日，戴志康释出了传说以久的内部代号为UltraX的体验版。大概是希望借用discuz已有的巨大号召力，UltraX在发布之前还是改成了discuz!X。
我在第一时间去discuz.org注册体验了一下，体验感受和我之前预计的相差无几，整理一下写出来，大家讨论：
(强调一点，我写这些不是讨厌Comsenz，而是因为我欣赏Comsenz，希望它变得更好。)
discuz!X的研究和质疑
SNS、门户、论坛互相冲突
X项目的最本质目的，应该是把Comsenz旗下的三大项目：Discuz、SuperSite和UCenter Home进行融合，减小项目和项目之间的隔阂，使之能更好地融合成为一个网站。
这一定是广大站长向Comsenz反应的一个共同心声。可是，站长们真的明白自己需要什么吗？融合了之后真的能让网站更好吗？Comsenz在大刀阔斧之前想清楚了吗？
一般来说，网站的内容质量从高到低可以分成三个档次：
媒体型，内容质量很高，有高水平的，固定成员的编辑团队。访问者到网站来大多数为了看内容，用户群结构上是一群读者围绕着一个牛人。这种类型适合建CMS型站点或者是博客。
草根型，虽然没有明确的编辑团队，但是大部分用户都有创造内容的能力，用户有时候会创造内容，有时候也会阅读评论内容。内容水平虽然够不上出版，但还不错，有信息量有价值，以垂直主题为核心。这种类型适合BBS形式。
灌水聊天型，用户的文化程度不高，讨论漫无边际，并且常会出现小圈子，用户和用户之间通过人际关系维系。这种用户类型适合建SNS站点。
不管是网站的哪一个板块，都大抵是同一批人在访问。同一批访客，就有相似的需求，具有相似的特性。基本上，个人站点都只能属于上述三种情况之一，而很少会出现媒体型和灌水型混合的情况。
我们看到过太多太多的网站，首页打开内容丰富品种繁多，但是毫无吸引力，大部分人都会在长长的菜单条里寻找一个叫“论坛”的东西。那才是网站有人气有内容的地方。
Discuz！X，说到底，只是在用户体验上对门户和论坛进行整合，可是从用户行为模式上，这两者恰恰是很难整合，甚至是格格不入的。网站一般只是上述三种模式之一，因此也只需要CMS、BBS、SNS三种系统之一。就算有些网站提供了多个系统，实际上，真正有人气的，也只有一个系统。与其做多个系统，只火一个，不如只做一个系统。
所以说整合是个无用功。
阅读方式无法融合
Discuz！X的融合计划，在体验上有一个致命伤，那就是阅读方式无法融合。
门户的内容展现方式，是报纸式的，长长的网页，左一块图片，右一块新闻列表，七拼八凑地一个新闻网站就出来了。可是用户的眼球也很累，东一下，西一下，他根本不知道自己应该用何种阅读顺序才能一笔画地把所有新闻看完。实际上，大多数用户都不会有耐心去把每一块的内容浏览完，而是会迅速找到自己关心的主题，点进去看新闻列表或者是博客列表。
论坛的方式是兴趣引导型的，在首页版面列表里迅速寻找自己感兴趣的版面，然后点进去开始阅读。
SNS的阅读方式是个人为中心的，在首页浏览长长的自己感兴趣的新鲜事列表，一页又一页。
三种系统的阅读方式截然不同，试问，用户怎么可能同时适应三种阅读方式？事实上，用户只会习惯性地去刷同一个页面寻找内容，而不会听话地把三个系统的首页都看完。
最终结果，正如前文说的，三个系统只火一个，另外两个成为摆设。
小组和论坛之间的尴尬关系
戴在新年的时候写了一篇文章，其中提到小组和论坛之间的相似性的问题。我满怀希望他能够想明白，把小组和论坛融合到一起去。可惜他没有这样做。目前小组和论坛的融合，只是功能和代码上的融合，概念上，仍然是独立的。
我曾经也坚定地认为，一个网站，需要有一些公共版面，也需要有一些兴趣小组。但实际上，这种设计是多余的。
小组的出现，就是为了解决网站版面太多时无从看起的困难，人大多数只会对某些少数版面感兴趣，通过加入小组，来表征自己对某些主题或者人群的偏爱。
实际上，即使是公共版面，也有人想看，有人不想看。为什么不把论坛版面和小组全部统一成小组，然后允许对小组做细节权限设定实现公共版面和兴趣小组的差别呢？
现在的discuz！X的做法，虽然在功能上做到了小组和论坛的统一。但是概念上，两者仍是不同的概念，导航结构上，属于两大不同的模块。并没有起到真正融合的效果。
排楼式帖子旧疾难改，点评模式治标不治本
中国式的论坛，有一个臃肿的坏毛病。每一个回复，都巨长无比，左边会加上用户的大头像，金钱、威望等等论坛概念的数值，甚至注册时间和最近登录时间。整一个人口普查。跟贴内容，就算只有一行字，后面也会跟着一个用户签名。更要命的是，有时候签名还是一张大图片。浏览者每一次看帖，累得要死，碰到这种大图片签名的用户，翻一屏才能看到一行字。
大多数的帖子，楼主的内容都是比较有价值的，比后面抢沙发板凳的无意义回复有价值得多。本来就不应该平等处理。跟贴内容往往就是几个字，一行字。为了这一行字，还要配上回复人的各种信息，以及签名，实在是很影响阅读体验。一页往往只能显示15-20个跟贴。
由于糟糕阅读的体验，导致了用户阅读的积极性不高，回复的积极性也不高。最后迫使发帖人选择“回复可见”这样的方式来强迫跟贴。陷入恶性循环。
而web2.0时代的设计，豆瓣、人人、开心，则是清一色的简洁式的，用户头像只显示48px的小尺寸版，除了用户名之外不显示任何用户信息，不显示签名。这样的好处显而易见，网页上只显示跟帖子内容有关的文字，其他统统隐藏。阅读体验很流畅，网页的容纳量也很大。豆瓣小组的一屏会显示100条回复。
我相信Comsenz内部一定有过关于简化帖子跟帖的讨论，否则UCenterHome的小组不会做成简洁式的回复。但是在这次论坛和小组的融合中，Discuz还是在排楼式和简洁式中选择了前者。
他们大概觉得，如果把帖子的跟贴大刀阔斧地改成简洁式的，个人站长们肯定要造反的。
于是他们选择了另一种妥协方案：在排楼式的帖子里加入点评功能。点评是简洁式的。很省空间。可是这其实是一个很表面的设计，它没有考虑到用户的阅读习惯和阅读顺序，以及用户的发言心理。
用户会发现在点评里发言得不到关注，说出去的话向一块扔到黑洞里的石头，听不到一点回声。因为点评不顶帖，显示的面积比排楼小很多，点评超过5条之后会隐藏，更要命的是，其他用户在浏览时，往往会快速滚动滚动球，拉到最下面看最新跟贴，根本不会注意中间会有一个“点评”。
如果你是用户，你想说话的时候会选择点评，还是跟贴？毫无疑问是跟帖，因为那样很醒目，会把帖子顶上去，得到更多关注。
事实上，跟贴和点评，其实都是讨论，实际情况是可能都没什么意义，为什么还要从显示效果上区分这两者呢？
插件机制依然非常不成熟
这两年来，我开始越来越多地使用wordpress建设各种CMS，越发体会到wordpress插件机制的好处。
虽然wordpress只是一个功能并不全面的博客程序，但是通过wordpress无处不在的插件机制，有数不清的开发者创造出了各种有想象力的插件，全方位地拓展了wordpress的功能。
现在每当我希望为wordpress程序增加什么功能，首先会去wordpress搜索相关插件，几乎每次都能找到满意的插件，省却了我大量二次开发的工作。同时，我至今仍然没有修改wordpress的一行代码。因为所有我的需求，都能通过插件，或者修改插件就能实现，不会污染wordpress核心代码。
而反过来看discuz，几乎每次discuz升级，都会是二次开发者的噩梦。因为他们总是被迫去修改discuz的核心代码。一旦discuz升级，那么这些二次开发代码就会被覆盖。这完全是因为discuz本身没有留下必要的插件接口，开发者才会被迫污染核心代码。
就算在Discuz当道，市场占有率超过75%的今天，Discuz插件依然少得可怜，不能不说是一个遗憾。
不知道戴总会不会看到我这个无名小卒的评论。或许上述判断有很多偏激之处，请海涵。
虽然我有各种质疑，但是我还是会把自己维护的论坛上升级到X，仍然感谢Comsenz给我们带来这么好的开源php建站程序。
Comsenz的7个短视之处
1.顽固坚持php4，迟迟不愿拥抱php5
其实这是我最不能理解的一点，Discuz现在的代码竟然还是以php4.3.0为最低标准的。
这种做法虽然说可以做到最大限度的兼容，php4的运行效率也确实比php5高不少。可是为了向下兼容，不得不牺牲很多高版本php的优秀特性。事实上，php5已经在各方面非常完善，面向对象方面的支持全面提升，PD0， 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一定能获得更大的成功。
来源：http://www.365x8.cn/?post=1264
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/3964/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
CURL传递Cookie的方法--本人未测试，From：Yongwang
通过C语言连接mysql的源码，书（买了）上抄并测试通过，不要转载评论列表
