梦想风暴

和新手一起工作

dreamhead — Tue, 30 Jun 2009 23:43:53 +0800

不知道从什么时侯开始，周边的人把我当作一个老手，尽管有些自己不那么情愿，但现实是和我在一起工作的人大多比我工作经验少。

新手之所以为新手，是因为他们的经验较少，所以，不可避免的会犯一些错误。记得别人还在用新手标准要求我时，有一次出差，到了现场，项目负责人要我去安装我们的程序，可我根本就没把我们的程序带来，结果可想而知，项目负责人劈头盖脸的把我骂了一顿。

换我扮演老手的角色，我会尽我所能把项目中的一些不确定问题解决掉，然后，让新手们去解决那些确定性问题，通常，他们的能力应对这样问题会游刃有余。最近一年多的项目里面，涉及到了很多探索新技术的工作，我会从项目中挑出一个最简单的情形用新技术实现出来，这个例子可以帮助我弄清楚技术背后的来龙去脉。之后，我就可以把他解释给其他人。我的同事们都很聪明，理解了基础结构，加上一个现成的例子，他们就完全可以继续进行下面的工作了。

或许单独看起来，我的做法并没有什么特别的地方。刚好最近项目里面有两件点要去探索，我自己做了一个，把另外一个分给另外一个同事。他很快就做完了，而就是这个最简单的例子，我也做了好几天。探索的工作结束，进入到正式的开发工作，其他同事很快就可以接着我的工作继续开展。就是这个最简单的例子，除了了解技术的目的之外，我还写所有相关的脚本，万事俱备，只欠东风。而当我了解另外一个同事的工作时，我发现，他真的只做了一个最简单的例子，了解了一些基本概念。真正把这些内容运用到项目里时，左一个困难，右一个麻烦相继出现，我陪着他一个个克服了这些点，又把脚本预备好，几天之后，才真正进入到可以开发的状态。

有人曾经问过我，你把有趣的工作都做了，把无聊的工作留给别人是不是合适呢？毕竟每个人都希望在项目中成长。前面说过，我的工作是削除项目中的不确定因素。是的，很多人喜欢的就是解决不确定问题带来的快感。但不确定对每个人来说是不一样的。只要最基础的例子跑通了，这项技术的不确定性对我而言就解决了，但实际上，在具体使用这项技术中还会有一些不确定的问题等待解决，解决这样的问题，同样可以提高。

谈到成长，每个人都希望自己能够不断的成长，但是，即便是做同样的项目，每个人得到的机会也是不一样的，这样的差异实际上对应着各人不同的表现。和其他人一起工作的过程中，通过观察，我会把不同的工作交给不同的人来做。像前面说的那个同事，我之所以肯把一个探索的机会交给他，是因为他在之前的工作中表现出的态度和能力，虽然他的探索并不完全令人满意，但是，有了之前的信任，我会告诉他，怎么做才会做得更好。

之所以会想起这个话题，是因为一个同事与我聊起他项目焦头烂额的状态。他在那个项目组中，扮演着和我类似的角色，他感觉自己做得非常累，项目进展也有些问题，于是，我们俩聊起了如何发挥其他人的作用，既让新人感觉自己得到了锻炼，也让自己轻松一些。

《城客》：第一本中文互动杂志！

月度演讲

dreamhead — Fri, 19 Jun 2009 20:25:08 +0800

RubyConf China，我认识了Robin Lu。我们俩有种一见如故的感觉。我半开玩笑的对他说，有机会请你到我们公司讲点东西。

回到北京，我向老大汇报RubyConf China情况时，提到了这句话。老大说，我们不妨建立一个Monthly Speaker制度，每个月从外面请一个人到公司来讲些东西。

Robin Lu有着很强的分享精神，于是，他成了我们的第一个Monthly Speaker。

今天，我们第一次月度演讲，主题是iPhone开发故事。

Robin Lu为我们分享了他自己从事iPhone开发的一些经验。从他了解iPhone开发到成为一个iPhone开发者，再到，他将自己的软件放到AppStore上销售。最后，他又分享了自己对于iPhone开发的一些建议。中间很多的故事，只有亲身经历过的人才能讲得出。

一如既往，Robin Lu的演讲是那样平实，那样吸引人。他不是那种靠技巧取胜的演讲者，但他却很能抓住听众，凭借的就是内容。他留给人的印象是含而不露，没有咄咄逼人的气势，但却可以把问题深入的讨论下去。

