关心

THU – team players 合作精神

2010-01-24T14:12:42Z

我朝的教育体系虽然时不时灌输“互相帮助”的精神，但是所有小考，中考，大考，无一不是考察个人独立作战的能力。你要互相帮助，不但违反考场纪律，而且其他同学的好成绩对你是一个直接的威胁。在这种价值体系下产出的学生，合作精神如何? 善于合作，对自己是弊大于利么?

在清华大学《现代软件工程》课中，我安排同学们有尽量多的机会和别人合作:

1) 两人一组的结对项目 I (为期两周)

2) 两人一组的结对项目 II (为期两周)

3) 4~5 人一组的团队项目 (为期十周)

我们安排让每个学生在三个项目的合作伙伴都不一样，这样，一个学生在这个课程中有机会和 5 至 6 个人合作。在组员眼中，你是不是一个好的合作伙伴? 我们让他们给各自合作过的同学打分 ( 1.. 5 分，5分最高)，下面是结果。

[第一列：学生学号，按合作精神分值高低排列; 第二列：合作精神得分; 第三列: 学生学号，按最后得分由高到低排列]

以0.5 为区间，得分人数分布如下。

这个投票的结果不计入课程成绩，大家匿名投票，当然还有一些同学没来上课，失去了投票的机会。由于投票者分布在3 个不同的项目中，可以说数据还是挺全面的。可以看出，有得全票满分分 (5.0) 的同学，也有得1.5 分的同学。对比第一列和第三列，绝大部分合作精神得分高的同学，最后课程的得分也相当高。

很多学生并没有自知之明 (self-awareness), 觉得自己已经很了不起了，别人也应该对自己顶礼膜拜, 至少为能有机会和自己合作而庆幸不已... ... 我上课的计划就是把这样的得分公布出来，让同学们看看自己在别人眼中的地位。相信一些人看了数据，会很震惊 - “平时大家都是哥们儿，怎么我才得这么少分数? ”

以后好些年，可以回头看看，“混得好”的人和团队精神高的人，是不是有相关性。

THU - 清华大学现代软件工程成绩统计

2010-01-23T05:28:32Z

第三年讲这个课。同学们除了完成个人项目，结对项目外，还完成了如下的团队项目:

team 1 (最后评审第二名)

一个日程管理的小软件，名为Lifer，可以与Google Calendar同步的 Todo / Calendar / 便签管理工具。

team 2 (最后评审第五名) 评审时尚未发布软件。

Q三国杀 - 像所有的游戏软件一样，多次推迟后，发布了一个问题多多的版本，他们的总结提到:

什么功能产生的bug 最多，为什么？
规则部分的bug较多。这是因为三国杀本身的设计造成的，其规则比较凌乱复杂，难以用一个清晰的框架描述。比如说:
· 关羽在被借刀的情况下是不能将红色的武器当杀打出
· 关羽在出过杀的情况下不能将红色的的诸葛连弩打出
· 大乔流离的时候，如果用武器或者马流离，则要去掉武器或马的距离

其实，最大的问题出在项目管理上。

team 3 (最后评审第四名)

课程管理助手

team 4 (最后评审第一名)

SmartMe - 用多个搜索引擎同时解决你的任何问题。

team 5 (最后评审第三名)

Cute Reminder -

1.BBS(newsmth,各系bbs等)消息管理、消息提醒； 2.网络学堂信息管理、信息提醒； 3.备忘录功能、日程提醒。

编程之美 - 哪个题目最美?

2010-01-02T15:42:00Z

编辑部搞的活动，请大家帮个忙，来投票吧，看看《编程之美》第1章“游戏之乐——游戏中碰到的题目”大家最喜欢哪个题目，或者大家认为哪个题目最有趣。
　　
　　
　　可以选择以下任何网址参与投票：
　　CSDN：http://vote.csdn.net/VotePost.aspx?voteid=6419

　　开心网：http://www.kaixin001.com/~vote/detail.php?vid=6324994&uid=57936198

　　QQ空间：http://user.qzone.qq.com/80754098/vote/1021116304

最不美的题目说不定以后就不要了 :)

顶级程序员的心得 Coders at Work (IV)

2009-12-26T04:12:11Z

( 第一，第二，第三部分 )

“Coders at Work”, 对15 位顶级程序员的采访，总共600页。看似冗长的问答中有不少精辟的言论。我摘录了一些关于挑选，面试程序员，优秀程序员的特点，和程序设计的句子。下面是最后 3 个程序员的心得，和我的几句解释：

Coder

What they say about good programmer, interview, and design

My interpretation

Fran Allen

first woman winner of Turing Award

Software process:

did software-development process save the IBM/360 project?

it's was absolutely necessary, but it was painful for the software people to [adjust to] design reviews, design specs, all of this stuff.

good programmer:

basic threshold: find out what they're excited about.

if they can't get enthusiastic about something, they're not going to get charged up in a group.

软件流程:

因为IBM/360 项目的软件部分遇到了很大的困难，那时候还没有什么成文的 "软件工程"， Fred Brooks 把管硬件的经理们调来，让他们来管软件部门，因为硬件是一个相对成熟的产业 - 芯片设计，测试，等等。这些“不懂软件”的同志们参考硬件产业，建立了软件工程的基本流程。

