神奇的阅读体验——读 BBS 代码小记
发信人: jjgod (jjgod), 信区: BBSDev
标 题: [转载] 神奇的阅读体验——读 BBS 代码小记
发信站: 一塌糊涂 BBS (Tue Aug 5 15:38:04 2003), 本站(ytht.net)
神奇的阅读体验
——读 BBS 代码小记
BBS 上了很久，对其结构却不甚了解，觉得云山雾罩，让人莫测高深。这几天
想帮忙改改 BBS 的 Web 界面，下载了两份代码一看，先是大分特，然后不信，
反复比较研究，最后不由得出这个令人沮丧的结论：至少国内的 BBS，程序全
都写得非常的糟糕，非常。
我和别人讨论 BBS 的问题早不止一次，总是觉得 BBS 应该是上上个世纪的东
西，全然不该出现在现在，其中讨论的焦点是：Telnet 还是 Web？
其实支持 telnet 的根本无法提出什么实质上的理由，无非是：
1. 早就在用，用惯了；
2. 习惯了字符的模式；
3. Web 方式慢。
第一种情况不必理它，显然这种人只会越来越少，直至消亡。第二种情况其实
站不住脚， 因为 BBS 不像 mud，它其实是在字符模式下模仿图形界面，包括
光标移动、前进后退，完完全全是在做一个类图形界面。 而在 BBS 使用中，
我们还可以看出这样的趋向：以模仿图形界面模仿得像为荣。这有什么意思呢？
你在服务器端做的再像还是不如客户端自己实现来得方便啊。
Web 方式慢，其实是一个错觉，因为 BBS 往往都是挂在教育网内， 大家在教
育网里互相造访，甚至只是访问本校的服务器，自然速度快得很；而像公众网
上普遍的论坛，却没有给每个用户都提供这么好的网络条件，不信你搬张椅子
坐到某个服务器前边去灌水，保证速度快得嗖嗖的。
想一想吧：一个最多只能支持十六色、纯文本的东西的表现力怎能和支持真彩
色、可以显示图片、音乐、动画……的浏览器相比？哪怕做得再出色的客户端，
它的可扩展性又怎能和已经发展得如此成熟的浏览器相比？
如此糟糕的东西，出现在现在还有偌大市场，原因其实不难分析：
1. BBS 的用户多为在校学生， 大家面对灌水的欲望没有选择，只能来这样的
地方；
2. 历史原因。
我个人的看法是，BBS 到国内这么多年，只有两点改进是值得赞赏的：
1. 提供了使用 C 做 CGI 的 Web 界面；
2. 水木清华 BBS 开发了使用 PHP 为脚本的 Web 界面。
--
再谈代码，实际上代码的糟糕可以很容易找到一个原因，那就是始终没有一个
编程修养较高的开发者出现，那些牛逼烘烘的名字，诸如 KCN、lepton、zhch、
ylsdd、yuhuan...... 没有一个注意过代码的格式整洁，没有一个注意过输出
的内容规范，没有一个注意过写份详尽的文档......
以至于现在打开放有 ytht 或者 smth 代码的目录，唯见一堆堆的代码毫无组
织地横七竖八， README、Changelog、INSTALL 这样基本的文档长度为零或者
只有寥寥一两行。唯一可看的一点代码还是来自人家台湾的。
与之相反的，是他们的小肚鸡肠： 好像每个 BBS 都恨不得把自己的名字贴到
大街小巷，ytht 的代码到处都是 ytht，nju 的代码到处都是 nju、lily，sm
th 的代码到处都是 smth……难道你们连定义一个头文件，把 BBS_NAME 这个
常量放进去，用的时候每次都用这个常量这么简单的技巧都不会么？
令我万般佩服的是他们的勇气， 比如说连 ANSI 控制符里面的 ESC 他们都不
愿意定义一个，每次用到都是 \033[x;xxm，拜托，ansi.h 也不是谁的独创了，
你们从别的地方 copy 一个，不要每次都这么寒碜好不好？
很多东西，从简单的编程素养来说都应该明白，有些经常要改的内容应该放在
文本文件里，而不是直接写在代码中，有些经常要用到的常量应该定义在头文
件里，而不是每次写一遍……因为代码是需要灵活性的，是需要经常修改的，
都写在 C 程序里面，偌大一个 BBS，每改动一点小的地方都要重新编译一次，
这样的勇气，怎能不叫人佩服？！
连 PHP 这样的解释性脚本语言都知道要用模板引擎，然而我们的 BBS 开发者
愣是不知道要把输出和程序分开这点基本的道理，所有的 HTML 代码直接写在
C 程序里面，你们用的是 C 做 CGI 啊，是要编译的啊。
在 mud 开发中， 我们会为了一些细小的地方，哪怕是少了几个空格而细细调
试几十遍，可是我从未在 BBS 代码中见到这样的迹象。国内的 mud 开发群体，
我原以为这已经是一个够落后的群体了，没想到还有比我们更封闭、更落后、
更低层次、更缺乏修养、更冥顽不灵的！
在我初识 mud 的时候，对于那个领域，我可以找到令我非常 Envy 的代码，
非常敬佩的程序员，但在 BBS 这里，我找了很久，没找到。
--
结论是至少目前的 BBS 的代码水平都极差—— 没错，这有历史原因，我也乐
于相信现在的这些 BBS 是正在往好的方向发展， 可是实际的情形告诉我并非
如此，我看到的 BBS 正在快乐地生产一批又一批地垃圾代码，乐此不疲！
这篇文章写得激动了一些，看到的朋友不必介意，我谈的知识我的看法，如果
你觉得有足够的理由改变我的看法，望不吝赐教。
还是用 Knuth 的一句话来作结吧，大意如此：计算机的程序设计是一门艺术，
我有时想象我是在像写诗一样写程序，因为不仅今天有人要读它，明天有人要
读它，一个星期后有人要读它，一年后、十年后、百年后还有人要读它。
--
笨笨的笨笨次方
※ 来源:．一塌糊涂 BBS http://ytht.net[FROM: 211.66.100.83]
--
※ 来源:．一塌糊涂 BBS http://ytht.net[FROM: 211.66.100.83]
ylsdd 的回复
发信人: ylsdd (好好学习，天天向上), 信区: BBSDev
标 题: Re: 神奇的阅读体验——读 BBS 代码小记 zz (转载)
发信站: 一塌糊涂 BBS (Mon Aug 18 01:46:00 2003), 转信(ytht.net)
显然不能怪我, 呵呵, 我对我的代码效率还是又信心的; 通常来说, 一个有潜质的 BBS
维护 (假设对 C 有一般概念, 而未曾做过其它方面的长期开发) 从入手 BBS 到能从系
统的观点考虑代码, 需要将近 1 年的时间. 我们这里有若干新手在写代码, 然后他们
check in 代码到 CVS 上的时候, 另外的人会阅读他们的修改, 提出改进意见, 所以我
想一般这方面不会出大的效率问题的.
但是同时我对美工没概念, 也认为多数的基于 telnet 的 BBS 的系统维护没有太多美工
概念, 这种能力在 telnet 界面上并没有太多的要求, 基本上能将内容正确地显示出来
就差不多了. 但是 WWW 界面是个问题, WWW 界面变化能力很大, 所以更难驾驭.
(讲述)
BBS 在 fb2.7 前的古老时代, 那个时候代码没有什么效率, 没有什么规范, 甚至连对齐
都没有做. 要用眼睛找一个 '{' 对应的 '}' 基本上是自虐. 那时我们也比较土, 连
indent 都不知道用. 不过这没什么, 因为这个代码可以运行, 可以提供丰富的功能, 因
此它就有相当的用户群, 因此它就可以发展.
(议论)
有人抱怨实用主义. 我想, 实用主义是否应该抱怨, 要基于评价者的目标. 如果目标是
优美得可以作为艺术的代码, 可以作为散文诗来阅读的代码, 那尽情抱怨吧, 这个代码
真的一点都不优美, 完全应该扔给碎纸机来处理. 但是事实上, 我们上 BBS, 维护 BBS,
只是将 BBS 作为交流手段来使用, 我们不是来欣赏这个系统的代码. 这些系统维护改
代码的过程都是,
1, 有 bug? 找找, 怎么着不发生就行了
2, 想实现什么功能? 那就东改改西改改吧
基本上就是这么将就着, 其实多数小的或者中等的 BBS 根本就不关心代码是什么, 系统
跑起来就挺高兴的了. 我们维护一塌糊涂的开始时候, 基本上就是整天跟 bug 搏斗, 如
果哪天 bug 睡觉去了, 我们才再去琢磨一下改进点什么功能.
(讲述)
但是并不是对所有人都是这样, 事情也在变化. 上网的人多起来了, 水木太慢了, 于是
KCN 等就用 bbsd 代替了 bbsref, 并且对代码做了很多优化. 一塌糊涂的机器太差, 也
被逼迫地不断优化. 因为需要长期地维护, 这时我们感到代码的混乱造成的压力了. 实
在是混乱, 代码在细节上的基础不好, 我们改到具体函数时再重新整理一下就罢了. 但
是代码有很多的结构问题, 很难处理, 我们到现在都没有能解决. 老农制作的 fb2000
时个很好的东西, 集中了很多功能改进, 而且很方便新手安装, 这个一时间被使用得很
广泛, 如果能有持续的开发应该是很好. 但是, 跟具体系统的维护比起来, fb2000 的
开发因为没有具体的 BBS 做为基础, 使得它没有继续发展的动力. 用的人很多, 但是
这些散在用户并不会给代码改进以很多推进. 自从老农回到生活之后, fb2000 的开放
就终止了.
(议论)
从 fb2000 我们可以明显了解, 一个具体的开发如果不能得到具体的支持, 是无法进行
下去的. 很多人看问题的时候, 出发点只是 "我希望什么". 如果事实跟他希望的不符
合, 他就会觉得这是多么可耻. 但是事情的发展有它的前因后果, 有它的具体条件. 如
果任何其它人都没有条件来做所希望的事情, 这样的抱怨又有什么意义呢?
(讲述)
zhch 是个很能干的人, 做了很多事情, 做事情很快. 能有这样的闲人对 BBS 是件很
好的事情, 谁给他的钱? 让我们感谢一下吧. 在具体的 BBS 维护之外, zhch 做了另外
两件大事, 一个是重写 BBS 代码, 另一个是 nju www bbs.
他尝试用数据库来重写 BBS. 这是当时不断有人提出的意见, 认为用数据库写 BBS 更
有条理或者更有效率. 我是觉得这个意见比较错误, 效率肯定不行. 但是问题也不太
大, 慢就慢呗, 对小 BBS 是没有问题的. 那时 zhch 甚至造出来了一个模型系统, 可
以登录上去使用一下. 但是这些项目没有进行下来. 从这里可以看到, 即使我们有个很
能干的大闲人, 重写 BBS 也是很困难的.
(议论)
现在有人对重写代码津津乐道, 正象以前有人对 BBS + database 津津乐道一样. 可是
你哪里来那么多精力去重新实现那么多的功能? 即使你真地重新实现了所有的功能, 你
又有什么所得呢? 对 BBS 用户来说, 最多是陌生的感觉. 对你来说, 你不过是重新做
了一件别人做过的事情, 除了所谓良好的代码. 但是如果你并不是大师, 一般来说你的
代码也好不到哪里去. 如果你真的是大师的话, 或许代码会良好一些. 可是如果你真的
是大师, 为什么不去找一件更有意义的事情来创造一下呢?
(讲述)
zhch (迄今为止) 最伟大的作品是 nju www bbs. 之前的 www2bbs 提供了基本的功能,
可惜 (又是) 因为没有具体的开发动力, 所以很少见到改进. 但是 zhch 一下子搞了个
nju www 出来, 从此, 世界就不一样了. 那时我们很想改进 www, 因为我们觉得 www
界面太土. 但是精力有限, 那时 lepton 在昵称里写着 "进度 1%", 而且从来没有向
2% 前进过. 这个时候我们听到了雄鸡报晓, zhch 打算推出新的 www 代码了, 于是我们
忍, 并且忍到了!
(议论)
曾经有一个时候, 很多在争论到底是 "应该" 用 telnet 上 BBS 还是用 www 上 BBS.
那时用 www 上 BBS 的人刚刚开始增加, 而 www 给系统造成了不小的负担. 其实这个
问题比较无聊, 用户想用什么就发展什么呗, 总不能因为我们喜欢果汁就不让别人喝
咖啡. 我们喜欢果汁的滋味正如同别人喜欢咖啡的滋味. telnet 和 www 必定各有好处
才导致都有很多的用户. 你就是再怎么说某个不好, 人家不还是照样用?
(讲述和吹牛)
然后我们就基于 nju09 开始改进了, 开始我们着重安全和效率, 然后就着重它的展示
能力了. 非常地实用主义, 为了让优秀的版面更加热闹, 我们做了人气, 为了让好的
文章更容易被发现, 我们做了文章评价和导读. 一直有人奇怪为什么糊涂发展这么快,
为什么, 同学们. 算了, 我这里透露点秘笈吧.
BBS 是个交流的系统, 如果我们做的有利于交流, 那就会吸引更多的用户, 这是水到渠
成的事情. 我们的管理人员知道正确的开版方向, 正确的治站方针, 知道怎么控制三角
地的风格, 这些我都不说了. 我要说的是, 我们那时是小站, 边上有水木这个大站挤压,
有未明和紫霞争抢, 我们那么少的信息怎么争抢? 但是, 事实上, 我们并不是什么都没
有, 我们有很多有趣的内容, 但是散布在不同版面, 读者很难发现他们. 幸运的是我们
恰巧找到了方法, 可以自动的将这些内容收集起来, 一起展示在 www 界面上. 面对那么
多的新 www 用户, 一个干巴巴的分区列表和丰富的精彩话题和导读, 哪个更容易阅读
是显而易见的.
人们说一塌糊涂的维护强, 其实我们不过是用正确的方法满足了根本的需要而已.
(结束语)
A. 如果有人拿着高效的语言而写不出高效的程序, 你就不要期望他能用优美的工具写出
优美的代码.
B. 用正确的方法满足根本的需要, 而不是为了似乎漂亮的方法而忽视了需要.
C. \033 对于 BBS 维护就像 XXX 对于 mud 维护一样. 涉足一个自己不熟悉的领域时
轻易下结论就像斯大林讨论语言学的阶级性一样.
D. 不可否认, BBS 的 www 界面是需要改进. 但是满足需要是第一位的, 为了代码的
优美而长期忽视真正的需要是不明智的. 哦, 这其实就是 B 了, 呵呵. 不过界面
的优美华不是我们的长项.
【 在 jjgod (jjgod) 的大作中提到: 】
: 呵呵，可惜有人拿着高效率的语言也写不出高效率的程序，那就不知道
: 该怪谁了。
: 【 在 ylsdd 的大作中提到: 】
: ...................
--
2////
※ 来源:．一塌糊涂 BBS ytht.net．[FROM: 127.0.0.1]
※ 修改:．ylsdd 于 Aug 18 02:00:28 修改本文．[FROM: 127.0.0.1]
※ 修改:．ylsdd 于 Aug 18 02:32:17 修改本文．[FROM: 127.0.0.1]