Tinyfool的开发日记

Beta技术沙龙第十期《云端的Ruby on Rails》预告

2010-01-18T10:33:00.001+08:00

时间：2010年1月24日下午两点半

地点：奇遇花园咖啡馆(地图)
beta技术沙龙官方网站：http://club.blogbeta.com

Beta技术沙龙第十期的主题是云端的Ruby on Rails。我们请到了Adylitica (http://adylitica.com/abo) 的Alex和Marc讲他们使用Amazon's SimpleDB的使用经验和在Amazon EC2上scaling的经验，Joyent也会有工程师来讲基于Joyent的云计算解决方案。

内容：

1. Amazon的SimpleDB (Alex)

SimpleDB是Amazon提供的分布哈希数据库。Alex花了大半年的时间使用SimpleDB作为主要的数据存储机制，构建了一个NO-SQL的具高可用的网站。他将介绍在这个过程中，他的经验、体会以及挫折。最后他将介绍该产品的一些相关新特性。

2. 基于EC2的可自伸缩的Web应用(Marc)

对我们的Web应用做了一些计算和使用模式分析后，我们决定不去购买昂贵的大型服务器，我们决定去构建一个使用小服务器的平台，当负载上升的时候，我们往服务器池中加入新的服务器，当负载下降的时候，我们去掉他们。在这个过程中，我们了解了要构建这样的应用所需的特性，以及要应对的一些常见问题。

发布Tiny4Reader测试版(Mac版，其他平台用户请直接忽视)

2009-12-31T16:08:00.001+08:00

Tiny4Reader是一个非常简单的PDF阅读器，其实Mac上Preview就已经是一个非常完美的PDF阅读器了，那么我为什么非要费劲写一个呢。

原因是，我经常用Preview看一些英文电子书、论文、文档什么的。其间总有些单词不认识，需要用字典查看。Mac的字典很好用，而且可以直接在PreView中右键打开调服务，但是总还是有点不够方便，对我来说。另外，我想学点非哑巴英语，所以，我往往先去词典查一下词的意思，然后在Shell里面用say命令把这个词读出来。这个流程，我觉得对我学习英语很有好处，可是涉及到两个软件，操作起来太过麻烦了。

所以就有了Tiny4Reader，它基本上就是个类似Preview的PDF阅读器，唯一区别是，阅读的时候，如果选中了一个词，或者一段话，然后，你按键盘上的a，这样就会读出这个单词，然后打开词典帮你找这个单词的解释。

下载地址：http://tiny4.org/Tiny4Reader.zip

欢迎大家提出宝贵建议，接下来我会慢慢的把它做的更好用一点，以及加入自动查找网络词典（dict.cn），以及Google Translate等。

如何给Mysql命令行客户端里的命令添加别名（如何在Mysql内使用ls/ll）

2009-11-19T01:15:00.003+08:00

我有个非常不好的习惯，每次进入到Mysql命令行客户端的时候，都会下意识ll一下。这个毛病非常不好，因为这命令人家根本不支持，而且人家还等着你给个分号，你不给就继续等，真是烦人。其实Mysql也真是的，有些命令需要分号，有些不需要，烦人。

于是我今天在我的Twitter上面抱怨这一点：

每次进入mysql>提示符，我总是先ll一下，每次都是，我决心以后研究下mysql console的源代码，让ll=show databases;，如果use了数据库，就变成show tables;

很多人说他们也是，于是我就想干脆Hack一下Mysql，让他支持ll/ls吧。在Hack之前，我想搜索一下有没有正规方式给Mysql命令行命令加个别名（要是有这正规方法，自己不用，反而去改代码也太丢人了），于是我在Google搜索“mysql alias ls”，结果没找到正规方法，倒是没想到很快就找到了这篇文章《Making mysql a bit more shell-like》。

这篇文章告诉我，原来很早以前（文章发布于2004年）就有人这么想，而且这么做了；而且这么做非常的简单，只需要修改mysql.cc文件，加几行代码，然后重新编译安装就是了。

不过注意，这篇文章太老了，代码已经过时，在现在的mysql.cc下已经编译不过去了，不要直接用patch，看懂patch自己改还是很容易的。另外你还需要把buffer->set("SHOW DATABASES", 14);这类的地方改成buffer->append("SHOW DATABASES;");就可以了（注意databases后面的分号，有了这个ll和ls就不用加分号了，很爽啊）。

当然，如果你连自己编译和安装mysql都不会，你还是先学了那个，然后再来玩吧。

我加了ll/ls，这两个命令一个意思，在没有选择数据库的时候，作用就是SHOW DATABASES，选择数据库以后，做用就是SHOW TABLES。而一旦你选择了数据库，你就无法取消选择，最多只能选择其他的数据库，为了在这种状态下，可以SHOW DATABASES，我又加了一个命令ld，可以在任何情况下，SHOW DATABASES。

做了这些修改，重新编译安装以后，用起来感觉真好用，再也不用觉得上来就ll是个错误了，我真是觉得开源太好了，哈哈。

欢迎大家参加Beta沙龙第九期《推荐系统在大型网站中的应用和实做》

2009-11-17T09:12:00.004+08:00

时间：11月22日星期日下午2点半
地点：奇遇花园咖啡馆（http://storygarden.me/cafe/map）
主题：推荐系统在大型网站中的应用和实做
主讲：王洪涛（当当）付超群（前某网站音乐事业部）
简介：“豆瓣猜你喜欢什么”，亚马逊的书籍推荐等等都是网站中的推荐系统，推荐系统越来越成为一个网站不可或缺的部分。它可以帮助用户找到自己可能喜欢的东西，可以帮助网站提高销售收入。有人说推荐系统就是搜索引擎之后的Next big thing。beta沙龙本期请到了resys的两位成员王洪涛和付超群，两位都在大型网站上进行过推荐系统的实做，希望他们的经验，可以帮助我们了解什么是推荐系统，网站为什么需要推荐系统，以及如何构建一个推荐系统。

无需报名，无需费用，点单随意。

正式发布雪计算的keynote

2009-10-24T00:22:00.000+08:00

前些日子TL聚会的时候，我做了一个关于雪计算的演讲，那是雪计算这个概念第一次面向除了我以外的广大人类们。昨天在迎接老莫，许式伟等盛大大牛们的饭局上面，老莫问起，我才想起，我居然忘了发雪计算keynote出来。

不管别人怎么看，我是正经地在阐述一个概念，一个想法，而不是讽刺或者挖苦什么东西。那么，云计算尚方兴未艾，我为什么着急下雪呢？

因为云计算是大众可以享用的，但不是大众可以构建的，越好用的云，对架构，投资，技术的要求越高，越不是普通人可以轻易构建的。而雪计算不同，每个有一定底层网络和架构知识的技术人员都可以搭建起一个还算可以用的雪计算平台，这是雪的草根之处，也是我自知无缘投入大云构建事业之后，想到的还算有点挑战性的玩法。

更细节的，请阅读雪计算的keynote，暂时还没有可用的Demo和更细节的信息。

下载地址：
http://www.tinydust.net/keynotes/tinysnow.pdf

为什么我想买TextMate但是没买呢？

2009-09-17T14:04:00.003+08:00

下午01:30:42 yayv: TextMate有哪些功能是Editplus没有的呢？
下午01:31:05 tiny: 跟texamate比的话ed就算没什么功能的
下午01:31:10 tiny: 模板啊，自动完成啊
下午01:31:13 tiny: 这些都要体会
下午01:31:20 tiny: 你必须有mac才行
下午01:31:30 tiny: 然后你下个测试版用就知道了
下午01:32:09 yayv: 你这个回答..., 等于我没问...
下午01:32:36 tiny: 实际上是这样的
下午01:32:42 tiny: 你说功能就那么简单
下午01:32:51 tiny: 但是好用这个不是简单可以说清除的
下午01:32:54 yayv: 你连1-3个你喜欢的功能都说不出来，凭什么说他好呢，哪怕是都有的功能他做的更好
下午01:33:31 tiny: 呵呵
下午01:33:54 yayv: ..., 还是没得到结果...
下午01:34:08 tiny: 我用着觉得你，你不一定啊
下午01:34:37 yayv: 我不在乎是不是我能用上，我只在乎为什么其他人觉得他好用
下午01:35:12 tiny: 就是好用
下午01:35:18 tiny: 我给你个最简单的例子吧
下午01:35:24 yayv: 好
下午01:35:26 yayv: 就等这个呢
下午01:35:26 tiny: 代码完成，现在ide都可以做吧
下午01:35:31 yayv: 对
下午01:35:35 tiny: vc,vb什么样子你知道的
下午01:35:40 yayv: 对
下午01:35:41 tiny: delphi看着是一样的
下午01:35:47 yayv: autocomplete
下午01:35:53 tiny: 但是往往要编译一下h,pas之类的
下午01:35:57 tiny: 会慢一点
下午01:36:03 tiny: 功能%一样，对吧？
下午01:36:14 tiny: 100%
下午01:36:20 tiny: xcode也有代码完成
下午01:36:32 tiny: 但是不是按点以后出现
下午01:36:37 tiny: 因为他不是c++
下午01:36:52 tiny: 他是Objective-C，他的语法是[对象方法];
下午01:37:23 tiny: 他的完成是你写 pr，他就给你输出一个pr正常字体，int灰色
下午01:37:38 tiny: 你觉得对，你就按tab，这样print就出来了
下午01:38:09 yayv: 输入 fo, 有 for foreac 多种选择的时候呢？
下午01:38:39 tiny: 你觉得不对，你可以按esc，出现一个下拉框可以选择
下午01:38:50 tiny: 或者你可以完全不理会，直接继续输入
下午01:38:51 yayv: 哦
下午01:38:57 tiny: pri的时候多半就不会错了
下午01:39:07 tiny: 而且貌似带有上下文的学习，所以错误的几率很低
下午01:39:10 yayv: 类似emacs的补全括号的感觉
下午01:39:15 tiny: 我昨天看到人说这个不好
下午01:39:24 tiny: 那就是完全按照vc的思路去说的
下午01:39:31 yayv: 无所谓谁说不好，我只在乎谁觉得好
下午01:39:40 tiny: 我觉得很好，为什么呢，因为我现在已经完全不记得他的存在了
下午01:39:42 yayv: 任何功能，都会有一大堆的人说不好
下午01:39:54 tiny: 就是给你讲的时候，我要去操作一下，才能给你描述对
下午01:40:04 tiny: 不然该按什么我都记不住
下午01:40:17 tiny: 但是我写代码的时候，肯定不会打错
下午01:40:20 yayv: 恩，明白，就像VI的很多命令，习惯之后就想用筷子那么简单
下午01:40:28 tiny: 我把这个叫做自然
下午01:40:40 tiny: 如果你完全不知道这个东西，你不理会他，不用他的好处
下午01:40:47 tiny: 它也完全不会干扰你
下午01:40:58 tiny: 不像delphi，他比较突出
下午01:41:07 tiny: 因为慢，你会暂时不能响应
下午01:41:15 tiny: textmate就有点这个感觉
下午01:41:23 tiny: 你让我跟你说他哪里好用，很难说
下午01:41:28 yayv: delphi还好，还算快，JB 这类的贼慢
下午01:41:39 tiny: bcb更慢
下午01:41:44 tiny: 我主要用bcb多点
下午01:41:45 yayv: 明白，要的就是你上面这些描述

我用满了TextMate的试用期，感觉很不错，有一个PHP网站的全部代码都是在里面写的，虽然我对TextMate的整体了解还不够多，很多有用的特性都不知道，但是用这很顺手，这点很重要。功能有时候并不重要，尤其是大多数功能，都是所有竞争产品都具备的的时候，我们才回到的起点，好用，最重要的还是回到好用和顺手。

我们应该使用金钱可以买到的最好的工具，那么我为什么没买TextMate呢？我有个毛病花钱的事情总是说老婆不让，对不起老婆大人了。有些事情是请示过老婆大人的，人家斩钉截铁不让的，有些事情老婆大人没有指示，我只是说老婆大人不让，来避免我自己花钱太过大手大脚，这属于自我审查，不是老婆大人的问题。TextMate还是有点贵，等我Adsense这轮漫长的100美金（这轮都快1年多了吧）到帐了，我再买吧。

Joel Test：写好代码的12个步骤

2009-09-16T17:12:00.003+08:00

刚才看到了篇《The Joel Test: 12 Steps to Better Code》，感觉很靠谱，分享给大家：

The Joel Test

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

其中的第9条，狠狠的击中了我，Robin同志多次告诫我买一个Textmate（约$59），我就是舍不得买，怕被老婆骂：上个月信用卡账单，美元怎么那么多啊？。

按照第9条的逻辑，不考虑硬件因素的话（考虑硬件的话，我是很想买Mac Pro的，$3299，8核，那不是机器，那是真正的野兽啊），我唯一出钱购买的开发工具就是IDP（iPhone Developer Program）了。

Joe Test这12条标题简译如下：

是否使用源码控制软件？
是否可以一步构建一个build？
是否进行daily build？
是否有bug数据库？
是否在修改bug后，才开始写新代码？
是否及时更新了你的时间表？
是否有详细的设计规格说明书？
程序员是否有个安静的工作环境？
是否在使用金钱可以买到的最好的工具？
有没有测试人员？
面试的时候是否要求求职者写代码？
是否利用陌生人进行可用性测试（直译为走廊过客可行性测试）？

看完体会一下，自己或着自己的公司项目，是否满足这些条件呢？我有很多没做到的。然后最重要的是把原文读一遍，我不翻译原文是有原因的，因为，在中国，显然应该加上第13条：

13. 是否能看懂英文？

第一台计算机的荣誉应该归美国

2009-08-28T10:53:00.010+08:00

第一台计算机的荣誉应该归美国，但是，英国人老是不服气这一点，因为他们认为实际上第一台确实是他们发明的，是他们根据图灵的设想创造出来的（1），并在解密工作上起了非常大的作用。二战时期，德国的Enigma-machine ciphers埃尼格玛密码是波兰人初步破解（2），而在图灵的带领下，被英国人彻底破解的（3）。

但是，英国人自己害死了图灵，他们对自己发明的计算机严格保密，甚至在不需要破解密码后，销毁了图纸和机器，只有两台做为收藏之用。

而美国的第一台计算机ENIAC（4），刚开始当然也是为了军用（5），可是战后，美国人没有束之高阁，或者干脆学英国人销毁了事。后来的计算机应该是参考了它而发展出来的。从而也催生了，美国整个国家的信息化，以及现在整个世界的信息化。

所以，英国人活该。图灵当时就应该移民去美国，这样信息产业的面目也许完全不同。要知道图灵死的时候才42岁，对科学家这个职业来说，这简直就是青壮年，正是应该大展宏图的时候。

当然，这也是我认为每个中国人，我和你迟早应该移民美国的原因之一。

---

应该是指Tunny Machine，为了解决出现在埃尼格玛密码之后的Lorenz cipher洛伦茨码而设计的，据说是依据图灵机思想设计的，故可称为最早的计算机，但也有人说它不可编程，故而不是真正的计算机，待考。
波兰版本的Bomba，可以解决原始的埃尼格玛密码，但是对改进后的无能为力，但是对英国人的最终破解启发极大，所以图灵的机器名字也叫Bomb。
Turing–Welchman bombe，英国人造的，彻底解决了埃尼格玛密码。
按照美国法院的判决，第一台计算机是ABC，基于类似的原因，我对此不以为然。
ENIAC设计的目的是用来计算火炮的投弹曲线表，实际上的第一次使用是氢弹设计中的计算。

跟朋友聊敏捷（我对结对编程、单元测试、重构的看法）

2009-08-21T01:00:00.005+08:00

大晚上的有个朋友也没睡，在Gtalk上找我聊敏捷，一聊就聊了一个多小时，谁叫我是话唠呢？我对敏捷的了解并不深，也许说的有很多不对的，不过下面这些东西都是我的一些思考，所以，贴出来就是露怯，我也不刻意藏拙了。

11:42 PM 朋友: 老兄，怎么看到现在，说的很热闹的敏捷开发方法
像ThoughtWorks这种公司

11:43 PM Tinyfool: 我接触的不多，方法确实很好

11:44 PM 朋友: 所谓的敏捷开发，主要是为了解决软件开发哪些问题？

Tinyfool: 其实还是软件工程问题

就是几个点

多人怎么协作

程序的质量怎么保证

11:45 PM 软件项目怎么组织，怎么计划

应该就是这些老问题

11:47 PM 朋友: 恩，这些老问题，其实不只是软件开发，好像只要是多人协作的工作，都会遇到

敏捷方法，能解决哇

还是，在探索过程中

Tinyfool: 大多数问题都还是可以解决的

11:48 PM 朋友: 就是说，已经有了一些好的经验和模型？

Tinyfool: 只不过有的时候在于你实施的怎么样

或者说，很多中软件工程的方法不是解决不了问题，而是实施不下去

11:49 PM 你用C写程序，写错了，编译器就不给你编译

但是软件工程是个管理问题，人是不确定的动物

我对敏捷的认识大概是这样的

11:50 PM 朋友: 很有道理

Tinyfool: 传统的软件工程方法不是不好

但是往往很笨重

或者说问题的前提很笨重

比如，人月神话，里面的前提，是历史上最大的一个项目之一

11:51 PM system 360

但是现在的开发团队，往往都没有那么大

或者说，我觉得应该不要太大

敏捷可能说，方法轻量级一些

所以更加的灵活一些

11:53 PM 朋友: 学习：）

Tinyfool: 我对敏捷了解的也不多，叶公好龙一下而已

11:54 PM 某些方法我们在用

或者想用

更多只是了解了一下而已

朋友: 哦

从不用敏捷方法，到用，中间会遇到什么需要改变的吗？

或者比较难过渡的地方吗

11:55 PM Tinyfool: 相对来说敏捷应该算好实施的吧

11:56 PM 朋友: 这敏捷倒是个美妙的概念

Tinyfool: 恩，不过也有些问题

就是很多概念看着很简单

朋友: 实施了敏捷，但是还出了问题，也可以把责任推到人身上

哈哈

Tinyfool: 但是真正要做好，其实也不是那么简单的

呵呵

你这么说也可以

我给你举个最简单的例子

11:57 PM 敏捷有一个方法叫做结对编程

简单说起来，这个应该是最好实施的

朋友: 恩，倒是听说，我一直觉得这个东西很诡异

一个哥们在旁边看着，干啥啊

Tinyfool: 就是说两个人写一个程序，不是说以前那种你写一段，我写一段，各自坐在座位上面写

对，一个写一个看，就叫结对

11:58 PM 简单说起来，你会觉得这个太好实施了

但是其实不然

这个东西的好处其实很多

我先给你说说好处吧

1、可以增进沟通

11:59 PM 在公司里面，号称是做一个工作，大家都写一个程序，或者是都做一个网站

但是也经常完全没有沟通

相互之间，可能会做出来重复的工作，或者是做出相反的工作来

12:00 AM 结对呢，代码是一起写的，两个人思路可以比较紧密的联系起来

2、避免错误

12:01 AM 人的思维，容易出错，但是自己很难发现。比如，很多人说他把一个问题想明白了，你让他描述一遍，他立刻就会发现他的逻辑漏洞百出

但是他自己想的时候，就会觉得全都是想得通的。

12:02 AM 结对，就给了你一个机会，每一步思路写成代码，旁边有另外一个人用他的脑子去理解你的代码。就像是有人听你讲一遍你的逻辑一样。

这样，你也很容易发现你的逻辑漏洞

如果你发现不了，他可能会发现，因为两个人很难同时犯一样的错误，几率太小。

12:03 AM 3、可以带新人

等等

但是实施起来，却没有那么简单

比如，两个人怎么做，是不是双屏，有时候都是实施成功的关键

坐

12:04 AM 如果旁观者，没有办法快速清楚的看到，写代码的人的代码，那也没啥用处

朋友: 恩，我觉得还有意见不一致，到底听谁的啊

12:05 AM Tinyfool: 或者，就算客观条件，你都具备了。可以项目经理总是会觉得两个人浪费在一个代码上，是一种巨大的浪费。

虽然他知道，如果真的两人结对的话，往往可以会效率更高。但是他往往不敢放心的去这么做。

朋友: 恩，我也觉得，成本太高，经济危机下，肯定会咔嚓掉坐在边上的一个

Tinyfool: “恩，我觉得还有意见不一致，到底听谁的啊”这个好办，如果出现了不一致的意见反而是好处，呵呵

12:06 AM 这说明找到问题了

其实成本是低的

但是，从人的直觉上觉得成本是高的。

12:07 AM 你现在貌似多余的放了一个人在那里，但是这能大大减少低级错误，和逻辑错误，维护成本会低多了。

但是人们往往会根据直觉行事。

朋友: 这么说对

Tinyfool: 这也是另外一个敏捷方法

单元测试，很多团队没有办法实施的原因

单元测试，也有点反直觉

12:08 AM 传统的测试，是程序员写好程序以后，提交给质量控制的小组，测试人员写测试代码，或者人工测试

这个很符合直觉

但是其实弊端很多

测试人员是黑盒测试

12:09 AM 不知道实现方式，所以有很多典型的问题，从代码一望而知的问题

他们如果没有经验就完全猜不到

所以就是撞大运

这也是为什么有编程经验的人做测试，往往水平会比较高的原因

他知道程序员常见的一切错误

12:10 AM 比如边界问题，代码在最大最小值容易出错，输入0容易出错等等

还有管理方面的问题

我以前在金远见的时候，同宿舍的人是搞测试的

12:11 AM 他就告诉我，产品有一测二测三测，终测

测试组的老油条，经常在一测二测三测发现了小问题迅速报告

12:12 AM 发现了大问题就不说

朋友: 啊

Tinyfool: 等到终测的时候，再报告

因为，如果一测二测三测都没问题，测试组奖金就少

但是一测二测三测出现bug的奖金没有终测的高

12:13 AM 所以他们会留到终测，这样可以拿到超额的奖金

这对开发组来说就很被动

朋友: 。。。。。。。。。。。

Tinyfool: 最后终测有些大bug根本没时间好好改了

12:14 AM 只能延期，或者是简单的绕过去，看看能不能骗过测试组

朋友: 呵呵

Tinyfool: 单元测试代替不了传统测试

但是他是程序员做的

而且按照标准的流程，也就是测试驱动的原则

12:15 AM 你要先写单元测试

然后写程序

比如，你要写一个算法，实现100以内的数字×2这个功能

12:16 AM 你要先写一个测试样例，for循环1到100，然后×2，看看等不等于他们的2倍。

写完了这个测试样例，你才能去写实现。

写实现的时候，你要先写一个错误的实现

比如，不管输入什么，都返回0，或者-1

这样执行一下测试样例

得到失败的结果

12:17 AM 这才完成了第一部

然后，你才应该去写正确的实现

朋友: 恩，这个太繁琐了

Tinyfool: 写好了，执行一下测试样例，对了，你的代码才算写完了

对，确实太繁琐了

所以，以至于我是很认同这个原则的

但是我很少这么写

12:18 AM 但是这个东西非常有用

对保证质量作用极大

程序员写代码经常会写出来那种

你随便用两个数字测试一下，他是对的

12:19 AM 但是用另外几个数字测试就会错的代码

这种就很难自查出来

单元测试就是要杜绝这种问题

这是潜层次的

还有更深层次的问题

程序大了以后的问题

12:20 AM 这就涉及到了敏捷的思想的综合使用了

写程序之所以需要软件工程，其实差不多就是三件事情

我前面说了

协作怎么协作

质量怎么保证

怎么维护

维护是最大的问题

12:21 AM 经常是

维护，也不是像一般人想的，只有软件卖出去了才有维护的问题

很多软件要写几个月到几年

而你昨天写的代码，你今天就可能全忘光了

12:22 AM 所以，往往程序还没写完，维护问题就出现了

举个最简单的维护的例子

比如，你有一个算法是算工资的

朋友: 恩

Tinyfool: 很简单，就是日平均工资×21

12:23 AM 你就写 s = c * 21

这个多简单

但是你这个系统很复杂

到处都需要算工资

你就把这句话到处粘来粘去

代码中有几百个这句话

12:24 AM 有时候，你需要算工资减去保险

那么就有了 s1 = c*21 - w

好了

你觉得没什么大问题吧

现在出问题了

老板说了，我们以后按照22天算工作日

12:25 AM 我这里还是简化了问题，有公司按照每月实际工作日算工资的

你就需要在代码中，把所有的这种21都变成22

朋友: 恩，有道理

Tinyfool: 你不能用查找替换

因为别的算法里面也有21这个数字

12:26 AM 你替换了别的算法就错了

这个s = c * 21直接替换s = c * 22，也不行

因为你有s1 = c*21 - w形式的

还有空格多了少了

就没办法了

这就是我们程序员说的代码有坏味道

12:27 AM 想不坏很容易

你把算工资写成一个函数

function s(c){ return c*21;}

老板说了，21改成22

你不用查找替换，也不用改100处

你该函数里面就可以了

对吧

12:28 AM 朋友: 恩，是的

Tinyfool: 这其实就是最简单的抽象

我的原则是，代码重复超过两遍

就要函数化

因为它就有了重复100遍的趋势

12:29 AM 随着你的工程的变大，很可能就会100遍

就像人类说名字，第一遍是全名

第二遍再提这个人，就用代词了

这就是抽象了一下

12:30 AM 朋友: 这个比喻好啊

Tinyfool: 软件是活的

你一开始写s=c*21;没有坏味道

因为他只有一遍

到处都用味道立刻就坏了

所以，你要随着项目的增长不停地去改善你的代码

12:31 AM 这其实叫重构，也是敏捷方法之一

重构是很多人心向往之，但是不敢为之的事情

一方面是很多的项目经理，觉得你在浪费时间

因为抽构完的代码味道虽然好，但是功能没有任何的改变

12:32 AM 另外一个方面，是怕你把程序改错了

第二个方面最重要

因为按照先贤的统计

你修正一个bug，就会引入4个bug

也就是说改代码总是危险的

尤其是，代码有可能不是你写的

12:33 AM 或者说，虽然是你写的

但是你已经不是你了

你已经是几十天以后的你了

你都忘了，当时这个函数是做啥的

注意事项是什么

12:34 AM 还有，本来一个程序已经对了，经过了测试组的测试

然后你什么新功能都没出来，就去再测试一次

老板和项目经理都不会喜欢你的

这时候

12:35 AM 单元测试的好处来了

单元测试是重构可以进行的保障

真正的重构有两种保障

第一，是IDE和其他工具的机制保障

这个说起来有点深了

最早重构这本书的意义就在与此

12:36 AM 人人都有自发的重构的思想

那么干嘛要这么书呢？

这本书，把重构方法论化，提出了重构的一些具体方法

这些方法都是非常具有操作性的

这就提升到了理论的高度

12:37 AM 这样，很多现代IDE就集成了这些重构方法的功能

这样，你就不会手工去重构

朋友: 我得好好读读你说的东西，对明儿的访谈特有帮助，

Tinyfool: 举个最简单的例子，你有个函数名字起的不好

12:38 AM 你要改掉，最简单的就是查找替换

但是这里有个问题

如果字符串里面提到了函数的名字怎么办？

只是凑巧一致而已

这就错误的替换了

12:39 AM 而IDE的重构功能里面的函数改名，就可以保证只替换函数声明实现，以及函数被调用的地方

不会改掉凑巧一样的字符串或者是其他的东西

这是重构正确的第一个保障

第二个就是单元测试

因为有了单元测试

所以，你可以放心大胆的修改函数的实现细节

12:40 AM 只要你修改后的函数还可以通过单元测试就可以了

像现在著名的一些开源软件

常常有数万个单元测试

12:41 AM 可以保障，不管你修改代码中的任意部分，都可以确保，你修改过的代码和以前的代码功能一致

而对于这种大型软件

修改以后，人工去核对功能是否一直，简直就是不可能完成的任务

前些日子，我帮人做一个词典软件

有个小bug

查某些词的结果不对

12:42 AM 这就很难办了

不是全不对，某些词又对

所以，最后我的做法，就是把词表倒出来做了一个5万个词的单元测试

每个词都查一边比较和预期的结果到底对不对

12:43 AM 这样找出了100个不对的

这100个不对的，其实对应了5种不同的情况

当然我事先不知道

我就先看第一个不对的

跟踪程序

找到原因

修改，然后再跑单元测试

12:44 AM 这下只有60个不对的了

就这么我其实就找到了5种情况，就保证了程序的百分百正确

如果我不做一个单元测试出来

我很难找全这5种情况

12:45 AM 我修改了一个bug以后，也不知道是不是解决了所有的问题

你理解这个例子吧？

朋友: 恩，明白了

Tinyfool: 在单元测试思想出来之前，你遇到这种

问题

是很难彻底解决的

12:46 AM 单元测试可以帮助我们开发出来几乎可以说完全没有错误的程序

朋友: 哎，通过你这些例子，俺对敏捷是长进了一大块

Tinyfool: 只靠黑盒能找到我刚才那个错误中的两三个情况就不错了

12:47 AM 我的了解还是很肤浅的

Tinyfool: 哈哈，那倒是可以去看看

12:54 AM 朋友: 打扰你这么长时间，真不好意思啊

12:55 AM Tinyfool: 呵呵

别客气

我把你的名字隐去，然后发blog你不介意吧

呵呵

12:56 AM 朋友: 哈哈，这怎么会介意

我刚想说，你刚才的内容，真可以写一篇文章了

Tinyfool: 呵呵，我自己写就懒的写，跟人聊心态轻松点

朋友: 算是对敏捷的一个梳理

12:57 AM Tinyfool: 我的了解还是不够深入

朋友: 哈哈哈，那，以后，想写博客前记得找我

Tinyfool: 好像到现在为止还没看过一本全面的敏捷的书呢，呵呵

：）

后：
聊天是我最没有压力的写东西的方式，前些日子的TL聚会有人反应我一个人说了3/4的话，就是因为如此。如果是聊天，我就可以没有压力的海阔天空的说，一旦正正经经的写个文章，我就会花大量的时间去考据，查资料，以免露怯，所以我最近一两年写东西越来越少。结对编程是我最心向往之的敏捷方法，可惜一直没有好好的实践过，这反而我和霍炬倒是经常一起结对设计，呵呵。8月23日，即本周日，Beta沙龙的话题是我的合伙人霍炬来讲我们如何在应用中使用Snmp协议来进行服务监控的，欢迎大家参加。

瞻仰海峡对岸的牛人《追求神乎其技的程式設計之道》

2009-08-10T10:22:00.004+08:00

活在这个日新月异的世界是需要巨大勇气的，因为有太多牛人在侧，以前（小学、中学、大学）我的生活圈子小，见得牛人少，觉得自己就很不错了。但后来有了互联网，我脆弱的心灵就一次一次地被各色牛人冲击着。

最近几次，是从刘未鹏开始的，他组建了一个颇有气氛和深度的Google Group:TopLanguage，里面牛人无数。他自己当然是其中的佼佼者，他的Blog虽然更新不多，但是每篇都巨长具有深度，很多年以前，他大学还没毕业的时候，我看他的Blog就以为他是哪个深山归隐的老怪了。最近，他的一篇《我在南大的七年》，则彻底摧毁了我残存的一点点自信，为什么牛人都那么年轻那么帅啊。未鹏的学弟是我的好网友xuyou同学，这个家伙也是牛的一塌糊涂，Cool的一塌糊涂，现在正在美国读博。他跟风未鹏的作品《我的大学》则让我相信我活着就是糟蹋粮食（按照我的体重，我这方面还算是有特长的），我准备找个山清水秀，春暖花开的日子自绝与人民。

然而，就在这时，我看到了海峡对岸的牛人Vgod（现在在MIT读书去了已经）的文章：

我突然想通了，牛人到处都是（斯坦福啊，麻省啊，都是一院子的），我还是勇敢的活下去吧。假设我还有30年好活（已经活了30年，再开30年的缓冲区，效率应该还可以），至少有4年可以用来把大学没学好的有兴趣的东西学好，再多写点自己想写的程序，改变世界很难，但是取悦自己不应该成为一个难题。

就像Zooey Deschanel在《Yes Man》里面说的：The world is a playground. You know that when you are a kid, but somewhere along the way everyone forgets it.

[转载sir的经典老文]胡侃学习(理论)计算机

2009-07-29T10:11:00.002+08:00

原文地址：http://bbs.nju.edu.cn/vd306802/bbscon?board=Mathematics&file=M.1002484634.A&num=2412
发信人: sir (阿涩), 信区: Mathematics. 本篇人气: 4731
标题: 胡侃学习(理论)计算机(0)
发信站: 南京大学小百合站 (Mon Oct 8 03:57:41 2001), 站内信件

我也来冒充一回高手，谈谈学习计算机的一点个人体会。
由于我是做理论的，所以先着重谈谈理论。

记得当年大一，刚上本科的时候，每周六课时数学分析，六课时高等代数，天天作业不断(那时是六日工作制)。颇有些同学惊呼走错了门:咱们这到底念的是什么系？不错，你没走错门，这就是(当时的)南大计算机系。系里的传统是培养做学术研究，尤其是理论研究的人。而计算机的理论研究，说到底了就是数学，虽然也许是正统数学家眼里非主流的数学。

数学分析这个东东，咱们学计算机的人对它有很复杂的感情。爱它在于它是第一门，也是学分最多的一门数学课，又长期为考研课程--94以前可以选考数学分析与高等代数，以后则并轨到著名的所谓“工科数学一”。其重要性可见一斑。恨它则在于它好象难得有用到的机会，而且思维跟咱们平常做的这些离散/有限的工作截然不同。当年出现的怪现象是：计算机系学生的高中数学基础在全校数一数二(希望没有冒犯其它系的同学)，教学课时数也仅次于数学系，但学完之后的效果却几乎是倒数第一。其中原因何在，发人深思。

我个人的浅见是：计算机类的学生，对数学的要求固然跟数学系不同，跟物理类差别则更大。通常非数学专业的所谓“高等数学”，无非是把数学分析中较困难的理论部分删去，强调套用公式计算而已。而对计算机系来说，数学分析里用处最大的恰恰是被删去的理论部分。说得难听一点，对计算机系学生而言，追求算来算去的所谓“工科数学一”已经彻底地走进了魔道。记上一堆曲面积分的公式，难道就能算懂了数学分析？

中文的数学分析书，一般都认为以北大张筑生老师的“数学分析新讲”为最好。我个人认为南大数学系的“数学分析教程”也还不错，至少属于典型的南大风格，咱们看着亲切。随便学通哪一本都行。万一你的数学实在太好，这两本书都吃不饱，那就去看菲赫金哥尔茨的“微积分学教程”好了--但我认为没什么必要，毕竟你不想转到数学系去。

吉米多维奇的“数学分析习题集”也基本上是计算型的东东。如果你打算去考那个什么“工科数学一”，可以做一做。否则，不做也罢。

中国的所谓高等代数，就等于线性代数加上一点多项式理论。我以为这有好的一面，因为可以让学生较早感觉到代数是一种结构，而非一堆矩阵翻来覆去。当年我们用林成森，盛松柏两位老师编的“高等代数”，感觉相当舒服，我直到现在还保留着教材。此书相当全面地包含了关于多项式和线性代数的基本初等结果，同时还提供了一些有用的比较深的内容，如Sturm序列，Shermon-Morrison公式，广义逆矩阵等等。可以说，作为本科生如能吃透此书，就可以算高手。后来它得以在南大出版社出版，可惜好象并轨以后就没有再用了。

国内较好的高等代数教材还有清华计算机系用的那本，清华出版社出版，书店里多多，一看就知道。特点嘛，跟南大那本差不太多。

但以上两本书也不能说完美无缺。从抽象代数的观点来看，高等代数里的结果不过是代数系统性质的一些例子而已。莫宗坚先生的“代数学”里，对此进行了深刻的讨论。然而莫先生的书实在深得很，作为本科生恐怕难以接受，不妨等到自己以后成熟了一些再读。

概率论与数理统计这门课很重要，可惜少了些东西。

少了的东西是随机过程。到毕业还没有听说过Markov过程，此乃计算机系学生的耻辱。没有随机过程，你怎么分析网络和分布式系统？怎么设计随机化算法和协议？据说清华计算机系开有“随机数学”，早就是必修课。人家可是工科学校，作为自以为“理科计算机系”出身的人，我感到惭愧。

另外，离散概率对计算机系学生来说有特殊的重要性。现在，美国已经有些学校开设了单纯的“离散概率论”课程，干脆把连续概率删去，把离散概率讲深些。我们不一定要这么做，但应该更加强调离散概率是没有疑问的。

计算方法是最后一门由数学系给我们开的课。一般学生对这门课的重视程度有限，以为没什么用。其实，做图形图像可离不开它。而且，在很多科学工程中的应用计算，都以数值的为主。

这门课有两个极端的讲法：一个是古典的“数值分析”，完全讲数学原理和算法；另一个是现在日趋流行的“科学与工程计算”，干脆教学生用软件包编程。南大数学系的几位老师做了件大好事，把前者的一本极为经典的教材翻译出版了：德国Stoer的“数值分析引论”。如果你能学会此书中最浅显的三分之一，就算没有白上过计算方法这门课！而后一种讲法似乎国内还没有跟上潮流？不过，只要你有机会在自己的电脑上装个matlab之类，完全可以无师自通。

本系里，通常开一门离散数学，包括集合论，图论，和抽象代数，另外再单开一门数理逻辑。这样安排，主要由于南大的逻辑传统：系里很多老师都算莫先生的门人，就连孙先生都是逻辑专业出身(见孙先生自述)。

不过，这么多内容挤在离散数学一门课里，是否时间太紧了点？另外，计算机系学生不懂组合和
数论，也是巨大的缺陷。要做理论，不懂组合或者数论吃亏可就太大了。

从理想的状态来看，最好分开六门课：集合，逻辑,图论，组合，代数，数论。这个当然不现实，
因为没那么多课时。也许将来可以开三门课：集合与逻辑，图论与组合，代数与数论。

不管课怎么开，学生总一样要学。下面分别谈谈上面的三组内容。

古典集合论，北师大出过一本“基础集合论”不错。南大出版朱梧(木贾)老师的“集合论导引”也许观点更高些，但他的书形式化得太厉害，念起来吃力。

数理逻辑，莫先生的书自然是经典。然而我们也不得不承认，此书年代久远，光读它恐怕不够。尤其是命题/谓词演算本身有好多种不同的讲法，多看几家能大大开阔自己的视野。例如陆钟万老师的“面向计算机科学的数理逻辑”就不错。朱老师也著有“数理逻辑教程”一书，但也同样读起来费力些。

总的来说，学集合/逻辑起手不难，但越往后越感觉深不可测。建议有兴趣的同学读读朱老师的“数学基础引论”--此书有点时间简史的风格，讲到精彩处，所谓“天花乱坠，妙雨缤纷”，令人目不暇接。读完以后，你对这些数学/哲学中最根本的问题有了个大概了解，也知道了山有多高，海有多深。

学完以上各书之后，如果你还有精力兴趣进一步深究，那么可以试一下GTM系列中的"Introduction to Axiomatic Set Theory"和"A Course of Mathematical Logic"。这两本都有世界图书的引进版。你如果能搞定这两本，可以说在逻辑方面真正入了门，也就不用再浪费时间听我瞎侃了。：)