从一个成熟的产业中学习，是很有效的办法。现在我们还可以从软件工程的一些术语中看到硬件的影子 - 例如 smoke test 冒烟测试。

好的程序员:

热情 (前面 Ken 同学也谈到了这一点)

Bernie Cosell

czar of PDP-1

pioneer of APPANET, the core of the later internet

advice to programmer:

write a lot of programs.

there is very few inherently hard programs. if the code looks very hard, that's almost always an indication that it was poorly thought thruough. if you have complicated code, put it in an encapulated place.

programs are meant to be read.

avoid premature optimization

find talented programmers:

whether they have the kind of inquiring, curious, precise kind of mind. quickness of learning, interested in lots of different things, and kind of broadly based.

[carefully chosen] puzzle can gives you a glimmer as to how they organized something to approach it.

给程序员的建议:

写很多程序。

世界上难的问题/程序很少，如果一个人的代码看起来很难，这通常意味着程序员没有想清楚。如果你必须用很复杂的代码，把它包装起来。

程序是用来给人读的。

避免过早优化。

优秀程序员:

应聘者有没有刨根问底，好奇心, 准确的思维? 能快速地学习么? 是否对很多东西都有兴趣? 是否有很广泛的基础?

[仔细挑选的] 智力题能让你看到应聘者是如何组织材料，解决问题的。

Donald Knuth

TAOCP, TeX and METAFONT, literate programming

Knuth 在学术界的影响

How I learn programming – basically taking one program that i made up myself and sitting at a machine over a period of some weeks, and kept getting it to work a little better and a little better.

Q: Should every programmer be able to read TAOCP?

A: I sometimes wonder if I can read them.

but even an algorithm like a balanced tree ot AVL tree, i don't use it in m own programs unless i know that it's going t obe a really big tree.

what do you use?

i use an ordinary binary search tree with a little trick for randomizing it that i just put it.

...

顶级程序员的心得 Coders at Work (III)

2009-12-25T15:37:02Z

这是第三部分（第一，第二部分），非常有意思的问答，值得仔细琢磨。

这里只是一些和程序员发展，面试，优秀程序员的特点等相关的部分。

有些想法和 MSF 中的原则也很相似（见 <移山之道>）。

Coder	What they say about good programmer, interview, and design	My interpretation
Dan Ingalls Guru of Smalltalk; inventor of BitBlt operation, working on Lively Kernal now.	Tips on a good technical leader: 1) clear vision; 2) trust people; get everything figure out, but leave it open to team member to do it. 3) avoid micromanagement. if you’re worried and you’re insecure, and so you’re feeling like you hve to nail everything down. Alan Kay is a good example for such great leader.	技术带头人: 1) 清楚的远景。没有清楚的远景，只有强大技术能力的团队，就像盲人骑瞎马，还使劲用鞭子抽打，让马快跑。看起来一度非常拉风，但后来免不了人仰马翻。 2）信任团队，把大方向弄清楚之后，把其他事情交给团队成员去搞清楚。如果带头人详细规定了所有细节，那么团队成员干得还有什么劲呢？ 3）避免“微观管理”。当你担心或者没有安全感的时候，你当然会希望把所有细节都搞清楚，但是这样反而会出乱子。
L Peter Deutsch veteran of Xerox PARC, author of Ghostscript; now he is into music composition.	skills of good programmer: intuition – no luck, but experience that had simply gotten internalized so far down that i didn’t have conscious access to the process. programmer – people who feel comfortable swimming around in the world of symbols. programmer vs. coder: "Coder" is strongly associated with the smallest and most narrowly focused part of that whole software building endeavour. "coder" represents such a small corner of the whole processs. a good title should be: software developer. computer science = enginnering + applied mathematics. I would've thought that the internt was inherently uncontrollable, and i no longer think that. China shows that you can do it pretty effectively.	优秀程序员：直觉。但是Peter 说的不是运气，而是长期实践之后成为你思维一部分的东西 - 你不知道推理这些东西出来，正如同你不知道如何推理出直觉。 Peter 认为优秀的程序员必须能在抽象思维 (world of symbols) 中得心应手的人。程序员 vs. 码农: Peter 认为Coder 把程序员的工作定义得太狭隘了。就像IT 民工，翻沙，砌墙。砌墙并不是一个坏工作，但这只是“建筑”这一过程中的一个小部分。 "软件开发者" 应该是一个好名称，虽然并不全面。所谓 "计算机科学" 不过是工程加上应用数学。我原以为互联网是根本上无法控制的。。。
Ken Thompson creator of Unix.	Talented programmers: it's just enthusiasm. you ask them what's the most interesting program they worked on, get them to describe it and its algorthms and what's going on. if the ycan't withstand my questioning on their program, then they are not good. enthusiasm is not something you ask directly, but in the conversation you'll come with the enthusiasm-ometer.	优秀程序员的特点: 就是“热情”，我们有时也说 "passion for technology". 但是在面试的时候你不能问 - 你对计算机技术有热情么? 因为所有回答都是 yes。你要在场景中，对话中感觉对方的“热情”。如果一个念了5-7年计算机专业的人，不能 “两眼放光”地给你讲他自己最得意，最激动人心的项目或算法，不能回答你的深入提问，除了老师的作业和实验室老板叫做的项目之外，没有别的想法。你觉得这种人有多少 “热情”? Ken 还表达了自己对C++ 的意见，几乎所有这本书采访的牛人都不太喜欢C++，很有意思，不过这是另外一个话题了。

