封杀华硕宣告

兹因华硕陷害门事件（可于google上搜索 华硕 陷害门 黄静，不要使用百度），决定于今日起封杀华硕系列所有产品。不购买，不使用，不推荐，并向认识的人宣告此问题。特此声明。
P.S:虽然华硕不把我们当回事情，但是我们还是要把华硕当回事情，你想当下一个黄静么？

程序生产流程管理的一些想法

程序的生产管理本质上说应当可以纳入生产管理中，然而程序毕竟是一种特殊的产品，因此程序的生产管理也有其特殊性。下面贝壳从小到大阐述一下个人对生产管理的一些想法。当然，30人以上的团队规模贝壳根本没有碰到过，因此就不予置评。
首先我们从软件的生产流程开始论述，当然你可以没有流程，然而你不能没有过程。没有流程叫做不正规，低成本和高效率，没有过程……没有过程我也不知道你怎么做的，直觉？
管理的头一步是计划，软件生产的头一步是调研和需求分析，然后是紧密关联的系统构架，包括构架选择和结构设计。调研的典型情况是回答以下问题，软件为了谁而做(Who)，设计周期和维护周期是多长(When)，软件的适用范围(When)，软件的意义和核心价值(Why)，软件要达成什么目的 (What)，如何设计达成这些目的(How)。这些问题中，要达成的目的和如何达成是核心。而后通过详细的讨论，得出到底要做什么东西，具备什么功能，以及一些细节问题。这时期形成的是软件需求分析报告和软件需求说明书。需求说明书的尺度是一个很难把握的问题，一般来说，需要灵活对应市场反馈的软件，需求说明书不用过早细化，反之则可以早细化一些。开发人员多，结构复杂的系统，设计说明书必须详尽，反之则可以简单一点。不过如果忽视甚至无视需求说明书，或者将需求说明书仅仅作为一个官样手续的团队，必定会在后面吃大苦头。如果要规避需求说明书，也并非不可以。贝壳会在最后描述一个原型系统方法，来规避灵活和不确定的需求对需求说明书的挑战。然而注意，这只是需求说明书的形成手段，本质上是以程序员和最终用户的互动来清晰需求，同时潜在的让程序员熟悉需求。并非真的不用讨论和细化需求，更不是提倡做项目不出需求说明。
项目的构架选择是在基本明确需求后做的事情，这个阶段主要明确以下问题。是单机软件还是群体软件，C/S还是B/S，.net还是java还是 C，Windows还是Linux。中间是否使用ORM，使用的话怎么设计细粒度表，不使用的话怎么使用冗余设计。结构设计和构架选择互相分离又紧密结合，结构理论上是脱离构架的，然而某些结构就必须适用某些构架(例如如果用了事务明显就不能用mysql，性能会差死)，某些构架则要求你特殊设计结构。结构设计是系统一个非常广阔专业而复杂的问题，有兴趣的可以看系统结构和构架的一些书，还有设计模式和UML的，这里就不细说了。
在系统完成结构设计后，就开始系统的编码过程了。而项目时间确定，到这个时候才有依据。粗说是编码过程，其实又细分为构架实现，技术研发，编码，自测试，系统整合几个部分。结构设计完成后，抽象的结构必须经过严格定义才能进行使用，其中进行严格定义并且文档化的过程绝对不要轻率处理。如果是大型团队，应当指定一个人负责结构定义的维护，并指定几个技术骨干来讨论定义，讨论修改。这个人需要处理每一个对结构修改的请求，分辨是否应当修改结构，并且交给骨干团队讨论。讨论确定后，对定义进行修改，修改定义文档，并且通知所有部门进行修改。
当结构定义后，系统的框架模型已经清晰可见了，剩下的就是编码了。可是否能进行顺利编码呢？未必可行。因为实际上会在过程中碰到很多技术问题。例如需要使用以前没有接触过的框架和组件，需要对抽象数学模型提出可行算法等等。这些问题如果不先行解决，后面的编码无法顺利进行，技术骨干的最主要作用就在这里。在他们解决技术问题后(或者，更经常的，在中间提出的问题被他们解决后)，系统就进入了编码阶段。编码阶段的代码一般来说会有不同级别的自测试，从最简单的写个小程序到最复杂的单元测试+冒烟测试，按照项目的级别具体分析。不过即使是再小的项目再小的模块，一般写一点代码就写个小片断测试下是否可行是最基本的常识，除非你能保证所有程序不论大小一次写对。在完成自测试后，还需要整合入系统，并可能伴随冒烟测试。如果结构设计良好，这个阶段会非常顺利，甚至不出现什么大的问题。反之，如果结构散乱，不用到客户那里，在这步就会碰到非常大的阻力。
在完成主程序的编码和整合后，项目进入收尾阶段。一般是漫长的测试和后续工作，主要包括叠代测试，性能分析，编写使用手册和编码手册，编写项目的技术分析，系统分析报告和各种材料。在这个阶段最主要是要通过测试，先于客户找出错误，并且逐步修改掉。良好的测试结果应当是逐步收敛的，当你看到一个逐步发散或者不稳定，根本没有规律的测试修改结果时，你的麻烦就大了。这通常是因为没有构架，构架错误，中间有不适应构架的修改，构架变化，核心算法错误，需求浮动太大等根本问题所导致的。当然，在测试的同时还要进行全面的文档化过程。
在测试和交付后项目是否结束呢？恐怕还没有。下面是漫长的客户服务期，需要收集和分析客户反馈，进行持续改进。不过那就是后面的问题了。下面我们按照团队的大小来逐步讨论团队的分配和任务。
首先是从一人团队开始，当然，如果也能叫团队的话。作为一人团队，也就没有什么分工问题。文档化要以轻量为主，方便自己日后理解，除非是客户特别需求。
而后是典型的一个团队，一个PM带几个技术，可能还有外面的美工支援什么的。人数不超过五人，不分组。这里前期的需求/后期文档都要由PM完成，程序员主要注重编码和测试(尤其是单元测试)。如果时间充裕，建议一些专门编码一些专门测试，这样可以有效保证代码质量。互相的沟通以开会为主，信息的沟通要诀是让每个人都知道别人的事情，尽量多的向别人传递信息。
再下面是一个典型的“大”团队，两个PM带四个程序员四个测试，其中有两个以上技术骨干，再加上一个专职美工和专职的UI Design(或者两个美工，基本差不多)，8-16人的“大型”团队。说大型是因为这个团队开始内部就要分工协作了，加引号是因为……即使10个人，基本也就刚够分工的底线而已。
贝壳个人建议，除开美工等支持岗位，将这种团队分成三个部分。一个是PM组，负责和用户沟通协调，产生需求文档，盯项目进度，调度程序员，产生用户文档，产生其他材料。这组PM不要求高技术，对于技术建议会用，但不用精通(最好也别精通，业务骨干做PM是非常浪费的)。但是对于沟通技巧，协调能力和领导能力要求非常高，也要求有相当的文字功底。毕竟他们是要和客户沟通的人，要是鸡同鸭讲就麻烦了。和客户产生矛盾，文档写不好，更是麻烦中的大麻烦。由于协调要求非常高，因此PM组强烈建议至少两人，手机24小时开机！建议设立正副职，采取正职负责，副职挂钩的方式。
第二个团队是研发组(Dev)，至少一个技术骨干带队。这组需要负责编码，自测试，系统整合，出开发文档，出技术文档。对于他们要求是沟通能力过关，程序编码效率高。对于系统经验，思考方式的全面和独特没有特殊要求。一般经过培训的新程序员就可以在研发组中担任工作。他们年轻力壮精力旺盛，相对编码效率比较高。不过如果有条件，还是用比较有经验的程序员比较好。在系统的整合测试，返工引发的效率低下控制方面会有相当的好处。
第三个团队是测试组(Test)，至少一个技术骨干带队。这组要求负责系统的叠代测试和性能测试，可能还要帮助编写用户文档，进行项目实施，培训和售后支持。这组人的要求是工作勤奋(叠代测试的工作量是非常高的)，技术过关(否则无法发现一些问题)，系统经验丰富，思考问题全面而独特。因此强列建议由最强的技术骨干和一帮能吃苦的年轻人组成。一般来说测试组和研发组的人员比例在1:2到1:1之间。如果小于1:2，那么会发生测试不充分的情况。如果大于 1:1，只要成本允许，到是强烈支持。
最后一个团队(有人算了算……怎么还有)，是系统的管理组。负责项目的构架选择，结构设计，时间节点认定，人事事务，开发成本控制，技术研发。这个团队有非常高的技术能力，管理能力和执行权限，一般由主PM，研发组和测试组骨干，客户代表，公司代表(多数和主PM是一个人)组成。主要是要对项目过程的监控，项目中人员权限的分配，核心技术的研究和管理进行处理。这个团队等若公司和客户的联合代表，对项目负全部责任。
对于30人以下的团队，估计可以按照比例放大组规模来使用同样的组织结构。不过如果再大，同样结构就不合适了。这主要是因为同一个组中的信息是互相完全流通的，超过10人的组会造成非常高的沟通成本。这时候一般是分解系统结构，分解研发组和测试组。将一个大型系统分解为两个或者多个独立的部分，让每个组分别研发和测试。这样可以避免每组内的信息沟通成本过高，可对文档的严密性和规范性提出了更高要求。通常来说，拆分方法有按照功能和按照构架。即按照功能划分出一个一个的业务模块，每个组开发一个完整的业务模块。和按照构架层次分为数据库组，业务逻辑层组和客户层组。通常来说，我支持以业务为主的拆分方法。因为此时组已经够大，让一个组精通所有层次不难。但是让所有组全部完整了解需求可就很难了。
对于这种成规模的开发，注重的主要是两点，文档和测试。最高的要求(也是我认为最好的褒奖)是及时的文档和全面的测试。此时的难点在于，研发过程中程序员经常为了修补问题而修改代码，但是忘记修改程序文档。或者需求变更后PM改了需求说明，通知了Dev，但是忘记通知Test。又或者通知了Test，但是忘记修改用户手册。因为诸多文档其实是对同一内容的不同描述，所以相互具有关联性。其中之一变化经常导致其他文档落后陈旧，而且版本不统一。
测试应当贯穿正规研发过程。从程序员实现一个个功能起就应当开始叠代，直到项目完成后。并且bug的管理应当和需求管理合并，成为几个组沟通的核心。测试的时候一定要注意充分测试和叠代测试，不要象微软一样弄出新的补丁补出老Bug的状况。
下面贝壳讲以下系统原型法，其实这个就是业界常说的敏捷开发。系统原型方法是指以构建非常简单的系统，实现非常核心功能的原型系统为基础，逐步推导出正规系统的功能和需求的系统分析方法。主要适用于系统需求不清晰，分析困难，开发周期短，程序员数量适中的项目。如果上述条件不成立，那么建议不要使用原型方法。
原型法的头一步是分析需求，不用说不确定的，就说为了实现业务目的(至少这个应该知道吧？)需要哪些功能。然后实现一个可用的，不用很美观，不用性能优化的系统。有了这个系统后，客户可以逐步分析使用这个系统哪里不方便，而后交给程序员改进。逐步反复，直到客户满意为止。使用这个方法，客户和程序员间，程序员互相之间要保证充分沟通，文档可以容后再写(前期还不确定呢，怎么写？)。主要是注意逐个的需求管理和Bug管理，这正好和我上面说的合并管理对应。使用这个方法的好处是当不清楚需求的时候可以马上做，逐步清晰。过程比较直观，做出来东西比较实用，也节约时间。坏处就是会浪费一定的程序员人力，而且一个没控制好就一直改一直改不知道哪里是头了……
当前国内软件业企业的几个问题就是，不注重需求，不注重测试，不尊重专业，不尊重规范，不培养人才，不积累技术，不重视信誉，不打算做事。下面贝壳逐个细说。
不尊重需求，一般来说，老板讲的时候都是需求为重的，可当客户需要变的时候，老板很容易同意需求变更(虽然我可以理解，做生意也不容易)。不尊重测试，做程序的非常理解测试的重要性，然而老板却认为那个岗位可以随便找个人来做。实际上，测试是一个非常专业非常流程化非常严密的东西，测试的主管最好是公司里面最有经验的人。同时，还有不尊重专业的问题。并不是说老板干预程序员的决策，而是很多时候老板根本不了解技术骨干和PM，测试的区别。让技术骨干来做策划，或是负责、或者主导和客户沟通，这都是超级缺乏效率的做法。至于不尊重规范，事先划定的流程，在遇到重大问题的时候，往往就变成了废纸一张。到不是说在重大问题前非要坚持僵硬的步伐，可一个项目一半时间都是重大问题，这就过分了把？先说了项目过程中要推进知识积累，推进技术交流，推进这个推进那个，等项目一忙就全飞了。
同时由于程序员的超高流动率，当前中国的程序界有一个非常不良好的风气，公司基本不培养自己的程序员。都不知道公司是否能开到明年呢，培养了做什么呢？这点在大型公司就比较好，无论什么情况，基础的内部交流总是保证的。只要签长约，多数可以弄到一些培训。中小公司不培养人才一方面是没有必要，另外一方面就是没有能力。于是程序员就被迫自我培训，自学或者脱产参加培训。付出了成本，自然要赶快跳到能实现价值(能把钱赚回来)的公司里面去。中小公司为人员流动付出巨额成本，而且很多都根本无知觉。
举贝壳公司的例子吧。因为发展需要，今年年初公司曾大型招人，C#程序员，结果可用者寥寥无几，很多都是浮夸碰运气的。以至于一天面试十多个人，竟然一个备选都没有的情况经常发生。一个人过来投简历，硕士，要价10K多。不说公司能否负担，看了看做的题目，算法题还不错，C#技术，解决实际问题都一塌糊涂。这种人招进来差不多就是研究算法写Paper的主，要做程序还得培训一下。还有一个人，我前周刚刚送走，转眼又回来，估计是批量投简历的时候忘记筛公司了。还有一个项目经理真的是不错，讲起问题来很深入，经验丰富，可老板认为用不到，贝壳一点办法都没有。由于人员仓促到位，我们在开发后期付出惨烈代价！有一个程序员从到岗到离开公司，最大的贡献就是拖了三个多月的进度，因为他连static函数干吗用的都不知道。还有一些人，很适应岗位，可做不到多久就走了(当然，这是有各种原因的，试用和刚满期的人走是比较正常的事情)。问题是，其他人就要重新接手他的事情，等来了人再换手。这样的直接结果是什么呢？如果说项目拖延有一半是因为我们需求没做到位，另外一半就是团队的人才损失。如果在普通项目上碰到类似问题，来的人不能做事情，人员替换率高。那么本来能按时完成的任务就一定会延后，而且分析的时候很难直接表现出来，多数会被认为是工作效率不够高，工作态度不认真之类的(某种意义上也没错，毕竟不能做事的人，不是因为效率不高就是因为做事不认真)。不能留住人才造成的后果，是通过项目拖延表现出来的，使得公司往往失去了隐性可能的良好口碑。这种软性杀伤是非常致命的但是又是难以直接表现的。
如果说不注重人才，还怎么能积累技术呢？人是技术最主要的载体。尽管我们可以通过互相培训，技术交流，技术文档化来积累技术。但是如果没有老员工的指点，那么新员工是很难吸收企业的原有技术体系的。无法积累技术的直接表现有两个，一个是中国企业没有核心技术，另外一个就是掌握技术的人就卡了公司的脖子。可能有人会举出中国有多少专利多少成果。贝壳告诉你，按照贝壳做项目的经验，那个多数都是项目做好了用来表功的牌坊。很多技术都是公司不敢给个人，个人不敢给公司，因为浮动率太高。许多真正有价值的核心技术往往是因为缺乏大公司(或者缺乏人)作为后台，而无法正式的走向商业化运作，更无法走向系统化理论化。因此中国不但缺乏真正的核心技术(我指能解决问题，有实现难度的技术)，更缺乏(这点可以确认)系统化理论化的技术体系。而掌握公司核心技术的人往往就能卡公司的脖子，尤其是技术都掌握在一个人手中的时候。并非说程序员都有坏心或者什么的，而是程序员有很多和老板不一样的想法(例如要重视测试，要重视专业等等)。当程序员觉得他是对的时候，为了和老板争辩，往往会使出走人的杀手锏。固然，公司是对产品拥有产权的。可是掌握核心技术的人不在，没有人能继续改进，研发新的产品系列，这不是要公司的命么？这时候老板就处于弱势的一方。从某个事情来说程序员往往是对的，可是从企业发展来说却绝非好事。
最后两个问题则是中国软件业更深层次的问题，不重视信誉，不打算做事。整天就想着前辈一夜暴富的事情，或者谁谁风投成功吃喝不愁的事情。根本不打算花心思将事业做好，而是设法请客招待人拉风投，找人做假买点击量买排名，花钱黑掉对手的网站，盘剥底层员工，炒作一些无聊的事情增加知名度。某种意义上说，这个才是中国软件业最大的毒瘤。