据说全中国最多只有三十个人懂图论(当年上课时陈道蓄老师转引张克民老师的话)。此言不虚。图论这东东，技巧性太强，几乎每题都有一个独特的方法，让人头痛。不过这也正是它魅力所在：只要你有创造性，它就能给你成就感。所以学图论没什么好说的，做题吧。

国内的图论书中，王树禾老师的“图论及其算法”非常成功。一方面，其内容在国内教材里算非常全面的。另一方面，其对算法的强调非常适合计算机系(本来就是科大计算机系教材)。有了这本书为主，再参考几本翻译的，如Bondy&Murty的“图论及其应用”，邮电出版社翻译的“图论和电路网络”等等，就马马虎虎，对本科生足够了。

再进一步，世界图书引进有GTM系列的"ModernGraph Theory"。此书确实经典！国内好象还有一家出版了个翻译版。不过，学到这个层次，还是读原版好。搞定这本书，也标志着图论入了门，呵呵。

组合感觉没有太适合的国产书。还是读Graham和Knuth等人合著的经典“具体数学”吧，有翻译版，西电出的。

抽象代数，国内经典为莫宗坚先生的“代数学”。此书是北大数学系教材，深得好评。然而对本科生来说，此书未免太深。可以先学习一些其它的教材，然后再回头来看“代数学”。国际上的经典可就多了，GTM系列里就有一大堆。推荐一本谈不上经典，但却最简单的，最容易学的：http://www.math.miami.edu/~ec/book/ 这本“Introduction to Linear and Abstract Algebra"非常通俗易懂，而且把抽象代数和线性代数结合起来，对初学者来说非常理想。不过请注意版权问题，不要违反法律噢。