顶级程序员的心得 Coders at Work (II)

2009-12-24T14:47:10Z

正在读 “Coders at Work”, 对15 位顶级程序员的采访，总共600页。这些看似冗长的问答中有不少精辟的言论。我摘录了一些关于挑选，面试程序员，优秀程序员的特点，和程序设计的句子。下面是 3 个程序员的心得，和我的几句解释。 Peter Norvig 讲了NASA 的一个著名事故的一些故事，我也重构了一下，写在后面.

Coder

What they say about good programmer, interview, and design

My interpretation

Simon Peyton Jones

Haskell architect, MSR-Cambridge researcher

Beautiful Code: agrees with Tony Hoare that good code should obviously have no bugs, rather than having no obvious bugs. but “looking at the bare code may not be enough, it’s not a characteristic of beautiful code that you should be able to just look at the bare code and see why it’s right. (AVL tree is one example)

漂亮的代码:

像Tony Hoare 说的那样 – 它们明显没有bug; 而不是没有明显的bug.

但是“漂亮”并不意味着看着源代码就能马上读懂。例如 AVL 树, 光看代码你不懂为什么这些子树要转来转去。但是如果你理解了它的核心思想，看到它维护了这个不变量 (invariant) 从而保证 log 级的访问速度，你就会说，”啊，明显理当如此。”

Peter Norvig

In charge of Research at Google, NASA.

Made fun of PowerPoint AutoContent Wizard

Advice to school:

Teach more on team work. “when I was in school, working as a team was called cheating”.

Successful programmer:

The bravado and willingness to “go ahead” with incomplete but essential info.

Interview:

I don’t like the trick puzzle questions. It’s important to have someone that you can get along with. More, Can they technically do what they said they can do? You really want to have people write code on the board.

XP, pair programming:

10% of the time is to share is important, but if doing it most of the time, it won’t be as effective.

UML:

I never liked any of these UML-type of tools. If you can’t do it in the language itself that’s a weakness of the language.

学校教育:

应该教更多的团队合作，“我上学的时候，团队合作被认为是作弊” (现在有些学校还是这样)。

成功的程序员:

他们更多的是“我只要懂得我需要的，就可以开始干活了”，而不是“我得完全理解某个领域，才能开始”。

面试:

不喜欢用智力题目，要依赖于面对面的问答来判断这个应聘者是否能够和团队合得来，更重要的是，让他们在黑板上写代码，看看他们是否真的能“说到做到”。

XP, 结对编程:

10% 的时间用来交流是很重要的，但是如果大部分时间都用来结对，那效率不会太高。

UML:

我从来不喜欢这类工具，如果你不能在计算机语言中表达(UML 要表达的东西)，那这是这种语言的弱点。

Guy Steele

Help created Common Lisp and Scheme, Emacs

Code writing:

When you are writing code you’re writing as much for human readers as for the computer.

If efficiency is important, I’ll often resort to a trick. And then I realize that will mislead a human. And you have to comment it or do something to flag that, to make it more readable.

代码:

当你写代码的时候，你写给机器看，同时也写给人看。

如果效率很重要，我会用一些小技巧。这些技巧会误导读代码的人，你得加上注释，或者类似的东西标注一下，让它更可读。

Peter Norvig 同学在NASA 工作的时候，参与了NASA 的一个著名事故的调查 ( 1999 年“火星气候卫星” 因导航出现重大错误而坠入火星大气层)。从他在这本书的问答中，我们可以看到一个大略的错误发生过程:

1) 软件外包公司对于 mission-critical 的软件模块有很完备的检查和测试，但是对于其他模块则没有完备的管理。

2) 程序员写了一个不重要的log 功能，其中用英制 (磅* 英尺) 表示力, 但是 NASA 用“牛顿”= 千克*米/(秒*秒)

3) 外包公司接到一个新的工程，他们进行了软件重用，log 功能中记录的力被重用为导航功能的输入参数，成为 mission-critical 的模块。 //错误: 一个模块从 non-mission-critical 变成 mission-critical 没有经历必要的复审和测试。

4) 这个新的工程由发包公司 Lockheed (洛克希德公司) 交给了客户 JPL (喷气推进实验室)

5) 火箭带着卫星发射了，在10个月的飞行中，JPL 可以每天两次启动小推进器，来调整太空船的航向，在这一过程中，有人发现了导航功能的一些不正常现象, 于是 -

a. JPL 发邮件给 Lockheed, 说 – 这个模块有些参数看起来好像不正常…

b. Lockheed 回邮件...

c. JPL 再发邮件…

d. 最后没有人再发邮件了

e. JPL的同志认为， Lockheed 的同志们估计已经搞定了。

f. Lockheed 的同志认为， JPL 的同志们没再追问这个问题，可能已经不是问题了。