Robin Lu为月度演讲开了一个好头，我开始期待后面的Monthly Speaker。

《城客》：第一本中文互动杂志！

Ant雕虫技

dreamhead — Thu, 11 Jun 2009 11:04:32 +0800

当构建脚本变得复杂，分离变化这样编程思路同样可以应用其上。

下面是一份简化过的构建脚本：













世界变化快，新需求来了，我们要进行一些安全设制。这份构建脚本即要支持安全版本的构建，也要支持非安全的构建。

冲入大脑的第一个想法自然是重写一个支持安全war任务。不过，稍加分析不难发现，安全版本和非安全版本的策略差异最终体现出来就只是一些属性的差异，也就是从config开始，二者就开始走上了两条不同的路。如果构建一个安全的war任务，那意味着，我们也同样构建一个安全的build任务，一个安全的config任务也是不可或缺的。这是一个经过简化的构建脚本，在真实的项目里面，task数量不会这么少，task执行的任务不会这么简单的。顺着这个思路想下去，得到就是一个让人抓狂的结果。

策略的差异只是影响到一些属性，如果根据不同的策略，只是配置相关属性，似乎生活就可以轻松许多。下面就是按照这种思路编写的一个新脚本：



































需要基于安全的版本时，
    ant sec war

而非安全版本是
    ant nosec war

这样，属性的配置和真正任务就成了两个独立的维度，不必因为属性的变动对任务进行大幅度修改。

在这个例子里面，我们用到了一些ant的特性，比如像configSec、configNoSec这样基于条件执行的任务，比如像defaultStrategy任务中，在没有指定参数时选择缺省的策略。

《城客》：第一本中文互动杂志！

环境的力量

dreamhead — Fri, 05 Jun 2009 10:11:16 +0800

和WPC聊天，提起了之前的工作岁月。听我说完当年的情况，WPC突然问了一句，你当时为什么不努力改变一下周边的人呢？

是啊！我为什么不寻求改变呢？

进入ThoughtWorks之前，我并不相信改变的力量。因为我周边的人向我传递的信息多半是一成不变，虽然那时的我已然是特立独行了，但改变其他人，我是压根没有想过的。大多数人给我的印象是，工作只是为了糊口，只要能够完成眼皮底下的工作，就不会再多花一点时间。我习惯了忍耐，我所能做的，只是把自己该做的事做好。

在ThoughtWorks工作的两年时间里，我听到过很多这样的声音：我们可以这么做，这样就更好了。每个人都倾向于把事情做到它应该俱备的好样子，而不仅仅是完成。在外做咨询的那段日子里，我看见了我们几个人给那个团队带来的改变，虽然不是如何巨大，但它真的改变了。慢慢的，我意识到，原来，我可以改变。

环境，可以影响到一个人的成长。

之所以，我在那样一个绝大多数人都沉寂的环境下，依然努力提升自己，是因为，我的身边曾经有Darwin和founder_chen这样的家伙，他们让我见识到另外的一种存在方式，点燃了我对软件开发的热情，所以，我才能一往无前。

现在，我的身边，有一些毕业就在ThoughtWorks工作的人。有的才工作一两年，他们的编程能力和对软件开发的理解远远超过我在同样阶段时的水平。偶尔想想，我会嫉妒他们，自己在黑暗中摸索和探寻了许久的东西，他们轻轻松松就得到了。可以预期，几年之后，他们的水平都会非常高，因为他们前面已然有这样的榜样了。

大多数人愿意和比自己强的人在一起：所以，读书的时候，好学生那么受欢迎；所以，有人会抱怨，我没有机会和某某一起工作过……

好的成长环境可以让人更快的成长，但成长的真正驱动力是自己。

这一点从毕业生观察会体现得尤为明显。同样加入公司，一段时间之后，有的就已经可以独当一面，有的却只能在别人指导之下工作。我和很多人聊过，那些我认为优秀的人，都会有很多额外的付出，好的环境加上自身的努力让他们与众不同。

在招聘的过程中，我们遇到过这样的应聘者，他的编程习惯都特别不错，但真正探讨起技术来，却显得不那么深厚。通过分析，我们发现，这样的应聘者通常是在一个很不错的环境中工作，这让他们养成了良好的工作习惯，但他们个人却并没有太多的额外付出，所以，他们对问题理解只停留在表面。