数论方面，国内有经典而且以困难著称的”初等数论“(潘氏兄弟著，北大版)。再追溯一点，还有更加经典(可以算世界级)并且更加困难的”数论导引“(华罗庚先生的名著，科学版，九章书店重印)。把基础的几章搞定一个大概，对本科生来讲足够了。但这只是初等数论。本科毕业后要学计算数论，你必须看英文的书，如Bach的"Introduction to Algorithmic Number Theory"。

理论计算机的根本，在于算法。现在系里给本科生开设算法设计与分析，确实非常正确。环顾西方世界，大约没有一个三流以上计算机系不把算法作为必修的。

算法教材目前公认以Corman等著的"Introduction to Algorithms"为最优。对入门而言，这一本已经足够，不需要再参考其它书。南大曾翻译出版此书，中文名为”现代计算机常用数据结构与算法“。pie好象提供了网上课程的link，我也就不用废话。

最后说说形式语言与自动机。我们用过北邮的教材，应该说写的还清楚。但是，有一点要强调：形式语言和自动机的作用主要在作为计算模型，而不是用来做编译。事实上，编译前端已经是死领域，没有任何open problem。如果为了这个，我们完全没必要去学形式语言--用用yacc什么的就完了。北邮的那本，在深度上，在跟可计算性的联系上都有较大的局限，现代感也不足。所以建议有兴趣的同学去读英文书......不过英文书中好的也不多，而且国内似乎没引进这方面的教材。