错误: 这个问题从来没有收录到NASA 的错误跟踪系统 (Bug tracking system)，只是在email 中交流，导致最后没有人对这个问题负责。在错误跟踪系统中，总得有一个人“拥有”这一个bug，这样可以避免推诿责任。 (MSF 也很重视这一点)

十个月之后， 1999年9月23 日，卫星抵达火星大气层，错误的导航参数造成卫星坠入大气层烧毁。单单卫星的造价就高达一亿两千五百万美元。

顶级程序员的心得 Coders at Work (I)

2009-12-23T03:09:33Z

正在读 “Coders at Work”, 对15 位顶级程序员的采访，总共600页。从采访的模式看，有点像“艺术人生”，一般都是音乐起，讲小时候的故事，你怎么开始写程序的? (Brad 同学 5 岁开始写) ；不过后来并没有神秘嘉宾上场，也没有声泪俱下的宣泄。无论如何，这些看似冗长的问答中有不少精辟的言论。我摘录了一些关于挑选，面试程序员，优秀程序员的特点，和程序设计的句子。下面是前6个程序员的心得，和我的几句解释：

Coder

What they say about good programmer, interview, and design

My interpretation

Jamie Zawinski,

LISP hacker,

early Netscape developer,

nightclub owner

Stay away from big fan of C++ templates;

Ability to argue their point is important.

Curiosity is a key skill for programmers.

There are people graduating with CS degrees who’d never written C. They started in java and they stayed there. That just seemed bizarre and wrong.

不喜欢过度崇拜C++ 模板的程序员；

程序员的表达能力，说服能力好奇心很重要；

很多学生拿到了CS 学位，但是从来没写过C 程序，他们学了Java，仅此而已。这是非常奇怪和不对的。

Brad Fitzpatrick

creator of memcached, Perlbal, MogileFS.

interview question:

Write a class to do arbitrary, bigint manipulation with multiplication and division

写一个大数的类，可以做乘除法。

Douglas Crockford

creator of JSON

Good Programmer:

They have to read Knuth (TAOCP); they are really literate in whatever language they write to other humans.

I invite the candidate to bring in a piece of code he’s really proud of and walk us thru it.

读过Knuth 的TAOCP;

有很强的文字表达能力和沟通能力。

请应聘者带自己最得意的代码来，给大家看看。

Brendan Eich,

Creator of JavaScript

hiring:

(rely on referral from team member)

Bright people like each other and can judge each other. I don’t give people puzzles to solve. We give them fairly practical problems, Not esoteric puzzles or math-y things.

(他有时通过同事的推荐来招人)

聪明的人会互相欣赏，评价。我不想通过智力题来判断程序员，我们给应聘者相当实际的问题，而不是那些奇怪的智力题或者数学题。

Joshua Bloch

Java Architect, author of “Effective Java”

About programming:

The older I get, the more I realize it isn’t just about making it work; it’s about producing an artifact that is readable, maintainable, and efficient. … it’s easier to optimized correct code than to correct optimized code.

“do you ever use UML as a design tool?”

No. I think it’s nice to be able to make diagrams that other people can understand. But honestly I can’t even remember which components are supposed to be round or square.

关于编程:

我越来越意识到写程序不是仅仅把程序写出来，而是要让你写的程序可读，可维护，并且高效。优化正确的程序要比改正已优化（但是有错）的程序要容易。

“你曾经用过UML 设计工具么?”

没有。能把设计画成图，让别人理解当然很好。但是说实话我记不起来哪些模块应该是圆形，哪些是方形。

Joe Armstrong

creator of Erlang, and OTP.

Interview question:

“what was the most fun project you ever wrote; show me the code for this stuff; how would you solve this problem?”

I’m not so hung up on what they know about language X or Y. they are either good at all languages or good at none.

You have to have a good memory to be a reasonable programmer.

面试问题:

“你写过的最好玩的项目是什么? 让我看看代码，你是怎么解决这个问题的?”

我并不一味要求他们已经知道某一两种语言。好的程序员精通一种语言后，就会触类旁通，能学好所有语言。

好记性对一个好程序员很重要。

一篇热帖的解剖

2009-11-24T15:49:52Z

上回提到《结婚相册》的快速流传，其实，不但是结婚相册，有时候网络上出现一篇似是而非，似非而是的热帖，大家就纷纷转贴，大家的朋友看了之后也热气上冲，继续转贴。。。