一件最XXX的事

好像小时候老师经常出这样的题目，不过我每次都没得可写，总觉得那堆事情太假太做作。没想到，我这两天亲身经历了一件很囧的事情。
事情是这个样子的。贝壳前两天玩开心（好啦，我知道很无聊，不过发现一堆N久没有联系的同学，很好玩那），然后突然想到搜索高中同学。首先跳出来的是我们的于飞同学，据记载，不出我们所料，去日本了。然后是一位叫江宁的同学，哪位？贝壳怕自己忘记了某些曾经的同学，所以打算点进去看看她的好友里面是否有高中的朋友，然后发现——这是谁？
她的列表中有一位“阿达”，这位同志刚刚加我，并且和我一样，是赵一搏的朋友，换句话说，是初中和大学圈子里面的。是不是贝壳点错了？还是开心太强大了？
事实证明，都不是，是事情太巧合了。贝壳联系该同志本人后发现，所谓“阿达”，乃是丁之光同学，正宗的初中和大学同学。而江宁同学在牛栏山高中复读，是杨亮和大佟的同学。他们是同事，我发消息的时候正好在旁边，OMG。
够囧了吧？好戏还在后面呢——
贝壳一时高兴，问，那个秦伯韬你认得么？认得。段旭辉呢？认得。张雷？认得。王巍？认得。朱金辉？认得。许智翔？谁？
shit，怎么就是不认得贝壳，俺这么有名的说。
不过此同学认出了我一箩筐的高中同学，于是贝壳自己都混了。然后说——段是在上海念书么？不是。那上海念书的是谁？张雷。（到底谁在牛山混的久啊？）哦——我知道，大佟的男友吧——
刚刚说完——对面发出了一阵吓死人的叫声——
（贝壳）：说错了么？我记得是杨亮女朋友和我说的（不就是刘莹同学么）——
（江宁）：张雷很帅的——
（贝壳）：小声点，大佟也是你朋友——
（江宁）：呃——
（贝壳）：好像我记得一起看过他们，那次我去复旦玩，大佟和张雷都来的，朱金辉陪他四中的女友，没来——
然后对面发出一阵杀气——
（江宁）：说，朱在复旦有几个女友——
（贝壳）：啊，我又说错什么了？
（江宁）：我一个姐们，是朱前女友——
（贝壳）：（原来是上门讨债的，少说的好）哦，哦，可能我记错了——
（江宁）：OOXX..**（省略一堆话，具体可以自行想象），不过你是可能记错了，当时王巍的女朋友是四中的——
（贝壳）：。。。（乌鸦飞过）。。。——
天啊，贝壳不想活了——