入门以后，把形式语言与自动机中定义的模型，和数理逻辑中用递归函数定义的模型比较一番，可以说非常有趣。现在才知道，什么叫”宫室之美，百官之富“！

sir的另一篇经典老文：理论计算机科学漫谈

[转载sir的经典老文]理论计算机科学漫谈

2009-07-29T09:57:00.004+08:00

原文地址：http://bbs.nju.edu.cn/vd306802/bbscon?board=Mathematics&file=M.975553688.A&num=1793
发信人: sir (sir), 信区: Mathematics. 本篇人气: 7567
标题: 理论计算机科学漫谈(1)
发信站: 南大小百合 (Thu Nov 30 11:08:08 2000) , 转信

早就答应russel的，今天有点时间，把欠债还上。

计算机科学和数学的关系有点奇怪。二三十年以前，计算机科学基本上还是数学的一个分支。而现在，计算机科学拥有广泛的研究领域和众多的研究人员，在很多方面反过来推动数学发展，从某种意义上可以说是孩子长得比妈妈还高了。

但不管怎么样，这个孩子身上始终流着母亲的血液。这血液是the mathematical underpinning of computer science(计算机科学的数学基础)，-- 也就是理论计算机科学。

现代计算机科学和数学的另一个交叉是计算数学/数值分析/科学计算，传统上不包含在理论计算机科学以内。所以本文对计算数学全部予以忽略。