这篇博客 (http://blog.163.com/hawin2000@126/blog/static/390562922008109112019157/) 分析了一个题为美国兰德公司对中国人的评价的热帖，并指出，它是一篇学术文章(China and Globalization) 和一篇 BBS 帖子(最原始的出处已无此文，有好事者后来贴到了天涯) 的翻译，截肢，并强硬的嫁接。某好事者嫁接之后，给它起了一个抓人眼球的标题，于是此文名声大振，可以想象 - 美国公司，智囊，对咱中国人的评价，赶紧看看。。。真正的学术文章倒是默默无闻地在兰德公司的网站上呆着。

<tipping point / 爆破点> 这本书提到了影响事物流行的诸多因素，在中国的网络里，一个好题目 (某国人对中国人的评论，某地人如何如何)， “过激言论”(例如痛斥贵国的教育) 都能极大加快流行的速度。

偶尔看到这篇帖子和它的解剖，随手记下来。

《我和他的结婚录像和相册集》的快速传播

2009-11-21T07:08:05Z

当你看到你的一个朋友的 Live Space 有了这个更新，你当然想看.

但是你是点击文字 “我和他的结婚录像和相册集”，还是旁边的 "心形图标"?

很多人，包括我，都点击了"心形图标", 不幸的是，这样就会把这个相册集加入你自己的收集中，然后你的朋友就会看到你的更新：

他们当然很好奇，这哥们不是还没结婚么，怎么和“他”都结婚了还有录像和相册集? 他们可以点击文字，也可以点击 "心形图标"...

于是，在下一个24小时内，更多的朋友，朋友的朋友都不自觉地参与了传播过程，这可能不是当初用户界面设计师希望的。

无独有偶，我们自己的旅游指南有这个问题：

作为一个用户，如果你想进一步了解 “亚龙湾”的情况，你是点击文字呢，还是图片? 这两个看似相似的点击有截然不同的后果。我们在强迫用户想 - 如果我要做这件事，就按图片，如果我要做那件事，就按文字。一个旅游网站，有必要搞得这么复杂么? 拜托， don't make me think!

作为一个附加题，当用户点击 “沙滩”，“潜水”等词汇时，用户期待什么结果，而我们的网站又返回了什么结果呢?

很早以前，我也写过类似的问题。

第二届C++技术大会@ 上海 - 我觉得可以去看看

2009-11-05T06:53:25Z

[转发的宣传]

大会官方网站www.china-cpp.org。

作为软件开发语言的翘楚，C++对于现代软件的发展功不可没，特别是在系统软件开发领域，C++扮演着关键的角色。中国作为全球软件产业最具潜力的市场，越来越多的企业认识到了C++及相关系统软件技术在软件产业中举足轻重的作用。

为了推动C++及相关系统软件技术在国内的深度应用与发展，提升国内IT企业的研发水平，第二届C++技术大会定于2009年12月3日-4日在上海隆重召开。届时，来自海内外C++技术领域的近20位著名技术专家将就C++及相关系统软件开发技术的热点应用和最新发展，分享技术观点、探讨最佳研发实践。

此次大会开设的主题演讲互动讨论近20场，内容涉及大规模软件开发、程序优化、安全编程、面向对象、泛型编程、网络与服务端开发、多核与并发等多个主题。

大会时间

2009年12月03日-04日

大会地点

上海诺宝中心大酒店上海闵行区漕宝路1688号

大会议题

编号	议题
1	大规模软件开发 Large-Scale Software Development
2	程序优化 Programming Optimization
3	安全编程 Secure Programming

4	面向对象开发 Object-Oriented Development
5	泛型编程与设计 Generic Programming
6	网络与服务端开发Network & Server-Side Development
7	多核与并发编程 Multicore Parallel Programming
8	工具与应用Tools & Applications

参会人员

本届C++技术大会主要面向以下软件开发专业人士：首席技术官（CTO）、研发总监、项目经理、开发主管、系统软件开发工程师等与C++及相关系统软件开发密切相关的专业技术人员。丰富的技术讲演，专业的主题设计、经典的应用案例，软件开发相关专业人士可从大会获得C++及系统软件技术发展的趋势与热点应用，与业界顶尖专家多方位的交流机会。

演讲嘉宾

Stan Lippman
Stan Lippman是全世界公认的C++技术领袖。Stan Lippman先生从1984年开始在Bell实验室从事C++方面的工作。参与开发最初的C++编译器，致力于Cfront的各种实现，包括从1986年的版本1.1到版本3.0，并领导了2.1和3.0版本的开发组。而后又参与了Foundation研究项目中关于程序设计环境的对象模型部分。Stan Lippman先生还曾历任迪士尼动画公司的首席软件设计师、美国宇航局喷气推进实验室(JPL)的著名顾问、微软公司Visual C++开发组系统架构师。Stan Lippman先生撰写了数本享誉全球的经典书籍，包括《C++ Primer》、《Inside the C++ Object Model》、《Essential C++》、《C# Primer》，并编辑了《C++ Gems Programming Pearls from The C++ Report》。

侯捷
侯捷先生是两岸著名技术教育者，计算机图书作者、译者、书评人。著有《深入浅出MFC》、《多型与虚拟》、《STL源码剖析》、《无责任书评》三卷，译有众多脍炙人口的高阶技术书籍，包括Meyers所著的“Effective C++”系列。侯捷先生还兼任教职于元智大学（台湾）、同济大学（大陆）、南京大学（大陆）。

还有很多厉害人物，见官网介绍。

[zz] 钱学森谈大学创新精神

2009-11-04T22:08:52Z

转贴，并请抄送周济，贵仁同志。

http://www.chinanews.com.cn/gn/news/2009/11-05/1947844.shtml

...

我是在上个世纪30年代去美国的，开始在麻省理工学院学习。麻省理工学院在当时也算是鼎鼎大名了，但我觉得没什么，一年就把硕士学位拿下了，成绩还拔尖。其实这一年并没学到什么创新的东西，很一般化。后来我转到加州理工学院，一下子就感觉到它和麻省理工学院很不一样，创新的学风弥漫在整个校园，可以说，整个学校的一个精神就是创新。在这里，你必须想别人没有想到的东西，说别人没有说过的话。拔尖的人才很多，我得和他们竞赛，才能跑在前沿。这里的创新还不能是一般的，迈小步可不行，你很快就会被别人超过。你所想的、做的，要比别人高出一大截才行。那里的学术气氛非常浓厚，学术讨论会十分活跃，互相启发，互相促进。我们现在倒好，一些技术和学术讨论会还互相保密，互相封锁，这不是发展科学的学风。你真的有本事，就不怕别人赶上来。我记得在一次学术讨论会上，我的老师冯·卡门讲了一个非常好的学术思想，美国人叫“good idea”，这在科学工作中是很重要的。有没有创新，首先就取决于你有没有一个“good idea”。所以马上就有人说：“卡门教授，你把这么好的思想都讲出来了，就不怕别人超过你？”卡门说：“我不怕，等他赶上我这个想法，我又跑到前面老远去了。”所以我到加州理工学院，一下子脑子就开了窍，以前从来没想到的事，这里全讲到了，讲的内容都是科学发展最前沿的东西，让我大开眼界。

我本来是航空系的研究生，我的老师鼓励我学习各种有用的知识。我到物理系去听课，讲的是物理学的前沿，原子、原子核理论、核技术，连原子弹都提到了。生物系有摩根这个大权威，讲遗传学，我们中国的遗传学家谈家桢就是摩根的学生。化学系的课我也去听，化学系主任L·鲍林讲结构化学，也是化学的前沿。他在结构化学上的工作还获得诺贝尔化学奖。以前我们科学院的院长卢嘉锡就在加州理工学院化学系进修过。L·鲍林对于我这个航空系的研究生去听他的课、参加化学系的学术讨论会，一点也不排斥。他比我大十几岁，我们后来成为好朋友。他晚年主张服用大剂量维生素的思想遭到生物医学界的普遍反对，但他仍坚持自己的观点，甚至和整个医学界辩论不止。他自己就每天服用大剂量维生素，活到93岁。加州理工学院就有许多这样的大师、这样的怪人，决不随大流，敢于想别人不敢想的，做别人不敢做的。大家都说好的东西，在他看来很一般，没什么。没有这种精神，怎么会有创新！

加州理工学院给这些学者、教授们，也给年轻的学生、研究生们提供了充分的学术权力和民主氛围。不同的学派、不同的学术观点都可以充分发表。学生们也可以充分发表自己的不同学术见解，可以向权威们挑战。过去我曾讲过我在加州理工学院当研究生时和一些权威辩论的情况，其实这在加州理工学院是很平常的事。那时，我们这些搞应用力学的，就是用数学计算来解决工程上的复杂问题。所以人家又管我们叫应用数学家。可是数学系的那些搞纯粹数学的人偏偏瞧不起我们这些搞工程数学的。两个学派常常在一起辩论。有一次，数学系的权威在学校布告栏里贴出了一个海报，说他在什么时间什么地点讲理论数学，欢迎大家去听讲。我的老师冯·卡门一看，也马上贴出一个海报，说在同一时间他在什么地方讲工程数学，也欢迎大家去听。结果两个讲座都大受欢迎。这就是加州理工学院的学术风气，民主而又活跃。我们这些年轻人在这里学习真是大受教益，大开眼界。今天我们有哪一所大学能做到这样？大家见面都是客客气气，学术讨论活跃不起来。这怎么能够培养创新人才？更不用说大师级人才了。

...

AgileChina 2009 / 敏捷中国感想 (3)

2009-10-11T15:23:06Z

Fred George

演讲题目: it's a bird? it's a plane? no, it's superman

Fred 演讲完之后，我和他聊了好一会，请教了好几个问题，下面是我的笔记和感想:

1) 不必用很高深的工具和复杂的报表，白板/Cardboard 成为了敏捷流程中简单而有效的项目管理工具. 团队成员使用简单的便签条来显示他们工作的进度。

Fred 推荐了两本书 "the soul of a new machine" & "guns, germs, and steel"

项目管理人员如何成为项目的拖累 - 这帮人不断地问 "你做得怎么样了?" 记下别人的进度 (或者要求别人写每日每周进度) 然后向上汇总。这些最大的汇总最后有人真正关心么?

如果程序员不断地在多个项目中来回折腾，像CPU 不断执行各个进程一样，那这样的 context switch 会导致时间的浪费。建议程序员最好专注于一个故事/场景. 避免 multi-tasking. 有时候，光从 excel 表格中看不出来 multi-tasking 导致的浪费 - 可以说你被Spreadsheet 骗了。

问: 关于结对编程，如果大部分团队中的成员都是新手，怎么办?

答：避免让刚上路的新手之间结对，让成熟的程序员带领他们，等他们成长起来之后，再结对。

问: 如果每个模块都是两人结对劳动的成果，你如何衡量单个人的绩效呢?

答：没关系，结对的两个伙伴可以互相衡量对方. 如果项目时间足够长，每个人都会和足够多的同事合作过，会有足够多的评价信息。

问: 我们每个员工都有自己的小隔间/cubicles, 而结对编程需要大家坐在一起，我们还需要另外的 "working zone" 空间让不同的人能坐在一起结对编程，这样岂不是比较浪费空间?