分词算法的具体实践

说到分词算法，可能很多人都很陌生，然而说起百度，google，很多人却是耳熟能详。google，百度在搜索的时候，输入关键词后瞬间就可以得到结果，如果用通用数据库是无法做到的。实行这个加速的关键就是分词算法。例如"项羽是萝莉控"这句句子，我们一般搜索都是搜索项羽，或者萝莉控，萝莉。你见过有去搜"是萝"这个关键字的么？因此系统通过分词，将句子分解为"项羽/是/萝莉控"，去处单字常见词"是"(如果要索引"是"，可以想像有多少文章没有"是"的)，我们就得到了项羽和萝莉控两个词。再通过反向关联，建立项羽，萝莉控指向文章的连接，就可以完成瞬间的搜索了(具体原理不说了，只要有一定数据库基础的人都应当能想明白原理)。并且通过关联性，某种程度上也可以提供"是萝"的搜索(带"是"的词，带"萝"的词，相关度最高)。
那么，如何来计算分词呢？方法很多，大家可以在网络上搜索下，贝壳就不赘述了。贝壳现在要说的是这次贝壳主要试验的方向，基于词典的机械分词中的最大分词算法。
机械分词算法是当今的主流，关键原因在于速度问题。虽然正确的分词很有价值，然而如果速度太慢，一样没有什么用处。机械分词一般可以保证 98%-99.5%以上的正确率，同时提供极高的分词速度。而机械分词一般来说，都是基于词典的。主要有正向分词算法，逆向分词算法，最大匹配分词算法。其中最大匹配分词算法具备最高的灵活性，只要你能评价一个切分的优秀程度，算法能把所有可能算出来让你评价。然而大家可以想像，这个是非常耗费CPU的。贝壳在这个基础上，做了一个具体的实现和细化加速。并且有准备做为一个开源项目来长期运作(只要有人有意向接手合作)。
首先我们先说贝壳这个算法的评价原则。贝壳认为，评价原则应当有以下几点。同时也必须要说明，以下原则是无法正确评价所有情况的。不过以下原则在原则正确的基础上比较便于优化。一、无法分析的词最少(这是全局最大匹配的理论核心)。二、匹配出的原子最少(这是保证分词优秀性的指标)。三、匹配出原子的出现概率和最高(这是纯粹没有办法了从概率上提高匹配正确的可能)。
当我们分析一句话的时候，我们可以想像，这句话应当是正常的，可被理解的。换句话说，句子中应当都是有意义的词。那么，在匹配后无法理解的词是什么呢？一种是匹配错误，一种是新单词，一种是单字成词和无意义助词。单字成词的例子有上面的"是"，我们可以通过一个比较小的词典去除。那么，假定词典够大的情况下，无法理解和分析的词越少的组合越正确。而同样一句话，匹配出的原子越少，在搜索的时候效率越高。因此我们有规定了原子最少原则。至于最后一个，在无法分析词一致，原子个数一致的情况下，我们只能通过出现概率来猜测可能性。
然后，现在让我们分析一下分词的特点，并且做一定的优化。首先就从最著名的例子，"长春/市长/春节/致辞"开始。
>>>长春市长春节致辞
首先，匹配算法一定要先搜索到一个出现的词，有词才有匹配优化问题。没有词的话，你试试看分词"嗡嘛呢呗咪吽"。根本无法可分。因此首先我们要计算出一个出现的单词。贝壳是从正向开始计算的(主要是因为词典的加速方法是头索引的)。
>>>*长春*{市长春节致辞}
>>>*长春市*{长春节致辞}
好的，我们匹配到了两个，不过这就是全部可能么？不是，否则就变成了正向最大搜索。你可以看看"有意见分歧"。如果从头一个匹配到开始计算，无论如何都是"有意/见/分歧"，而事实是"有/意见/分歧"。因此我们还有一种可能，在头一个匹配到的位置，其实并不匹配。不匹配多长呢？最大长度不会超过最短的匹配词。为什么？我们来看下面一个例子。
>>>*长春*{市长春节致辞}
>>>*长/春/(这两个字不是词，而是两个无法理解的字){市长春节致辞}
很明显，后一种分法违背了我们的第一原则，无法分析的词最少。无论后面怎么计算，其最优结果是相同的。在后续结果相同的情况下，头一次匹配到词后，所有可能的跳空(搜索可能的不匹配)最大长度严格小于最短匹配词的长度。
那么是否所有跳空都要搜索呢？也不，我们可以继续剪枝。对于情况"有意见分歧"来说，这个路径是必须搜索的。但是对于我们的例子来说，是无需搜索的。为什么呢？我们看以下计算。
>>>*长/{春市长春节致辞}(下一个匹配是什么？总不会是春市吧，所以应当是"市长")
>>>*长/春/市长*{春节致辞}
>>>*长春*{市长春节致辞}
大家可以看到，其实这个路径是无需计算的。那什么情况下需要计算呢？
一旦跳空，其跳空后寻找到的下个词的位置必须严格小于最短词的词尾位置。否则就没有搜索价值。具体可以看以下示例。
XXXXXXXNNNNNNNNNNN(X是词，N是无关紧要的)
SSSSSSSXXNNNNNNNNN(S是跳空或者跳空后形成的无法理解字，X是词，在这种情况下，无论后面怎么评价，都不影响该匹配被剔除)
OK，我们回到例子，刚刚我们说了，有"长"的匹配。但是通过刚刚的剪枝，又被剪了出去。我们下面分别计算两个情况。
>>>市长春节致辞
>>>*市/{长春节致辞}
>>>*市长*{春节致辞}
>>>长春节致辞
好，我们先不计算下去了。通过上面的计算，我们发现，在计算过程中经常需要计算同一内容的结果。我们可以想一下，同样的分词，同样的算法，出现的应当是同样的结果。就是说，分词函数是状态无关的算法。通过分解一个单词，得到一个最优结果。那么，我们对于同样的数据，何必需要计算两次呢？贝壳上文中提到过记忆函数，这次就用上了。根据贝壳的试验结果，如果记忆全部词的分解结果，会造成大量的记忆-释放，而内容基本没有用到，造成效率下降。如果只记忆长词的分解结果，往往又会因为太长，大多数句子无法达到长度而根本没用。这中间有个平衡值，具体多少贝壳就不说了。我们可以按照上文的方法计算以下两个过程，得到结果。大家可以自行验证。
>>>春节致辞
>>>*春节*致辞*
>>>长春节致辞
>>>*长/春节*致辞*
>>>*长春*节/致辞*
结合上面的过程，我们推算得到结果。
>>>*长春*{市长春节致辞}
>>>*长春*市长*春节*致辞*
>>>*长春市*{长春节致辞}
>>>*长春市*长/春节*致辞*
>>>*长春市*长春*节/致辞*
按照上面的评价原则，我们得到了正确的结果。
大家可以看看其他例子，这里着重说一下"有意见分歧"。
>>>有意见分歧
>>>*有*意见*分歧*
>>>*有意*见/分歧*
注意，有是单字成词，见可不是。如果见单字成词，做看见讲，那这句话就彻底成歧义句了。可以理解为，有意的要看到(或者让其表现出)分歧。这一般是古文语法。由此也可以看出上述原则在理解古文的时候往往会出现问题。同时还要指出的是，在匹配"长春市长春药店"的时候，会出现以下结果。
>>>长春市长春药店
>>>*长春*市长*春药店*
>>>*长春市*长春*药店*
两者的无法理解词都没有，切分数一致，最后硬是因为春药店出现概率低而被筛掉。可见系统有的时候是依赖概率和人品在工作的。
经过上面的原则和算法，贝壳实现了一个python的分词程序，1000行代码，原型系统。90W条词情况下，在AMD MK36上(2G主频)分词效率66K/s上下，具体看分词的选项(例如顺序分词就比较节约资源，分词排除重复就比较慢，启用多线程后在单CPU 机器上更慢)，内存使用114M。使用C++写的核心词典后，90W条词的情况下分词速度80K/s，比python的核心词典快了20%，内存70M，节约内存40%。不过可惜，这个核心词典是公司产权，贝壳无权公布。并且贝壳做了一些工作，准备使用分词程序来生成分词词表。这个么贝壳就不准备讲了。前面讲的内容贝壳准备放到试验型站点 http://shell909090.3322.org/split_word/split_show/上面去，08年内有效。有兴趣联系我的可以发 mail给我，shell909090@gmail.com，欢迎大家试验并提出意见。