最常和理论计算机科学放在一起的一个词是什么？答：离散数学。这两者的关系是如此密切，以至于它们在不少场合下成为同义词。

传统上，数学是以分析为中心的。数学系的同学要学习三四个学期的数学分析，然后是复变，实变，泛函等等。实变和泛函被很多人认为是现代数学的入门。在物理，化学，工程上应用的，也以分析为主。

随着计算机科学的出现，一些以前不太受到重视的数学分支突然重要起来。人们发现，这些分支处理的数学对象与传统的分析有明显的区别：分析研究的对象是连续的，因而微分，积分成为基本的运算；而这些分支研究的对象是离散的，因而很少有机会进行此类的计算。人们从而称这些分支为“离散数学”。“离散数学”的名字越来越响亮，最后导致以分析为中心的传统数学分支被相对称为“连续数学”。

离散数学经过几十年发展，基本上稳定下来。一般认为，离散数学包含以下学科：

1) 集合论，数理逻辑与元数学。这是整个数学的基础，也是计算机科学的基础。

2) 图论，算法图论；组合数学，组合算法。计算机科学，尤其是理论计算机科学的核心是算法，而大量的算法建立在图和组合的基础上。

3) 抽象代数。代数是无所不在的，本来在数学中就非常重要。在计算机科学中，人们惊讶地发现代数竟然有如此之多的应用。

但是，理论计算机科学仅仅就是在数学的上面加上“离散”的帽子这么简单吗？一直到大约十几年前，终于有一位大师告诉我们：不是。

D.E.Knuth(他有多伟大，我想不用我废话了)在Stanford开设了一门全新的课程Concrete Mathematics。 Concrete这个词在这里有两层含义：

第一，针对abstract而言。Knuth认为，传统数学研究的对象过于抽象，导致对具体的问题关心不够。他抱怨说，在研究中他需要的数学往往并不存在，所以他只能自己去创造一些
数学。为了直接面向应用的需要，他要提倡“具体”的数学。

在这里我做一点简单的解释。例如在集合论中，数学家关心的都是最根本的问题--公理系统的各种性质之类。而一些具体集合的性质，各种常见集合，关系，映射都是什么样的，
数学家觉得并不重要。然而，在计算机科学中应用的，恰恰就是这些具体的东西。Knuth能够首先看到这一点，不愧为当世计算机第一人。

第二，Concrete是Continuous(连续)加上discrete(离散)。不管连续数学还是离散数学，都是有用的数学！

前面主要是从数学角度来看的。从计算机角度来看，理论计算机科学目前主要的研究领域包括：可计算性理论，算法设计与复杂性分析，密码学与信息安全，分布式计算理论，并
行计算理论，网络理论，生物信息计算，计算几何学，程序语言理论等等。这些领域互相交叉，而且新的课题在不断提出，所以很难理出一个头绪来。
下面随便举一些例子。

由于应用需求的推动，密码学现在成为研究的热点。密码学建立在数论(尤其是计算数论)，代数，信息论，概率论和随机过程的基础上，有时也用到图论和组合学等。

很多人以为密码学就是加密解密，而加密就是用一个函数把数据打乱。这就大错特错了。现代密码学至少包含以下层次的内容：

第一，密码学的基础。例如，分解一个大数真的很困难吗？能否有一般的工具证明协议正确？

第二，密码学的基本课题。例如，比以前更好的单向函数，签名协议等。