答: 团队的效率比空间更重要, 我认为让合作的同事们并肩作战是提高效率的第一步。当经过几次磨合，人们开始习惯和享受在 "working zone" 中编程时, 他们在自己的隔间中花的时间会很少，我们可以让隔间/cubicle 变得更小，减少空间的浪费。

问: 在项目管理中，每个任务 (工作项/work item) 有大有小，但是在报表中他们都是一个同样的数字，这样看起来报表会欺骗读者，你怎么样避免这一问题，让报表如实反映真实情况?

答: 把巨大的任务分成小的子任务，项目经理应该负责这样的事情, 估计子任务所需时间，通常会让人头痛，但是在我的经验中，这件事可以很快进行 - 相关人员像划拳一样，同时出手，比划任务大小，如果达到一致，则进行下一个.

问: 看起来你希望大家很快估计出任务的长度，然后开始工作。但是如果估计错了怎么办? 我们难道不要花很多时间仔细估计任务的花销么? (还有一本书 Software Estimation 把估计工作上升到了 Black Art 的地步)

答: 我希望不要过分强调 “估计”的价值，因为它就是一个“猜”字。 “猜得准”不是我们的目标。我们的目标是把软件写出来。如果猜错了，没关系，微调项目进度即可，不希望看到大家为了“猜得准” 而踌躇不前. 或者为了让当初的猜测看起来更靠谱而不如实报告进度。

问: 在你的演讲中我看到一个报表是显示 “waiting time/等待的时间”，怎么在项目中自动地做到这一点 (而不是人工去问) ?

答: 在我的项目中，我有专门的流程和状态表示“等待”这一状态, 一个任务并不会自动跳过上一个状态而进入下一个人手上 - 要等到这个人有时间处理才行。敏捷方法并不是一味地简化流程，或者消灭流程，我希望敏捷的流程能加入精确表达任务状态的各种字段和表现形式。

问: 在我们项目的实际中，很多情况下，大家不敢让图表如实反映情况 - 那样会让人觉得 “你们并没有把项目管理好”。所以很多burndown chart 看起来是一条完美的对角直线，而实际上并非如此。

答: 报表的目的是为了如实反映项目的进展，对老板，客户，利益相关者(stake holder) 都是如此。如果你的报表能显示项目中很多 “等待” 的状态是由于测试人员不够所造成的，那么你的老板会非常乐意替你解决这个问题。如果你把问题都隐藏起来了，给别人看的是完美的对角线，那别人会认为你的项目不需要任何帮助，这对团队就更不利了.

---------------------------------------------

注：这是参加 AgileChina 2009 大会的感想，大会的情况如下:

AgileChina 2009大会报道与评论集锦：

http://www.infoq.com/cn/agile

大会现场图片集锦：

http://www.flickr.com/groups/agilechina2009

演讲资料下载：

- 敏捷大会所有演讲PPT下载：http://bit.ly/agilechina2009
- Kent Beck名师讲堂PPT下载：http://bit.ly/KBtraining

---------------------------------------------

感想(1) (2) (3)

AgileChina 2009 / 敏捷中国感想 (2)

2009-10-11T06:39:22Z

David Thomas, Author of “the pragmatic programmer” (English and Chinese)

Title of speech: Pragmatic Agile (实用的敏捷)

怎样才是 "Pragmatic":

Do what works. (if it doesn't work, stop doing it).
Working at what to do (focus)

个人笔记:

1) 过时了?

这本书(程序员修炼之道) 已经出版10年了, 10 年间软件产业的变化，几乎可以和别的产业100 年相比。那么这本书变老了么? 过时了么.

有一些细节的确过时了，软件工具变得更成熟，可以替代不少手工；更多的人在使用动态语言编程，等等. 但是，基本的想法还是没有过时。例如：“破窗理论”, 很多人还在说： “我以后会处理那些小问题的”，但是“以后”什么时候来呢? 你总有更多重要的事情在等你。也许没有“以后”，也许，已没有也许。

2) DRY 原则 - "Don't Repeat Yourself".

所有能够被表达的概念都应该有一个并只有一个地方来表达。

设计模式 - 设计模式很有用，David 认为这个概念已经被用得太多，太滥。设计的目的之一是避免重复，但是我们有很多重复的模式在代码中大量出现，这是好事么? 这违反了DRY 原则. 应该避免重复，保持松耦合，让代码做好一件事。这样才能方便地修改和演化代码。

3) 敏捷需要一个执行者

"敏捷/agile" 是一个形容词/副词，不是一个东西，它修饰的是我们做事情的方式，不是这事情本身。所以“敏捷”需要一个动作，和一个动作的执行者。光说“我们敏捷”是没有用的。同样，敏捷/Agile 也不是一个 “拷贝/粘贴”的东西.

对于很多与会者称David 及其他讲师是 "敏捷大师/agile masters"。他不以为然地说 “我们不是大师，我们不过是把你们还没有犯的错误都经历过了，我们现在把这些经验分享出来，可能会帮助后来者少犯错误，节约时间".