物以类聚，人以群分。你的群在哪里？

上海肯德基20年Say Yes-光阴的故事

RubyConf China

dreamhead — Thu, 21 May 2009 23:43:22 +0800

此刻，我，在上海。

距离上次离开上海还不到两个月，之所以重返大上海，是为了RubyConf China。

刚听说RubyConf China要举办的消息时，我就在想，找个怎样的借口才能到上海参会。所以，当我们负责市场同事找到我，说需要一个演讲人的时侯，我毫不犹豫的就接受了任务。

接受任务是喜悦的，完成任务却是烦恼的。先是gigix和WPC讨论演讲的主题，最终定下分享我们在Ruby项目的一些经验，接下来，就是具体的准备了。每次准备演讲对我来说，都是一个痛苦的过程：一方面，我希望自己的演讲对听众来说，有一些价值，另外一方面，我还要保证思路顺畅，不让人感到突兀。这一次的准备，尤其困难，因为得到确切消息距离大会只有一个星期了，而且我还在项目上。感谢gigix和WPC等人，在他们的帮助之下，我对要讲的内容逐渐有了一个更加清晰的认识，也是因为如此，演讲稿也迟迟达不到可以拿出手的标准。负责联系演讲者的Daniel几次催我提交演讲稿，我何尝不想啊！演讲前夜，我依然在不断修改。

这次RubyConf China最大的主角，自然是Ruby之父Matz先生。从他进场时那经久不息的掌声中，就可以看得出他到底有多受欢迎。他的演讲《Why Ruby？》介绍了他开发Ruby的一些历史，以及他在设计程序设计语言的一些考虑。很多想法也与我的一些观点不谋而合，听得我频频点头。Ruby原来是一个失业者的产品，时值日本经济不景气，失业在家的Matz利用这段难得的空闲，写出了Ruby。另一个失业者著名产品BT。很多人内心难以接受的失业原来也是一个巨大的资源。Matz说，如今这样一个不景气的光景，说不准就会产生出下一个影响深远的语言。

借助演讲者的身份，我让会议的组织者引荐我认识了Matz。时间关系，我只和Matz做了一个非常短的交流，介绍了自己在Ruby实现上的一些工作，算是和Matz彼此相识了。最后，我邀请Matz到我们的北京办公室去做客，Matz欣然应允，“只要你们邀请我就好”。

这次大会的内容还很扎实，robbin的《JavaEye网站架构深度解密》和robinlu的《Ruby and Rails Pitfall》是两个亮点，拳拳到肉。只有真正的经历过这样的问题，才能讲得出这样的话。从演讲技巧上来说，他们两个都算不上优秀，但扎实的内容让人已然忘却了外在，全心全意追随他们的内在。

koz的《岛根县政府的挑战－在日本地区政府和社区当中使用Ruby的案例》是一个介绍，让我们了解Ruby在日本的发展，很开眼。让我惊讶的是，他——一个日本人用中文完成了整个演讲。Ruby的流行程度超乎了我的想像，可以说Ruby教育，从娃娃抓起。原来，岛根县就是Matz居住的地方，岛根县对于Ruby的推动，让我想起了鸟山明，政府为了让他送稿方便，而修了一条高速公路。

其它几个演讲带给我的冲击相对来说要小得多。至于我自己的演讲，留给别人评价吧！

最后的Q&A环节，说实话，我更想坐在下面做一个可以提问的听众，而不是一个回答问题的演讲者，因为对于其他人的演讲，我还是希望有更多的交流。在这个环节中，有一个人用日英中三种语言提问，成了大家关注的焦点。

整体来说，这次RubyConf China还是很成功的，考虑到组织者只用了一个月时间，这样的结果已经让人非常满意了。robbin说，争取下半年在北京在办一次。北京的Ruby开发者们，期待吧！

《城客》：第一本中文互动杂志！

程序员的编译入门教材

dreamhead — Sun, 10 May 2009 17:57:00 +0800

提起编译器，很多程序员都会心向往之，但真的动手实现一个编译器，许多人心里就打起了退堂鼓。因为在他们心里，编译器等价于编译原理，而编译原理就意味着一大堆让人找不到北的名词：有限自动机、语法制导翻译、窥孔优化……

