BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Kevlin谈写作
录制于:

| 受访者 Kevlin Henney 关注 5 他的粉丝 作者 Michael Hunger 关注 1 他的粉丝 发布于 2012年7月2日 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!
22:51

个人简介 Kevlin是住在英国的一位独立咨询师和讲师,在Better Software、The Register、Application Development Advisor、Java Report、C/C++ Users Journal等杂志、网站上开设专栏,是POSA第四卷《A Pattern Language for Distributed Computing》和POSA第五卷《On Patterns and Pattern Languages》的共同作者,还是《97 Things Every Programmer Should Know》一书的编辑。

QCon是源于社区、面向社区的软件开发大会。大会投入巨大的精力和资源以求令社区带头人就最重要的议题发表最精彩的见解,给社区同仁最好的参会体验。QCon的定位是技术深度和企业视角,专门针对技术团队领导、架构师和项目经理的兴趣所在。

   

1. 我是InfoQ派来的Michael Hunger,镜头前这位是Kevlin Henney,今天刚主持了QCon的软件匠艺专题。Kevlin,你能向大家介绍一下你的背景和现在的主要关注方向吗?

我的路子比较杂。我自己给自己扛活。根据地在英国,不过常得往国外跑。我做一点培训,做一点咨询,也写点东西,搞点评论什么的,比较杂。我感兴趣的主要有模式、过程、实践、编程这些大的方面,关注程度超过当前流行的具体技术。

   

2. 说到写作,这是你一直劲头特别大的一个爱好吗?

逐渐培养起来的。大概二十年前吧,我开始写文章是因为当时自己迷上了一些东西,特别想跟人分享。写着写着就成习惯了。后来和Frank Bushman、Doug Schmidt一起写了两本模式的书,又参与了别的一些书,编了一些出版物。诸如此类与写作有关的工作,就这么一直做下来了。我写过不少专栏,最近还稍微改变了一直以来技术写作的路子,开始写一些非技术的,以及小说类的东西,说明里面肯定有兴趣的成份。确实可以说我内心一直有点写作的冲动,不管是用代码还是轻松自然的语言来写作。

   

3. 写作的经历对你的开发者身份、你的思维、你和别人的沟通有什么影响吗

写作经历改变了我身上不少东西。大多数人没意识到软件开发者其实写很多代码以外的东西,我不是说文档,我是说像邮件那些。这些每天重复的事情,如果你想做得好一点,就要多留点心。我是从网上互动交流中学到的,后来我写文章的时候就变了一种写作方式,写作风格就变了。写作中间真正重要的是自我反思,还有别把字数当作目标和生产率指标。
对于任何写作,复查都是一种基本活动,你通过复查来证明你知道自己在做什么。我越是反复看一段代码,就越清楚要做的事情和代码的好坏,区分出还行的代码、差劲的代码跟有才气、有共鸣的代码。复查是最平实不过的活动。有句话我忘了是谁说的,“写作就是重写(writing is rewriting)”,就是这么回事。有些人虽然接受了“重构”等概念,但做起来还是半推半就、浅尝辄止的程度。有时候其实需要的不只是重构,干脆扔掉重写反而更好。再往大了说,其实是一种持续寻求反馈去完善作品的观念,因为作品其实是你的思维的外在表现,作品是你的表达。
当你开始将代码作为表达,当作“我对这件事的理解,我的知识和观点的呈现载体”,就会打开一个全新的方向。仅仅将代码作为计算机指令手段,这种过于单薄和平面化的视角无助于我们建设更大规模的系统、更不容易过时的系统、有更多人参与的系统。我在这方面想得越多,越重视反馈和自我提升的观念,重视反馈的途径方式,认识到作品总是处于一种“不凝固”的状态。在艺术领域有一种说法,小说、诗作、画作永远没有完成的一刻,只有被遗弃的结局。我们在软件领域也许不至于全这样,但时不时会遇到相似的遗弃感。

   

4. 写作要考虑目标读者;我也需要向开发同一个系统的同事传达我的理解。当读者不是指我们自己——即现在写代码的人,而是别的开发者,或者5个月之后重读代码的作者本人,你觉得写代码的时候要考虑哪些事情,才能照顾到读者?

