对【煮江品茶】同志的反诉状--模仿百度查询示例

时　间:2011-11-09 05:24:12
作　者:dbaseIIIer   ID：22003  城市：深圳
摘　要:一个月有900多人看过的文章，不知到批判这篇文章又有多少人看？
正　文:

10月10日后，终于坐下来休息一下了！我终于看到煮江品茶同志对我的批判了！

“其实dbaseIIIer同志在枚举一串字符组合的可能性时，已经触到了解决问题的边缘，可惜的是dbaseIIIer同志以此作出了相反的结论。造成这一情况的原因，是dbaseIIIer同志过于相信了自己的判断，因而丧失了继续思考下去的机会。dbaseIIIer同志的错误告诉我们，凡事皆有可能。任何怪异的想法，都可能隐藏着孕育着新的发现。只要我们的视野不被经验所蒙蔽，就一定可以看到许多的可能。”

这就是编程员了！未经历过风浪，未做过百万条记录对十万个用户的互动。为了完成一个视觉效果，为了取悦客人，为了争取建功的表现，放弃了实施人员的困难，项目的可执行性，可重复性，这是编程员经常犯的错误！

这也是为什么Access没办法做大项目的原因。当然这是微软的策略，Access实在是太容易学会了！
但正式用Access的人
- 没多少人用它的存储过程；
- 没多少人用它来做SOA服务；
- 没多少人懂得用类模块来定义集体开发的共用模块。

这并不是Access编程人员的失败，而是微软的成功呢！

为什么大系统现在都要用Java, 并且用SSH架构？Spring-Struct-Hibernate 三个产品一起用才能成大事？太多的好处，我也一时三刻说不完！不过要用 ssh， 整个开发环境，实施环境都会比起Access来说，成本会是10倍以上的！所以笔者我也不一定要大家学会这个“好”东西的“坏”处。

今天我只是想说明煮江品茶代码“成功”背后的4宗罪，记得我们是在研究搜寻逻辑（search logrithm)。

1. 数据库压力。输入8个字，不管中文英文，都要在数据库查询 8 Factorial 那么多次，而且是x从几十个字的标题文本里面搜寻。1*2*3*4...*8 = 40320次 两个 * 号通配符的查询！

2. 错误朋友当然也想在40320次的查询里面做个精简化，所以他个人认为 如果 8个字里面 譬如 ABCDEFGH 配对到 CDEFGH 就不去找 CDE / DEF /EFGH 等里面的是否再可以配对，即使用家不知道这个缩短计算的回路对她是帮助还是伤害，我会认为编写搜寻就是要尽量的找适合的出来，为了提高效率而抹杀有关通配的可能性，这是做搜寻逻辑天大的错误！    ·在我向编程员反映问题时他居然说

“我化了半个多小时好不容易找到 i=i+(j-1) 和 Exit For 这两句来限制短词组出现，所以不同意这样修改，呵呵”

意思是我两分钟内看出的错误，是他花了半个多小时刻意做进去的，不舍得删去！

3. 错误朋友把拆字做好了，却又想偷懒了！就只加了一个 全AND 或 全OR 的功能上去。事实的搜寻逻辑内，数据列表的顺序应该是：

• 全配对上
• 一或多段配对上 又以 配对度排倒序， 2端4个字 会比 3段2个字 先列出（就这个都够玩几天的代码了！）

若果只是让用户选 全And / 全Or 的话，那拆词组的意义又何在？我们用搜寻器就是希望越输得多越会接近我们的目标的，全Or就会越来越多我不想看到的数据，全And就是我很清楚知道我要的内容是什么样子时才用得上。这两个选项对搜寻这就是形同虚设了！

4. 最关键的就是要知道什么水平的人来的要求。我并没有贬低这个程式的需求人，或这需求人的老板的意思，我们做项目的，绝对需要分析并判断，与需求者与及使用者沟通有关“成本”与“期望效果”的关系。

其实，提出这样的要求的人，只是懒惰，不想输入几个空格或者逗号而已，那老板真的要一个IT部门的普通编程员去做个搜寻器出来么？这肯定是沟通的错误。
编程员来到这里求教时，我们作为有经验者，有责任教导后辈，这是很高水平的程式，不该让用家提出这样成本那么重的要求；又或者是回复老板，看看有没有这个的工具可以下载来用的。确实是有这样的控件出售的。或者可以导入微软IIS里面的Indexing Server 来以IIS来实现搜寻的。

如果我们是做项目领导，带着几个项目实施员，或者需求分析师的话，遇到这样需求，我们就要考虑多少成本能不能给用户提供功能的细心考虑了。又或者跟用户沟通，到底不输入空格，让系统开发与及运行的成本带来多大上调。2-3人操作的程式，只有几千条记录的话，根本不会花这个成本去做搜寻器，上10万记录有几十个操作员的话，做的方法就绝对不是这个方式去做，而应该是正式建立字典库，或单独字典服务器的。

而用java+ssh框架建立的系统就不会犯下这种错误了。因为一般的编程员是不会让他写代码直接操控数据库的，全部都会以SOA的服务方式调用的，而那些服务都是经过多年经验的分析师设计，数据库专员负责编写的，搜寻器更是独立的一个小组去研发的。完全避免了编程员把系统拖垮的现象的。