第三，密码学的高级问题。例如，零知识证明的长度，秘密分享的方法。

第四，密码学的新应用。例如，数字现金，叛徒追踪等。

在分布式系统中，也有很多重要的理论问题。

例如，进程之间的同步，互斥协议。一个经典的结果是：在通信信道不可靠时，没有确定型算法能实现进程间协同。所以，改进TCP三次握手几乎没有意义。

例如时序问题。常用的一种序是因果序，但因果序直到不久前才有一个理论上的结果......

例如，死锁没有实用的方法能完美地对付。

例如,......

sir的另外一篇经典老文：胡侃学习(理论)计算机

结对设计

2009-07-25T21:50:00.007+08:00

刚才乱翻infoq的老文章，翻到一篇《结对编程的经济价值论》，感觉有点意思。结对编程是我和霍炬同学最心向往之的一种XP方法，然而我们几乎没有结对编程过。

时间是一个大问题，公司就三个程序员，最多的时候也只有四个程序员，大家总是忙着不同的事情。往往不是你忙就是我忙。

座位也是个问题，我们的工位和会议桌似乎都不够方便，至少应该有比较大的桌子，比较大的双显示器等等。

所以，想起来最像结对编程的是，在我们遭遇重大技术问题时，我和霍炬做的结对排错和结对调优。

但是，我今天突然在想，其实我和霍炬曾经做了无数次的结对设计。从几年前，我们设计365kit的前后台，协议，机器人；到两年前，我们和韩磊喝酒的时候，设计出开创一个技术咨询公司的想法；到一年前，我们设计出银杏泰克这个搜索服务的公司；到现在，我们公司产品的每一个架构和细节。

我思路天马行空，霍炬则更加保守严密，我先肆无忌惮的讲出所有的想法，然后霍炬对每个想法一一challenge，我们讨论，然后霍炬记录下来。这是我们作为朋友和合作伙伴合作了几年一直以来的工作方法，我想这也是我们能一直作为好朋友和合作伙伴的方法。

附：如果你想进行靠谱的结对编程，请参考这篇文章《成功实施结对编程》，写的很全面，很有操作性。

beta技术沙龙第四期[iPhone开发入门]我的总结

2009-06-03T14:25:00.004+08:00

beta技术沙龙虽然一月才搞一期，但是转眼间也搞了有4期了。每次我都没有写过总结，这点总被火炬和余晟老师诟病。本来为了表示我的清白，我准备别人主讲的活动我不总结，自己主讲的活动就也不总结（看，我还是天才吧，给自己的懒惰找的借口多冠冕）。但是，算了，人总是偶尔要勤快一点的。

我和Robinlu在等待开始

这期活动搞iPhone OS开发入门，主要原因是在最近的一个多月来，很多朋友都在问我一些iPhone OS开发相关的技术问题，还有很多朋友询问我iPhone OS开发难度到底如何。很多人对这个越来越火的平台非常感兴趣，但是对iPhone OS开发到底是什么样子，却没有感性的认识；有些朋友虽然已经开始进行iPhone OS开发，但是总是被一些或大或小的问题弄的焦头烂额。在我开始进入iPhone OS开发领域近一年的这个时候，我觉得有必要给朋友们介绍一下，这到底是怎么一回事。

我的朋友Robinlu是比我技术高得多的高手，他的Blog就介绍过iPhone OS开发中内存管理需要注意的事项。

我们对iPhone OS开发都有兴趣和一些经验，所以合作了这次活动的演讲，我来负责前面简要的介绍这个平台，开发工具，开发流程等等。他来讲主要的设计模式，注意事项以及技术难点。

现场的气氛很好，朋友们没有因为我的迟到而生气，令我很感动，谢谢大家。Robinlu觉得我们两个人的演讲都稍微简单了一点，但是非常活跃的问答环节，解决了这一问题。在问答环节中，iPhone和gPhone的比较，对平台的看法，对跨平台的看法，对内存和性能的看法等等等等，很多有深度的问题，给我们的演讲做了最好的补充。可惜问答没有被记录和整理，不然就会是一篇非常好的FAQ了（这个争取在以后的活动中改善）。

所有说来没来的兄弟们，没来是你们的损失；所有本来就不知道这次活动的朋友们，呵呵，记得follow我们beta沙龙的官方推特@betasalon，活动的通知会发布在那里。

最后大家可以在这里在线查看我和Robinlu的keynotes。

顺便公布我翻译的4篇iPhone开发入门的文章，点击代码中国iPhone OS开发专区。

我的搜索历史就像我的作息时间表

2009-05-21T10:54:00.002+08:00

刚才打开Google搜索历史看了一眼，发现Hourly search activity（按小时统计的搜索行为）简直可以说就是我的作息时间表。建议以后Hourly search activity作为个人病例的一部分，几点起床，几点睡觉，几点吃饭，简直是一目了然。

beta技术沙龙第四期[iPhone开发入门]活动预告

2009-05-14T16:48:00.005+08:00

UPDATE:最新消息，人邮图灵的主编刘江老师资助本活动5本图灵出版的《iPhone开发基础教程》（这本书很经典），我们将在活动的结束的时候抽奖，每个参加活动的朋友都有机会。感谢图灵和刘江老师。

时间：5月24日14点30分开始
地点：奇遇花园咖啡馆（点击查看详细地址）

主题：iPhone开发入门 & iPhone开发中的内存管理和性能优化

主讲人：郝培强（银杏）、陆亦斌（iPhone应用程序iChm开发者,财帮子网站共同创始人）

简介：本次活动介绍iPhone开发的入门知识和开发工具简介，帮您从新手快速进入iPhone开发领域，我们也邀请了经验丰富的iPhone开发者分享他们的开发经验和思想，探讨关于内存管理和性能优化等高级话题。

参与人员：最大的前提是技术出身，第二个要求是写blog。积极参加现场沙龙聊天；如有可能对话题通过blog保持跟进关注。http://club.blogbeta.com/ 网上报名或直接现身沙龙，参与免费，点单另付。

关于沙龙：blogbeta技术沙龙由一群技术人员发起并参与，旨在以技术的视角看待社会、互联网和未来，以务实精神深化交流，促进创新。

[PHP]发布一个小代码“静态文件的Rss生成器”

2009-05-06T23:00:00.013+08:00

最近做了一些Web开发，对PHP的了解开始加深，才发现自己以前写的PHP程序确实可以用，但是PHP很多有用和有意思的特性，我却完全不了解。

正如去年看到大鱼儿写的《习惯成自然》，吓了我一跳，我也一直以为纯PHP文件以<?php开头以?>结尾是个好习惯，谁知道实际上好的习惯是文件结尾最好不要有?>。又比如以前我一直是一个用英文句号（.）的高手，多复杂的字符串都是用英文句号来拼接的，看到$xxx="this is a $test";的时候还会以为人家写错了呢。

所以，我在做Web开发之余，开始翻译PHP的手册，每翻一章都发现自己知道的东西更多了，很有意思。这当然是一件非常重复发明轮子的蠢事，但是翻译是我学习英文资料的最好办法，所以就翻吧。然后，当我想把我翻译的进度弄到我的微尘程序员网站首页时，遇到了点麻烦，我怎么把这些一直在变的静态文件的最新进度同步上去呢？所以就有了这个简单的代码，“静态文件的Rss生成器”。

代码的逻辑很简单，使用ls -t获得以更新时间顺序排列的文件名，然后用head取前几个文件。然后，获取文件的标题和时间，生成xml。整个操作在我的本地很快，不过在我的虚拟主机上很慢，所以，实际使用中，我定时一个小时生成一次静态的XML。

代码的文本格式版本，请点击这里。

也欢迎对翻译进度感兴趣的朋友们订阅以本代码生成PHP中文手册翻译进度的RSS。

To所有人

2009-04-01T11:05:00.002+08:00

今年的2月，毫无意外的我30岁了；3月3日我的女儿诞生了；前两天我对老婆说，我离40岁还有10年，应该还能做出点什么。

但是不管你做出了多么伟大的事情，没有happy ending，只要你还活者，人生就是无尽的旅程。面对你以为的伟大成就，人们只会微笑，拍下你的肩膀，鼓励你继续前行。何况你还什么都没有做出来呢，所以，继续前行吧…

Jeff Dean 在WSDM 2009上面的演讲 Keynote 和视频终于出来了

2009-03-16T13:22:00.005+08:00

从2月17日到昨天，将近一个月我终于等到了Jeff Dean的演讲Keynote和视频。昨天我一整天把整个英文版的Pdf翻译成了中文，放在了Google Doc给大家分享。

前面我翻译了Geeking with Greg写的Jeff Dean keynote at WSDM 2009，以及Michael Bendersky听该演讲的笔记，他们虽然写的都很好，但是原汁原味的Keynote显然有更多有价值的信息在里面。昨天一天我的翻译工作都是在非常愉快的心情下度过的，一种得道般的快乐始终伴随着我。以前对Google架构的猜测有些得到了证实，有些则证明是完全猜错了。比如我一直以为Google的索引是按照词来切分的，但是这次Jeff Dean的Keynote讲得很清楚，按文档和按词切分的利弊，以及Google为什么选择按照文档来切分。所以，每个关心Google核心技术的朋友，我建议你们好好看看这个 Keynote。

因为有人抱怨在我的blog内嵌入Keynote会造成google reader的窗口跳转，所以我把嵌入的Keynote取消了，请大家点击下面的地址：

中文版Keynote观看地址为：http://docs.google.com/Presentation?id=afdfdfhqkrd8_1098qht7ggj