你要代入别人的视角去看问题,这件事非常难,要想办法找到一些技巧去获得反馈。有人说“我的代码不需要注释,我的代码都是不言自明的”,这显然是个笑话。有没有达到不言自明的程度,不该由作者去下判断。“self documenting” 这项品质出自别人的观察、认可,不是说里面有“self”的字眼,你就可以自说自话了。回到自己写的代码中去,全身心投入,深入到一个程度之后,你感觉茅塞顿开,文思泉涌,很满意自己真正解决了问题。
很好,暂时放下,过一天再回头看看。长时间专注在一件事情上很可能令你忽视了一些焦点之外的东西。复审还有一层意义,就是让你总是警惕着:“如果将来我再回到这个地方,会怎么做?如果一周之后再让我看,会是什么感觉?六个月又会怎么样?”。复审还会提醒你以前的经历:“没错,事实证明我连自己的代码都不理解,难理解的不仅是别人的代码。当你拿到一段代码,最正常的反应就是复习。你看到的是一段不熟悉的代码,不管它是自己很久以前写的,刚刚写的,还是第一次看到别人写的代码。”
看着它,你思考它的原理,经过调查、探索找到答案,过程中可能还做一点笔记,终于在头脑中建立起一个模型,终于可以开始在上面做修改,又终于顺利修改完毕。对你个人而言,这是很好的结果;但是对下一个人来说,你没有给他留下任何路标。在注释里写上“这个地方很难理解,我也没看懂。这个变量名字没起好。”这样的信息远远不够。你与其在笔记里记下来“我记得描述的是如此这般的一个概念”,在注释里写上“这个地方表达如此这般的一个概念”,何不干脆把代码改掉,直接消除掉理解上的困难呢?“我不理解这一块代码,但它做了三件事情。假如我把这三件事分别提出来……”,主动出击去做第一手的写作。
与其做注释、笔记这种二手写作,为什么不直接去写?代码就在那里,流动的媒体就在那里。我们很多时候不一定敢下手,因为流动的代码翻过来说不定是什么坚硬的后果。但总归有那么一个思索过程,多来那么一点自省。设身处地地想一下,我能明白自己写的东西吗?别人能明白吗?我需要一遍遍地解释吗?当你发现自己老是解释某一段代码,你会怎么想?“那些人笨死了,怎么就是看不懂?等一下。假如一段代码老是需要我外加解释,也许应该把解释放在代码里面,把我给解放出来。”程序员要做到这样的自我质疑和批判眼光可不简单,不仅程序员,但凡人类都很难做到。这是人性使然。

   

5. 所以重点是把自己放在一个自我反省的角度,重构等工具不但是学习手段,还用来传送知识给下一位读者?

就是有意识地“通过代码来沟通”。当然不是任何事情都能用代码表达出来,但只要你好好想想怎么改能消灭解释的需要,怎么改能消除别人和自己的理解障碍,能透过代码传达的信息量是出乎你预料的。

   

7. 最近你还编了一本有很多人参与贡献的书,O'Reilly出的《97 Things Every Programmer Should Know》。你是怎么找上这本书的,或者说这本书是怎么找上你的?