4) 单元测试

单元测试也是一个好事，但是好多人也做得过头了，太注重单元测试，单元测试成为了目标 - 这是错误的。写代码的目标是“满足用户的需求”，而不是“满足所有单元测试”。 (我的理解) 如果单元测试能百分之百地表达用户的需求，这两者就可以统一，但是如果有人能写 “百分之百地表达用户的需求的单元测试”，这些人干脆直接写软件算了。

5) 敏捷方法的真正好处

问题: 我想敏捷，但是项目的期限不动；敏捷能帮我早日完成任务?

回答: 敏捷不是万能。敏捷的方法能帮助你更早地知道你是否能如期完成任务。仅此而已。 敏捷的方法（迭代的方式）能帮你尽快让用户看到项目的（部分）价值。当你尽早交付（部分）价值的时候，也许用户对你目前交付的东西已经很满意了，这样你就不用再花时间来实现其他计划中的事情。另一种可能是，用户看到了（部分）系统，他们对整个需求有了新的认识，这样你就可以实现他们新的需求，而不用再浪费时间.

---------------------------------------------

注：这是参加 AgileChina 2009 大会的感想，大会的情况如下:

AgileChina 2009大会报道与评论集锦：

http://www.infoq.com/cn/agile

大会现场图片集锦：

http://www.flickr.com/groups/agilechina2009

演讲资料下载：

- 敏捷大会所有演讲PPT下载：http://bit.ly/agilechina2009
- Kent Beck名师讲堂PPT下载：http://bit.ly/KBtraining

---------------------------------------------

感想(1) (2) (3)

AgileChina / 敏捷中国感想 (1)

2009-10-08T13:11:12Z

Kent Beck (one of the founders of XP movement)

演讲题目: Pragmatic Idealism (summary of his talk)

我的理解: 我们必须同时具备理想主义和实用主义的心态，才能让项目取得最大限度的成功。敏捷的流程正可以帮助我们取得二者的平衡。

其他感想:

1) 愿望，决心和行动

大部分人都希望项目敏捷，然而敏捷是有成本的，他们有相应的决心和行动么? 能支付相应的成本么? 例如，前来开会学习的成本? 如果你都不敢问自己的老板，能否花两天时间来参加会议。那良好的愿望也不过是说说而已。

2) 借口，形式和教义

有些时候，敏捷成了一个借口，例如 - “ 我们的项目没有仔细计划就开始了，因为我们敏捷，所以这是没有问题的”。

有些时候，敏捷被人误认为只不过是某种形式，例如 - 他们每天早上都报告自己的状态，听说那就是敏捷的"史可郎"会，我们也这样搞，不就敏捷了?

更多时候，人们忽略了大小写 - "we follow an agile process" 一般指团队的流程比较灵活。 "we follow the Agile process" 指按照官方敏捷流程的教义开展工作。当实事求是的做法和教条发生了冲突，你怎么办呢?

3) 专注，真诚，说到做到

光是教义不能写出好软件，好软件需要人专注工作，才能写出来。有一些很实用的招数 (避免被杂事打断, 避免同时进行多个项目, 避免其他随机任务，等等). 这些招数在“实用”的同时，也让人更接近了“理想状态”。

"真诚" 这个词听起来更适合于谈恋爱的场景。不过Kent 同学说的是这个意思 - We need to do what we say we’re going to do.

比如，在一个Sprint 的过程中，不允许外界改动工作内容。这个原则应该坚持。又比如，员工不应该同时在多个项目中疲于奔命，但是有时各种需求太多，人们不好意思说 "no", 只好敷衍下来，结果自己很累，需求方也不满意 - 既不满足实用主义，也和理想渐行渐远。

---------------------------------------------

注：这是参加 AgileChina 2009 大会的感想，大会的情况如下:

AgileChina 2009大会报道与评论集锦：

http://www.infoq.com/cn/agile

大会现场图片集锦：

http://www.flickr.com/groups/agilechina2009

演讲资料下载：

- 敏捷大会所有演讲PPT下载：http://bit.ly/agilechina2009
- Kent Beck名师讲堂PPT下载：http://bit.ly/KBtraining

关心

THU – team players 合作精神

THU - 清华大学 现代软件工程 成绩统计

编程之美 - 哪个题目最美?

顶级程序员的心得 Coders at Work (IV)

顶级程序员的心得 Coders at Work (III)

顶级程序员的心得 Coders at Work (II)

顶级程序员的心得 Coders at Work (I)

一篇热帖的解剖

《我和他的结婚录像和相册集》的快速传播

最近到手的一些书

第二届C++技术大会@ 上海 - 我觉得可以去看看

[zz] 钱学森谈 大学 创新精神

AgileChina 2009 / 敏捷中国 感想 (3)

AgileChina 2009 / 敏捷中国 感想 (2)

AgileChina / 敏捷中国 感想 (1)

THU - 清华大学现代软件工程成绩统计

[zz] 钱学森谈大学创新精神

AgileChina 2009 / 敏捷中国感想 (3)

AgileChina 2009 / 敏捷中国感想 (2)

AgileChina / 敏捷中国感想 (1)