苏博婚礼回来暨python2.6发布

这次10.1算是个大日子，因为我们可爱的苏博终于和他美丽的新娘结婚了。据说两个人相识10年拍拖7年，找的高中班主任做证婚人。实在有点为难人家，到底说高中就好上了呢？还是高中没好上？不过总而言之，他们总算结婚了。具体苏博是怎么被我们蹂躏的，以及婚礼的起因经过什么的就不写了，毕竟我不是新闻记者。这次就写一些有趣的事情和感想。
首先是去震泽的车子，因为10.1的关系，并不怎么好去。不过坐在车上晃晃悠悠两个小时，看旁边的河跟路一起走，感觉还是很不错的。江南不愧是水乡，有条河就在我们的路旁跟了10多分钟，还有条船跟我们并排跑。震泽古镇也很灵的，宝塔街古香古色，保证没有现代元素，除了大头发现的几个公共厕所外。建议大家有空可以去看看，苏博的家乡。
而后是新郎和新娘的一个让我比较震撼的问题。婚礼上，主持人问新娘的大学同学，是否在校园里面经常看到新郎。人家说，一直以为苏於良是南大学生。我吓一跳，南大啊，我一直以为王苏瑾在上海念大学。由此我得到一个结论，远距离恋爱是否会失败，和双方爱对方的程度无关，而和双方把爱付诸行动的程度有关。其实不光远距离恋爱，婚姻也是一样。认识我的人都知道我的两个总结。夫妻双方性格相近或相反，价值观一致。今天看来还要加一条，愿意将爱付诸行动。
然后是婚礼前一天，阿丁同学打过来跟我哭诉她和她男友的情况。实话说，虽然被哭诉半天，但是我还是搞不清楚她和她男友的状态，总之是非常复杂一团浆糊。因为隐私关系，我不打算说她和她男友的具体状况。不过大致就是她很喜欢他男友，喜欢到没有自我没有尊严。他男友呢，则是有点——不知道怎么说。说有问题吧，说不出来，说没有问题吧，情况确实——不怎么好。而且她本人处理事情上也不是没有问题，我觉得这个应当叫孽缘吧。不过无论如何，我的建议是——分手。
然后我就建议阿丁同学到震泽来玩一天，反正黄禹同学正好没来。然后她跑来玩了一天，回去和我说了一句雷晕人的话。我彻底无语了——
无论如何，那是她的家事。
再后面就是苏州到上海的车，同样也不怎么好弄。我问今天又没有去上海的车，最好是动车。回答说有，动车。我说来两张票（帮人代买一张），售票员说，晚上11点半的哦～～
我彻底无语。
后面一个朋友则更悲惨。他问，今天到南京的车票还有么？没了。明天的呢？也没了。后天的呢？我们只发售今明两天的～～
最后我们坐大巴回来的。
最后的最后，说一下，python2.6发布了，虽然我不打算用。比以前在构架上有了不少进步，不过很多东西暂时没有这么快迁移过去。我打算等3.0出了后直接用3.0，反正程序是一样写的。