这本是O'Reilly“97件事”系列的第三本。第一本叫《97 Things Every Software Architect Should Know》,诞生于Bruce Eckel主持的企业编程邮件列表。当时Richard Monson-Haefel为了准备演讲材料,到处问人什么是每一位架构师都应该知道的事情。他很快发现讨论组里面值得挖掘的经验智慧太多了,完全可以编一本书,于是就有了图书项目的构想。项目采取一种开放式、自主贡献的形式。起初参与的是讨论组里的人,但由于项目开放的wiki形态,大家都可以来添砖加瓦。
这个构想被执行下来,中间还诞生了“97件事”的品牌。选择数字“97”有各种实际的原因,也有闹着玩的成分。总之情况是影响越来越大,被吸引来参与贡献的人也越来越多,然后书就出成了。其实那本书有一个项目经理,所以也不能说完全开放,但运作都在wiki上进行。我编的《97 Things Every Programmer Should Know》灵感来自有一年夏天,我正斟酌着怎么给一位程序员交代代码批改意见的时候,看着代码心里面突然就冒出来这么一句话:“这种事情每个程序员都应该知道。”因为参与过之前那本软件架构师的书,话中的关键字马上就让我联想到,可以照同样的思路做一本以程序员为目标读者的书。于是有了后面的事情。
我们很快把想法付诸实践。我把书里应该涵盖的内容大致勾勒出来,还定下跟系列前两本不太一样的项目开展方式。因为希望吸引更大范围的参与,我们的计划是项目孵化之后,就在边上做引导,发挥群体智慧。项目汇集很多参与者个人的贡献,可以说我们建立一种了开源模型。我们从一种个人的层次去展现群体智慧,不同于代码那种开源,模块调用别的模块那种模型。除了关注和放大每个人的声音,你还要关注它们的相互作用。大家应该贡献什么内容,不由我来决定。我有时候会这么跟人说,“你的提议很不错”,“很有启发”,但不管多好的想法,一定要先拿给大家七嘴八舌一番,因为随便一个人都能坐着数出97件事。
程序员向来不缺观点意见。我说“我要97件事”,你就能哗哗地给我97件事。97件事我能举出来,任何人都能举出来,因此重点不在这里,重点是当你让大家都来评头论足的时候,才会从别人的意见里面发现你没想到的事情,而就算是你已经想到的事情,你也想不到别人能有那么新颖、精彩的呈现方式。这样的互动方式非常有意思。所以我尽量扮演编辑和项目带头人的角色,不以作者身份直接插手。

   

8. 你创作这本书的经历是怎么样的?有什么高潮、低潮吗?花了多长时间?

从冒出想法到摸到实体书,一年左右吧。时间记不清了。我用了开头的一段时间把事情带上轨道,当时想着应该设个“孵化期”,还联系了一些我觉得笔头好的人。孵化期的作用把标杆给立起来,不搞任其自然那一套。这样当别人来到我们的网站,会看到上面已经有一些实用的内容,前期的贡献已经给网站定下了基调。所以经过孵化期的准备之后,我才把项目公开,通过各种媒体去宣传。
其中Twitter最有意思,转发的次数非常多,招来很多人的关注。另外有些博客也提到这件事,我还在会议上做宣传,诸如此类。网络传播的过程同时也是很好的意见交锋过程,但是呢,你没办法预估过程需要多长时间,不可能定下确切的计划。从项目公开到截稿用了三个月,而公开之前的孵化期时间还要更长,我不去掐这个时间。我和出版社的对话很有意思。出版社说:“差不多够97件事了。”我说:“项目不是这么运作的。我们不能只看到97件事,而应该积累足够的材料去孕育一场充分的意见交锋。”把97这个数目当作终点,好比当你问人到目的地要多长时间,人家说要两小时,于是你开两小时就停了。
显然不能这么办 。我们追求达到一种临界质量。你不可能直接就知道选哪97件事最合适,只有经过群体互动的化学作用,才有一批精彩绝伦的文章冒出来,让你选进书里。你不是从单篇文章的质量去判断,而是可以看到文章与文章之间一种环环相扣的关系,让你觉得只有这样安排才是最合理的表达。孵化期的时候大家入戏有些慢,有些事情拖延很久,所以我用了一点管理技巧。第一件事是大面积地跟人谈话,因为根据我的自身经验,编辑跟我直接沟通比较管用。O'Reilly的人觉得说我这样会不会工作量太大。结果我一共和100位作者交流了将近170篇文章,工作量大不大?但文章质量确实上去了,而且和作者的关系也更紧密。我自己当过作者,知道交流的作用,最重要是大家清楚交流是为了做出好的作品。
用一对一的交流来代替没有特定对象的广播,这是其中一种管理技巧。还有别的技巧,还有我从软件开发中学来的一整套方法,例如怎样测量进度。如果你去看前面两个“97件事”项目,你想不到里面会有那么多未完成的条目。从wiki页面上看,一大串条目那么列下来,好像成果已经很丰硕的样子。但要是深挖下去,里面只是一个一个坑,这边有两句话,那边有一个构思,但就是没有完整的文章,没有真正的贡献。这时候我就想,“我们平常是怎么做的?有什么敏捷方法可以借鉴?怎么把真实的情况暴露出来?”其实不就是我们熟悉的to do、in progress和done吗?我就照做了。后期为了尽量清理“编辑债”有些小调整,因为我知道编辑的工作量很容易被低估。
我知道最后肯定要做统稿的工作,合作型的书必然少不了这一步,绝不可能直接就付印。一定要保证全部编辑妥当。而且编辑工作不能等到最后一刻才去做的,这也是编辑与作者持续沟通的意义所在。结果证明从截稿到完成文章挑选,只有不多的几件事需要特别处理。编辑的成本已经被我分摊开了,我采取的这种“early-and-often”的方法论,正是从软件开发借鉴过来的。它可以很好地应用于写作方面的工作,尤其是编辑工作。诸如此类的手段让进度得以直观地展现出来。我注意到一个有点哭笑不得的现象,不少以敏捷开发知名的人反而一直卡在“in progress”阶段出不来。
不会把生活中一个领域的经验运用到另一个领域,真让人不知说什么好。名字我就不提了,总之有相当数量的条目一直赖在“to do”和“in progress”,到最后也没有结果。高潮和低潮比起来,还是高潮的时候多一些。项目一公开,贡献就源源不断地涌进来,几乎应付不过来。我们一方面高兴,一方面又意识到必须把截稿期往前挪,不然处理不完。说到困难,网站上收到的贡献内容灌水的很少,造成我在终选的时候很难取舍,精简到110-115篇左右还比较快,再往下筛就很难了,减到99篇的时候我纠结了好一阵子。
都怪我们把97这个数字给硬编码在系列名字里了,早该写一条“千万不要硬编码常量”给大家看的。从99减到97太艰难了,我不得不去外面走了好大一圈才下最后决定下来。除了这件事情,照我夫人的说法,看不出有多少烦心的时候。我觉得编书的时候比我写书的时候要轻松多了,还行。

   