我承认，读书的时侯，我也被这些东西恐吓住了，虽然编译原理这门课我得了一个不错的分数，但还是一脑子浆糊。不过，我相信，如果不能把想学的学生教明白，多半是教材（和老师）有问题。所以，大部分的编译原理教材是不合适的。但合适的在哪里呢？

之所以这些教材不让人喜欢，主要是这些教材一上来就给扔下一大堆理论。作为一个程序员，我们最喜欢的是代码。所以，如果给我看代码，然后，结合代码给我讲理论，我才可能心情愉悦的接受这些理论。

有龙书之称的《编译原理》是个不错入门书。我知道，有些人已经开始怀疑我了。只要看一下龙书的目录，就会发现，它和大多数编译原理教材没有本质的区别。不过，这里并不是让你读完整本龙书，我推荐的程序员入门教材只是其中的第二章。

这一章实现了一个非常简单的编译器，把一个自定义的语言转换成一个中间代码。无论是语言，还是中间代码都非常简单，但这并不妨碍支撑起一个完整的编译器前端框架：定义语言、定义运算符优先级、词法分析、语法分析、建立符号表、代码生成。所有这些东西对于实现一个编译器都是必需的。龙书第二版选择了Java作为第二章的实现语言，而在第一版的实现语言是C，从入门的角度而言，让人有了更多的选择。

这是一个纯手工打造的编译器，所以，我们可以清晰的看到代码到中间代码的转换过程。之所以强调它的纯手工，是对比于现在很多的编译器前端生成工具而言，比如yacc和Antlr。这样的工具可以极大的程度提高我们的生产率，但是从学习的角度，纯手工编译器可以帮我们理解这些工具运作的机理。了解了纯手工过程之后，如果还想了解依赖工具实现，那就不妨参考有人实现的Antlr版本。唯一的遗憾是，这个版本用的Antlr 2，而不是最新的版本。

读完了龙书的第二章，我们拥有了编写编译器前端的基础知识，但这些内容还不足以让我们窥见构建程序设计语言的全貌。《Unix编程环境》（The Unix Programming Environment）是我们的下一站。

放心，同龙书一样，我不会让推荐读完这本看上去和编译器没什么关系的书。我们的选择还是其中的一章，第八章，一个关于程序开发的章节。原本，这是一个介绍如何在Unix上做开发的章节，实现了一个计算器，只不过，随着功能不断丰富，这个计算器最终变成了一个完整的语言（hoc）。同龙书第二章只生成中间代码不同，这个实现真的是一个完整可用的语言。

这章用了六个阶段进行实现：

第一阶段，实现一个简单计算器
第二阶段，加入变量名和错误恢复
第三阶段，实现任意的变量名，并加入了内部函数
第四阶段，实现一个机器，这便是一个虚拟机的雏型
第五阶段，有了控制流和关系运算符
第六阶段，实现函数、过程和I/O

我非常喜欢这样的讲解方式，完全是一个循序渐进的过程，功能逐渐丰富，每一步做的事情并不多，让人可以专注于当前讲解的部份。考虑到这是一本诞生于1984年的书，如果再年轻一些，估计我们可以看到一个完整的面向对象语言的实现。

相比于龙书第二章只给了我们一个前端，这里给我们的是一个完整的语言实现。准确的说，不是一种实现方式，前三阶段的实现只是一个简单的解释器，从第四阶段开始，它变身成一个编译器，因为它要运行在一个自己实现的虚拟机上。虽然这个虚拟机并不像我们现在知道的很多虚拟机那么强大，但它已经很好展示出一个虚拟机的运作方式。在学习编译器之余，我们顺便了解了虚拟机。

这是一本关于Unix的书，所以，即便是在这一章里面，我们可以处处体会到Unix的文化。这章的讲解方式就是最好的一种体现，把事情做简单。六个阶段，每个阶段都很简单，不知不觉中，一个像样的编译器就呈现在眼前。仔细品味知识的同时，顺便习得Unix的工作方式，何乐不为。

如果打算动手按照书中的内容一步步把这个编译器实现出来，需要说的是，书里面用到的C语言时很早期的C语言，而不是我们熟悉的现代风格。如果你打算用自己习惯的方式编写，那么就要做好调整代码的准备。实际上，这个语言是在不断发展的，所以，我们可以找到它的现代版本（1、2、3、4），相对来说，现代版本显得有些复杂了。对比书上的内容和现代版本进行实现，是一个不错的选择。

这里提及只是一些入门教材，了解了以上的内容之后，并不能让人成为一个编译器专家，但应该可以削除对编译器的恐惧，至少，可以去尝试挑战编译原理那些不合适的教材了。

《城客》：第一本中文互动杂志！

两年思想工作者

dreamhead — Fri, 08 May 2009 22:21:13 +0800

两年的今天，我成为了一个ThoughtWorker。

两年的时间，我对软件开发有了更加清晰的认识。同Darwin聊过，我们都有相似的感觉。加入ThoughtWorks之前，我们虽然都写很多年的代码，但是对于软件开发的理解依然非常模糊，准确的说，有很多东西是我们想不清楚的，比如，为什么要写一大堆没有人会看的文档。曾经有一次，当时的公司在推广CMMI，部门的技术负责人给全部门讲解相关的东西，我就抛出类似的问题，得到的答复是，过程要求。在ThoughtWorks做开发，我很少考虑这些问题，一切就是那么顺其自然。当我有机会给别人敏捷的时侯，我突然意识到，软件开发原来并非不可理喻，敏捷是一种顺应人性的开发方法，需要智慧的工作，尊重人性可以更好的发挥人的作用。

这两年的开发，我学会了价值分析。价值分析，用通俗的话解释就是，挑重要的事做。这包含了两方面的含义，一是做的事要有价值，二是当一堆事摆在面前时，挑价值大的。这是敏捷软件开发中非常重要的一个观点，我最初接触到这个观点是在Story分析上，所以，我最初只以为它是用于指导Story分析的方法。但随着接触的人和事越来越多，我发现，价值分析适用于很多方面。价值分析已经成为了许多ThoughtWorker做事的指导方针，每当我们开始做一件事，我们都会问一句，这件事的价值何在。比起曾经的那种“别人怎么指挥，我就怎么干”的工作方式，这样的工作方式让我们做事的目的性更强。

在《高效开发的敲门砖》中我写道，读《Productive Programmer》给人带来的思考，怎样提高自己的工作效率。在ThoughtWorks的工作，我学会有意识的提高自己的工作效率。一方面，同别人的结对开发时，我会观察别人一些好的习惯，争取化为己有，另一方面，寻找开发中一些让人不爽的地方，改进它，提高开发效率，“写个脚本”成了很多ThoughtWorker遇到反复进行麻烦事的第一反应。这样的观察为咨询工作奠定了一些基础，要知道，咨询需要发现问题的本事。

有时侯，追求很简单，每天高高兴兴的做好工作，在ThoughtWorks，我至少经历过这样的软件开发。

上海肯德基20年Say Yes-光阴的故事

“轻松”时刻

dreamhead — Wed, 06 May 2009 21:04:44 +0800

项目做多了，就可能碰到各种各样的情况。时间紧，任务重的，有；时间松，任务轻的，也有。

“沉重”的工作会让我们无比思念“轻松”的工作，但真的有“轻松”的工作，我们能够把它做好吗？

我知道，有人已经开始暗自念叨，生在福中不知福，轻松的项目还不好做，把代码一写，然后，潇洒转身。哪怕用剩余的时间，对着窗外的阳光发呆也好。

给别人讲TDD，很多人记住的是，TDD就是先写测试，后写代码。可TDD的节奏实际上是红——绿——重构。重构是什么？对于TDD来说，它是一个停顿，给人一个思考的机会，品味新鲜出炉的代码对于整个系统而言，有怎样的影响。

我想你也知道我想说什么了。如果仅仅按照“沉重”的工作方式去做“轻松”的工作，是不够的。所以，前面的问题是做“好”。

做“轻松”的工作时，既然有了足够的时间，我们就该争取了解事情的来龙去脉，而不只是满足于可以看到一个结果。做开发的人都知道，知识都是一点一点积累的，今天积累的知识说不定在那天就会有用。不趁着轻松的时侯，多了解些东西，等“沉重”到来，飞奔之时，那还顾及得到路边的风景。

即便在一个项目内部，我们也常常会有轻松和沉重的区分。轻松时，完成了基本的工作，我们不妨想想新代码会对系统有怎样的影响；不妨翻翻旧有的代码，寻找哪里是忙时忽略的东西；不妨想想做些怎样的工作可以让未来的生活更美好一些。

我很喜欢一个关于重构的比喻。重构，有如健身，大规模的改写，则是手术，健身做好了，也就不必动大手术了。

“沉重”时的狼狈，很多是因为浪费了“轻松”。

上海肯德基20年Say Yes-光阴的故事

非喜欢项目

dreamhead — Mon, 27 Apr 2009 22:27:44 +0800

在ThoughtWorks工作，有机会接触到很多不同的项目，于是，自然会有喜欢的和不喜欢的。

大约5个月前，有人对我说，你出差吧！可我不喜欢出差。但我还是去了，毕竟我从来没有做过咨询项目。接下来的四个月里面，我成了一名咨询师。
大约两个星期前，有人对我说，你培训吧！可我不喜欢培训。但我还是去了，毕竟我没有当过老师。于是，我真的讲了几天的课。
今天，有人对我说，你做新项目吧！可相比之下，我谈不上很喜欢这个项目。

5个月后，我知道了咨询和开发之间的差异，也得以重新认识自己，我发自内心的感谢这样的机会。
两个星期后，我为学员们打开了一扇通向敏捷开发的门，他们快乐的编码，深入的思考让我觉得很成就感。
这个项目下来会是什么样子呢？

两年前，我以为的低谷时，我知道了明白了一件事：对我而言，喜欢是很重要的；不喜欢的，只要去做，也会有收获。

有经济大环境的影响，加上公司的一些因素，让我最近不得不去做一些自己并不是特别喜欢的项目。所幸，所做的这些给我了一些不错的回馈，甚至影响到自己很多看问题的根本观点。于是，对于那些自己不喜欢的项目，我也不像从前那么从打心眼里讨厌。

当然，我最想做的还是自己喜欢的项目。

上海肯德基20年Say Yes-光阴的故事

QCon北京两日游

dreamhead — Sun, 12 Apr 2009 20:33:26 +0800

QCon的名气很好很强大，当QCon来到中国，我心向往。

时间刚刚好，上海的飞机一落地，北京的QCon就开始了。本来三天的QCon，因为公司的事务，错过了第一天，也就错过了老马的演讲。去年的Agile China也因为家里事错过了老马的演讲，也就是说，迄今为止，一次老马的演讲都没有听过。

从安排上来看，我对QCon北京的预期高于其他国内的一些技术大会，但低于QCon在其他地方的会议。高，是因为InfoQ和QCon的名头；低，是缺少足够的技术话题，硬货比较少。

两天的会议中，给我印象最深的是，洪强宁关于豆瓣架构的介绍。他按照时间线将豆瓣的架构介绍了一番，每一步发展会遇到怎样的问题，做了怎样的调整，达到怎样的效果。思路非常清晰，听着很过瘾。FreeWheel的CTO Diane Yu也给我留下了很深的印象，她的观点“架构也是需要演化的”深得我心。我还特意问了一下，FreeWheel如何做架构演化，当我得知他们会将一半研发力量投入其中时，我也吃了一惊。西门子的李伟为大家展示了另类软件开发，机场、生态城市等方面的建设，以我的理解，这么大的系统工程，远远超出了我们常规理解的软件开发。

有很多人，本身做的事情应该很不错，但话题的组织或本身的演讲能力着实一般，作为一个听众，我很难捕捉到一条主线，跟上演讲的思路。淘宝的演讲据说因为有些东西因为涉及到一些所谓的内部信息，被拿掉了，影响了思路的连续性。有道的演讲，像是所有内容都拿掉了，临时拼凑出来一些别的东西。

适当的降低期望是有好处的，捧得越高，摔得越狠。比如，当一个人顶着大师的光环出现时，人们会巴不得他说出来的句句是箴言，但结果，他用无数的比喻在真正的问题外面兜一个大圈子，又摆出一副高处不胜寒的样子信口雌黄的指点一番江山。你会怎么想。除了怀疑给予大师名头的人头脑有问题，剩下的就是想骂人了。

如果我们敏捷了，是不是就可以像你们公司一样，冰箱里面装满食物，随心所欲的吃呢？（有关系吗？）
我是一个学生，能不能从哲学的高度探讨一下模式？（代码写好了吗？）

作为听众，如果我们能够问出更有档次的问题，QCon会更好。

总而言之，QCon北京开了一个头，希望以后可以继续办下去。

《城客》：第一本中文互动杂志！