英文版Keynote下载地址为：http://research.google.com/people/jeff/WSDM09-keynote.pdf

视频观看地址为：http://videolectures.net/wsdm09_dean_cblirs/

Google核心技术为：GFS / MapReduce / Bigtable ，再加上这个Keynote基本上就算齐了。

[SEO]如何解决重复内容问题-Google Yahoo MS的回答

2009-02-26T13:56:00.005+08:00

这里说的重复内容问题不是指的由非法转帖造成的重复内容，而是由于很多CMS设计不好，或者有些网站利用链接参数跟踪用户行为（我们的一个咨询客户这方面就很严重，造成的结果是收录率极低，搜索量自然也极低），造成的在同一个网站同一个内容有多个链接的问题。

这种问题长期得不到重视，因为网站主和技术人员往往意识不到这对他们会带来什么样的恶果。简单的说：

搜索引擎不知道哪一个是权威的页面，所以可能会把你不希望的页面给用户展现出来。或者在同一个关键字下，你自己的网站的不同页面竞争排名。
用户看到搜索结果的时候会看到省略重复内容的提示，影响网站的形象。
搜索引擎对权威页面判断的准确性并不高，很有可能以为两个重复的页面是不重复的，甚至因为你的重复页面问题过于严重，反而把没有重复的页面判定为重复。

最好的解决办法就是规范地生成地址。如果CMS很难修改，或者确实有必要给同样的内容不同的地址的时候，那么最好是用Http持久301转向把不权威的地址转到权威的地址。

但是如果你的虚拟主机功能有限，或者你在你的服务器上权限有限，你很可能无法使用Http持久301转向功能。所以现在Google，Yahoo，微软三家联合推出来了权威链接属性Canonical，你只需要在页面加一个link标记，然后设定它的Canonical属性，上面三家搜索引擎就会知道你所指定的权威页面是什么。

Matt Cutts，Google的著名Blogger，为了Canonical属性，做了一个演示文稿，我翻译了送给大家，如下：

据说有些人的Google reader在看这篇Blog的时候会自动跳转，所以我取消了直接嵌入的演示文稿，要看请点击下面的链接：
http://docs.google.com/Presentation?id=afdfdfhqkrd8_108hp3vctf8

Google大牛Jeff Dean在WSDM（ACM的Web搜索和数据挖掘研讨会）2009上面的演讲

2009-02-19T11:18:00.020+08:00

重要更新：Jeff Dean的Keynote文件和视频已经发布，请移步查看

昨天看到好像是大辉共享的， Geeking with Greg写的Jeff Dean keynote at WSDM 2009。现在Jeff Dean的Keynote文件和视频貌似都还没公开放出来，所以我把Geeking with Greg的文章翻译如下，方便有兴趣的同学了解一下。Jeff Dean是何许人也呢？呵呵，他就是Google Mapreduce架构的发明者，那篇尽人皆知论文的第一作者。WSDM又是何物呢？WSDM是美国计算机协会ACM组织的Web搜索和数据挖掘研讨会。Jeff Dean在WSDM2009上面演讲的题目是Challenges in Building Large-Scale Information Retrieval Systems（构建大规模信息检索系统中的挑战），演讲介绍了Google从1999年到2009年，数据量，用户查询次数，以及相应架构的变化。

下面是简要译文：

Google Fellow Jeff Dean在最近的WEDM 2009会议上做了一个非常精彩的演讲，包含了一些我从来没有听说过的关于Google的轶闻。给我最深印象的是，这十年间Google对性能细节的关注，以及他们敏捷的开发模式。

Jeff给出了从1999年到2009年Google如何成长的几个例子。他们现在拥有1千倍的查询次数。他们现在拥有1千倍的处理能力（机器数量乘以他们的速度）。而且他们把更新的延迟降低了1万倍，送过去需要数月才能监测到一个Web页面的变化，到现在几分钟即可更新页面的搜索结果。

最后这一点非常令人印象深刻。Google现在可以非常迅速地监测到很多Web页面的变化，计算这个页面的近似静态排名，并把索引的更新发布出去。对许多页面来说，搜索结果可以在页面变化数分钟后更新。要做到这点需要解决几个困难的问题--重复抓取的频率和重要度，PageRank的快速近似计算，一个允许快速更新索引的架构--看来这些问题他们都解决了。

他们的性能改进也令人惊讶，现在显示每个页面的时间是200ms以下。Jeff提到从几年前起，现在绝大多数的索引是完全保存在内存中的。也就是说现在每个查询不是由几十个机器，而是由上千个机器处理的，Jeff说这是值得的，这令每个搜索者可以立即就看到搜索结果。

Google对细节的注意是可圈可点的。Jeff描述了他们这些年创造和使用过的几种索引压缩技术。他讲到他们如何最后决定了一种格式，4×3的位置信息有序地组合在一起（By Tiny:原文是a format that grouped four delta of positions together in order，这句我不确定翻译的准确性，因为我没有看明白），这样就可以把压缩过程中需要的移位操作次数降到最低。Jeff说道，他们总是很注意他们的数据在磁盘上的组织方式，把他们需要快速流读取的数据总是放置在硬盘的外圈，而冷门数据，或者短读取的数据放在磁盘的内圈。他们为没有校验的内存写自己的错误恢复软件。他们写了自己的硬盘规划器。他们不断地修改Linux内核去满足他们的需求。我们先是设计自己的没有外壳的服务器，然后切换到现成的标准的服务器，现在他们又转向设计自己的没有外壳的定制服务器了。

Google的敏捷同样令人难忘。Jeff说10年间，他们已经进行过7次主要的架构升级。这些变化通常牵扯到完全不同的索引格式，或者全新的存储系统例如GFS和BigTable。在一些切换中，他们甚至做到了，在新的数据中心运行着新的代码，旧的数据中心运行这旧的代码，并在这些数据中心间切换用户的访问。每天，搜索用户持续地接受用户体现方面细微的变化，测试新的代码。Google的切换安静而快速，用户不会注意到任何变化。

原始的计算能力的地位已经摇摇欲坠了--现在可以用数千个机器为一个请求服务--虽然这一切看起来那么不可思议。Jeff说，Google机器翻译模型翻译一个句子的时候，会对一个数T的模型进行上百万词的查找。他接着说，Google的目标是不管你使用什么语言，让你可以读懂任何语言描述的任何信息。这需要的运算量难以计算，看起来这么巨大的运算量可能令所有其他人都只能战战兢兢的呼喊Google（Tiny:原文The amount of processing required is difficult to fathom, yet it seems the kind of computational mountain that might cause others to falter calls out to Googlers.，说不好这句）。

------云时代的分割线------

Geeking with Greg还提到了，Michael Bendersky听该演讲的笔记，下面也大略翻译如下：

1999年到 - 2009年规模的变化

100倍文档数
10000倍查询数（这里Geeking with Greg和Michael Bendersky的数据有出入）
更新速度快了1万倍
查询延迟从小于1秒到大于0.2秒，快了5倍

10倍增长的时候设计的搜索引擎，100倍增长时重新了系统。然后，他粗略描述了从90年代后期开始抓取和索引发生的变化。下面是一些要点。

90年代后期

批量抓取系统，抓到“足够”的页面后停止。
批量索引和Unix工具协同工作。减少了机器失效和数据不一致性。
原始的97索引格式就是简单的字节对齐的系统，包含编码的字段和词频信息。这需要大量的磁盘访问。

之后不久

迁移到新的基于块的变长索引格式，附带高频词跳表。这令索引尺寸小了30%，而且解码更快。
加入结果和文档摘要的缓存服务器。
2001年前期，他们迁移到一个内存索引架构，索引服务器（）可以直接和前端服务器沟通。
索引按文档分割而不是按词分割。

{资料} 顶级期刊《Machine Learning》 1986-2007 全部论文的合集

2008-12-29T20:50:00.004+08:00

今天，pongba发现了这个非常好的资料，并在他的论坛共享出来。
地址是：
http://gigapedia.org/items/62699/machine-learning--1986---2007--collection-of-journals--springer-

不过这个下载地址有点麻烦，需要你注册gigapedia.org才能看到下载链接，然后还要去ifile-it网站才能开始真正的下载。所以，我下载了一份，在电驴共享出来，欢迎大家使用电驴来下载。

地址是：
ed2k://|file|Machine%20Learning,1986-2007.zip|512062790|3E9F4EEF83BD6996FA2CE1A9BC026B2B|/

欢迎下载也欢迎一起做源，现在下载速度很一般，不过只要做源的人多很快就会快起来的。

Google、微软还是好耶的黑色幽默？

2008-04-26T02:16:00.005+08:00

刚才要下载Mac版本的Mysql，所以去Google搜索Mysql，不过突然搜索结果右边的广告吸引了我。微软买了Mysql这个关键字，还要在广告里跟IBM的数据产品叫板多好玩啊。

可是，我点了之后，居然只看到一条错误信息：
Database not found!totaldb=0 dbname[1]=

我靠，难道是跟IBM比谁更幽默么？那估计微软要赢了。仔细一看地址是
http://mccannafa7.allyes.cn/main/adfclick?db=mccannafa7&bid=12680,6073,50&cid=6371,289,1&sid=12210&show=ignore&url=http://www.microsoft.com/china/sql/prodinfo/compare/default.mspx

原来问题出在好耶身上，微软的地址 http://www.microsoft.com/china/sql/prodinfo/compare/default.mspx 其实可以访问。

只是在宣传数据库的广告上，广告系统的数据库崩溃了，总让我觉得很有点黑色幽默。这更说明了数据库的重要性，不过好耶的数据库用的是谁家的，我还真是不太清楚，哈哈。

technorati tags: google, 好耶, 微软

DreamHost值得推荐吗？我看不值得！

2008-03-15T21:11:00.005+08:00

之前有不少Blog用了DreamHost，还做了推荐，我的Blog一直在国外，所以也就没有凑热闹。

所以，头些日子听说DreamHost摆了一个大乌龙的时候，我自然可以幸灾乐祸一番。上次的乌龙不清楚的朋友，可以看看这篇文章《DreamHost 大乌龙事件及众生相》。大概过程就是DreamHost的联合创始人乔希·琼斯在对2007年欠费用户催缴时，写错了程序的参数，把2007写成了2008，这样本来不需要付款的无数用户就自动被扣了11个月的租用费，这是个 7,500,000 美元，甚至引发了些用户对网络服务自动扣款是否安全的讨论。

这当然是无心之失，虽然对很多客户损失重大（可能会造成一些客户信用卡透支），但是我认为还是可以原谅的，因为总归不是故意的，成熟商业社会里，只要生意还做得下去，估计没人会白痴到故意提前扣款，那么多用户，与其提前扣款赚一笔跑路，自然不如老老实实的服务客户，争取让客户多享受几年服务。

问题是这样的，头两天有个朋友告诉我他的blog被Google清出索引有些日子了，他怀疑是Google认为他的链接太多了。

我看了看链接其实不算多，而且也没有任何明显的作弊的迹象，这位哥们人品虽然谈不上值得称道，但是多半也是不会作弊的。

那么帮他申请个Google Sitemap，看看他的网站到底出了什么问题吧。谁知道，一确认，才发现GoogleBot报警说，无法访问他的网站，错误号是403。

网站访问毫无问题，那么看来这个403是专门针对GoogleBot的，你不让人家抓你，人家凭什么索引你呢，呵呵。

问问哥们，他说自己没做过任何的设置，那么多半就是空间服务商干的了。哥们说，他在用DreamHost，在Google一搜“dreamhost 403 googlebot”，马上就找到了两篇文章《Errors with .htaccess : Site Down with 403 Forbidden Errors》和《Is Dreamhost support stupid or am i missing something?》。

一看才知道，果然是DreamHost干的，他们刻意在一些客户的根目录的.htaccess文件中加入

<limit>
order allow,deny
deny from 66.249
</limit>

服务器有过多的GoogleBot访问造成压力，临时做些解决方案，暂时封锁GoogleBot倒是不稀奇的。但是，一来，做这个操作完全不通知客户，太不负责任；二来，我那哥们的blog已经很久不能被Google访问了，看来DreamHost的如意算盘是如果客户不知道，就这么一辈子节省流量，反正客户发现Google不收录，多半以为自己有什么操作过分了，或者直接以为Google抽风了。

So，DreamHost的行为是故意的，而且完全不考虑客户的利益和感受，十分卑鄙，值得鄙视，不值得推荐。另外，DreamHost中国人用得极多，容易被GFW，也不值得被推荐。

technorati tags: DreamHost, google, htaccess

程序员的成长从开窍开始系列一、如何摆脱低级错误的困扰

2007-12-28T01:40:00.001+08:00

原文：程序员的成长从开窍开始系列一、如何摆脱低级错误的困扰

最近，有两位Google Maps API的初学者向我请教他们按照最简单例子写的程序为什么不能正常的运行。

其中一位用GTalk跟我交流，我仔细了看了他的代码，没看出问题，把代码保存在本地，打开Firefox的错误控制台，用Firefox打开他的页面。出错的那一行被清晰的显示出来，我再仔细端详那句话，原来有两个应该是英文逗号的地方，写上了中文逗号。

另一位，在我的论坛跟我交流他的Google Maps API中遇到的问题，我看他代码的时候也没有马上发现问题。然而，同样在用Firefox打开后，问题很明显的找到了，原来是一个方法openInfoWindow被他写成OpenInfoWindow了。

在我帮助别人解决的程序调试问题中，这是非常常见的。人人都可能打出中文逗号，人人都可能把大小写写错。但是在我帮助他们解决问题以后，他们总是感慨的说，谢谢我解决了这个问题，这个问题困扰了他们几个小时，甚至是几天。

这其实并不是只有初学者才会遇到的问题，我还帮助过些有非常丰富经验的工程师解决问题，有时候问题仅仅出自某个参数没有传递进来，或者是拼接字符串的时候少些了一个冒号，或者是拼接地址的时候漏掉了http:。我甚至帮助一些人调试一些我根本不懂的语言的程序，因为多半出现的问题，都和语言特性无关，不是程序员写错了字符，就是写错了逻辑，或者是错误理解了一个函数。

出问题是正常的，写程序是一个复杂的边思考边打字的过程，笔误和一时糊涂都是难以避免的。程序员一般把这种问题叫做低级问题，因为这类问题跟你的智商完全无关，任何人都可能犯。

但是，问题在于，有时候即使是很优秀的程序员，也会被一个低级错误困扰，可能会几天都解决不了。所以，关键在于，如何找到问题。

遇到问题的时候：

不要怨天怨地。出了问题，当然有可能是系统的bug，API的问题，但是那些几率往往比你犯低级错误的几率要低多了，先从自己身上找原因，是不是自己写错了。
要掌握工具。最低限度你要会写Log，最好是Log和调试器结合。好的工具可以大大的提高效率。以前有人跟我说，Dll不能调试，我发现可以；有人说多线程不能调试，我发现可以；有人说COM不能调试，我发现可以；有人说 IE插件不能调试，我发现可以；有人说OE插件不能调试，我发现也可以。当然，你确实会遇到不能调试的时候，当年我们做东芝芯片的嵌入程序，一个组都没有一个仿真器和调试器，但是至少可以用Log嘛，无非是麻烦点。
分析问题要有逻辑。遇到问题可以先把所有的可能性都列出来，然后一个一个分析，肯定能找到原因的。
要学会隔离问题。问题涉及到的代码越多，越难以理解，问题越难以解决。遇到这样的情况，可以利用Log或者调试器，一行代码一行代码的给它们洗清嫌疑，这样很快你就可以找到出问题的地方。如果代码特别长，程序特别复杂，可以用二分法来做，效率很高。
千万不要懒惰，不要事事求别人。一次复杂的调试过程就像一部侦探剧，如果你有非常好的逻辑性，那这部剧的主角就是福尔摩斯，剧情一定非常精彩。我说这个是有巨大风险的，说真的我帮人调东西挺上瘾的，很有意思。但是我还是要告诉大家，一次高难度的调试之后，你的满足感绝对不亚于写了一个伟大的程序。

要想不遇到问题，写代码的时候：

要对写出来的代码负责。我很佩服那些写代码写100行都不执行一次的高手，如果他们最后不被低级错误困扰的话我就更加的佩服了。我写程序几乎是写一行两行就要执行一次，每句话我都要确保执行效果跟我的预期一致。没错这样写的时候可能慢一些，但是调试的时候很轻松，我可以很简单的确定哪些代码绝对没有问题。所以我写代码整体速度比一般人高。很多人学习新东西的时候喜欢把例子抄一遍，运行一下，改改，再运行。我喜欢一句一句的抄例子，抄一句两句执行一次，这样可以把例子透彻的理解，而且很难会遇到出现了问题找不到原因的时候。
函数体功能块不要过长。我认为我的智商并不高，我很难接受一个程序的一个函数体或者一个功能块超越3屏（当然逻辑真的有那么复杂除外，你会发现越是简单的逻辑越是容易被人写的冗长）。很多人对面向对象耳熟能详，对封装继承看起来驾轻就熟。但是动不动就写出来个函数体超长的程序。这就像写本书从头到尾不点句号一样，会累死读者的。自己看的时候，估计也会被累的喘不过来气。这是我对基础教育的微词所在，他们连教会学生写函数都没教会，虽然表面上他们连面向对象这么高深的东西都教。
缩进要对。这点很重要，虽然大部分语言不是像Python那样用缩进来决定逻辑块的位置，但是人看到缩进的时候，总是会以为这些缩进位置跟逻辑相关。尤其是在有大量的ifelse或者for循环等等的嵌套逻辑的时候，如果缩进错了，可能会直接让人把程序的逻辑读错。所以我拿到别人的代码，第一件事情就是整理缩进。我见过一些比较优秀的页面工程师，他们会在div结束的位置用注释写上这个div的id，这样层级关系就一目了然了。
不断重构。随着程序的不断修改，有些部分会不断的增长，原来看着清晰的架构可能因为问题的复杂而慢慢模糊，也可能被修正bug的权宜之计弄的面目全非。不信你找一个经过多次修改的程序看看，是不是满目疮痍，是不是都很难认出是你自己的作品了。这在多人参与的项目中更加严重，每个人有不同的代码风格，经过多次杂交后，你肯定认不出你的代码是骡子是马，还是四不像了。随着程序的慢慢成长，原来有些函数体会慢慢膨胀，需要拆分；有些原来简单的功能块四处都需要，应该被提炼成函数或者方法，等等。现在不重构，未来等到代码复杂到无法控制的时候，重构的工作就会变得更加困难。我见过最强的案例是，一个几千行的电子辞典配套联机软件，经过无数次的改版，变成了一个几乎无法维护的主窗体的cpp有1万8千行的怪物。最后经过复杂的重构，才变成一个出新版本只需要新增一个驱动程序的可以维护的几千行的程序。这个故事详见：一个具体项目的重构（一），一个具体项目的重构（二），一个具体项目的重构（三）。

technorati tags: log, 调试, 重构