9. 这本书还可以在原来的wiki页面上读到?

对,肯定的。书上的内容全都在,还包括没收进书里的内容,所有东西都是开放的。现在能看到,以后也能看到,97件事系列默认是这样的规矩。这是真的开放,按照Creative Commons Attribution版权协议发表的。参与者之间有着高度的互相信任,我相信O'Reilly履行承诺,而他们确实做到了。他们给了很多支持,甚至准备近期对网站做一次翻新。大家为这个项目贡献时间精力,也是抱着对编辑的信任去做的。应该说编辑出版的工作提升了书中内容的价值,看书和看网页显然不一样,这本书的电子版卖得很好,说明看书和看网页其实是不同的体验。
有很多不一样的地方,很多方面都升华了。这个项目在积极正面的氛围里化出人的力量,这就是项目的推动力。你贡献一些东西,把大家吸引过来,然后你发现大家会给你回馈,而从回馈中诞生的产品,也就是我们的书,仍然对大家有吸引力。结果很圆满,保留网站并不会影响销售。

   

10. 除了书的创作过程和书本身以外,你从这本书中得到了什么?它对你有什么影响,或给你留下什么深刻的印象?

首先编这本书是一种享受。书里一共集合了73位作者,这个数字已经是一个成就。协调73个人一起来写作绝对充满乐趣,听到大家说他们的感受,我觉得很欣慰。有一位熬过来的作者说:"我一直想写本书,却从来没有结果,现在总算成功出版了一点东西。" 你可以看到诸如此类的满足感。有几位私下感谢我做的事情,我觉得很温暖,但最有成就感的还是当你向别人展示:“看看大家做出来这些优秀的作品。看这篇文章写得多好。”我说不清楚,应该是一种与有荣焉的感觉。我们在书里用了很多照片,也带出来这种参与感和个人色彩。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT