頂級(jí)程序員的心得–Coders at Work
[原文在 www.yishan.cc 連載, 現(xiàn)在合成一篇]
我去年讀了 “Coders at Work”, 對(duì)15 位頂級(jí)程序員的采訪， 總共600頁。 從采訪的模式看，有點(diǎn)像“藝術(shù)人生”， 一般都是音樂起，講小時(shí)候的故事，你怎么開始寫程序的? (Brad 同學(xué) 5 歲開始寫) ； 不過后來并沒有神秘嘉賓上場，也沒有聲淚俱下的宣泄。 無論如何， 這些看似冗長的問答中有不少精辟的言論。 我摘錄了一些關(guān)于挑選，面試程序員，優(yōu)秀程序員的特點(diǎn)，和程序設(shè)計(jì)的句子。下面是這些程序員的心得，和我的幾句解釋：
| Coder
| What they say about good programmer, interview, and design
| My interpretation
|
|
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++ 模板的程序員；
程序員的表達(dá)能力，說服能力好奇心很重要；
很多學(xué)生拿到了CS 學(xué)位，但是從來沒寫過C 程序，他們學(xué)了Java，僅此而已。 這是非常奇怪和不對(duì)的。
|
| creator of memcached, Perlbal, MogileFS.
| interview question: Write a class to do arbitrary, bigint manipulation with multiplication and division
| 寫一個(gè)大數(shù)的類，可以做乘除法。
|
|
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;
有很強(qiáng)的文字表達(dá)能力和溝通能力。
請(qǐng)應(yīng)聘者帶自己最得意的代碼來，給大家看看。
|
| 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.
| (他有時(shí)通過同事的推薦來招人)
聰明的人會(huì)互相欣賞，評(píng)價(jià)。 我不想通過智力題來判斷程序員，我們給應(yīng)聘者相當(dāng)實(shí)際的問題，而不是那些奇怪的智力題或者數(shù)學(xué)題。
|
| 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.
| 關(guān)于編程:
我越來越意識(shí)到寫程序不是僅僅把程序?qū)懗鰜恚且屇銓懙某绦蚩勺x，可維護(hù)，并且高效。 優(yōu)化正確的程序要比改正已優(yōu)化（但是有錯(cuò)）的程序要容易。
“你曾經(jīng)用過UML 設(shè)計(jì)工具么?”
沒有。 能把設(shè)計(jì)畫成圖，讓別人理解當(dāng)然很好。 但是說實(shí)話我記不起來哪些模塊應(yīng)該是圓形，哪些是方形。
|
| 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.
| 面試問題:
“你寫過的最好玩的項(xiàng)目是什么? 讓我看看代碼， 你是怎么解決這個(gè)問題的?”
我并不一味要求他們已經(jīng)知道某一兩種語言。 好的程序員精通一種語言后，就會(huì)觸類旁通，能學(xué)好所有語言。
好記性對(duì)一個(gè)好程序員很重要。 |
| Coder
| What they say about good programmer, interview, and design
| My interpretation
|
|
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 “l(fā)ooking 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 樹, 光看代碼你不懂為什么這些子樹要轉(zhuǎn)來轉(zhuǎn)去。但是如果你理解了它的核心思想，看到它維護(hù)了這個(gè)不變量 (invariant) 從而保證 log 級(jí)的訪問速度，你就會(huì)說，”啊，明顯理當(dāng)如此。”
|
|
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.
| 學(xué)校教育:
應(yīng)該教更多的團(tuán)隊(duì)合作，“我上學(xué)的時(shí)候，團(tuán)隊(duì)合作被認(rèn)為是作弊” (現(xiàn)在有些學(xué)校還是這樣)。
成功的程序員:
他們有勇氣和意愿 “開始干”。 “我只要懂得我需要的，就可以開始干活了”， 而不是“我得完全理解某個(gè)領(lǐng)域，才能開始”。
面試: 不喜歡用智力題目，要依賴于面對(duì)面的問答來判斷這個(gè)應(yīng)聘者是否能夠和團(tuán)隊(duì)合得來，更重要的是，讓他們?cè)诤诎迳蠈懘a，看看他們是否真的能“說到做到”。
XP, 結(jié)對(duì)編程: 10% 的時(shí)間用來交流是很重要的，但是如果大部分時(shí)間都用來結(jié)對(duì)，那效率不會(huì)太高。
UML: 我從來不喜歡這類工具，如果你不能在計(jì)算機(jī)語言中表達(dá)(UML 要表達(dá)的東西)， 那這是這種語言的弱點(diǎn)。
|
|
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.
| 代碼:
當(dāng)你寫代碼的時(shí)候，你寫給機(jī)器看，同時(shí)也寫給人看。
如果效率很重要，我會(huì)用一些小技巧。 這些技巧會(huì)誤導(dǎo)讀代碼的人，你得加上注釋，或者類似的東西標(biāo)注一下，讓它更可讀。
|
Peter Norvig 同學(xué)在NASA 工作的時(shí)候，參與了NASA 的一個(gè)著名事故的調(diào)查 ( 1999 年“火星氣候衛(wèi)星” 因?qū)Ш匠霈F(xiàn)重大錯(cuò)誤而墜入火星大氣層)。 從他在這本書的問答中，我們可以看到一個(gè)大略的錯(cuò)誤發(fā)生過程:
1) 軟件外包公司對(duì)于 mission-critical 的軟件模塊有很完備的檢查和測試，但是對(duì)于其他模塊則沒有完備的管理。
2) 程序員寫了一個(gè)不重要的log 功能，其中用英制 (磅* 英尺) 表示力, 但是 NASA 用“牛頓”= 千克*米/(秒*秒)
3) 外包公司接到一個(gè)新的工程，他們進(jìn)行了軟件重用，log 功能中記錄的力被重用為導(dǎo)航功能的輸入?yún)?shù)，成為 mission-critical 的模塊。
//錯(cuò)誤: 一個(gè)模塊從 non-mission-critical 變成 mission-critical 沒有經(jīng)歷必要的復(fù)審和測試。
4) 這個(gè)新的工程由發(fā)包公司 Lockheed (洛克希德公司) 交給了客戶 JPL (噴氣推進(jìn)實(shí)驗(yàn)室)
5) 火箭帶著衛(wèi)星發(fā)射了，在10個(gè)月的飛行中，JPL 可以每天兩次啟動(dòng)小推進(jìn)器，來調(diào)整太空船的航向，在這一過程中，有人發(fā)現(xiàn)了導(dǎo)航功能的一些不正常現(xiàn)象, 于是 -
a. JPL 發(fā)郵件給 Lockheed, 說 – 這個(gè)模塊有些參數(shù)看起來好像不正常…
b. Lockheed 回郵件…
c. JPL 再發(fā)郵件…
d. 最后沒有人再發(fā)郵件了
后來, JPL的同志認(rèn)為， Lockheed 的同志們估計(jì)已經(jīng)搞定了。 Lockheed 的同志認(rèn)為， JPL 的同志們沒再追問這個(gè)問題，可能已經(jīng)不是問題了。
錯(cuò)誤: 這個(gè)問題從來沒有收錄到NASA 的錯(cuò)誤跟蹤系統(tǒng) (Bug tracking system)，只是在email 中交流，導(dǎo)致最后沒有人對(duì)這個(gè)問題負(fù)責(zé)。在錯(cuò)誤跟蹤系統(tǒng)中，總得有一個(gè)人“擁有”這一個(gè)bug，這樣可以避免推諉責(zé)任。 (MSF 也很重視這一點(diǎn))
十個(gè)月之后， 1999年9月23 日，衛(wèi)星抵達(dá)火星大氣層，錯(cuò)誤的導(dǎo)航參數(shù)造成衛(wèi)星墜入大氣層燒毀。 單單衛(wèi)星的造價(jià)就高達(dá)一億兩千五百萬美元。
| Coder
| What they say about good programmer, interview, and design
| My interpretation
|
|
Guru of Smalltalk; inventor of BitBlt operation, working on Lively Kernel 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.
| 技術(shù)帶頭人: 1) 清楚的遠(yuǎn)景。沒有清楚的遠(yuǎn)景，只有強(qiáng)大技術(shù)能力的團(tuán)隊(duì)，就像盲人騎瞎馬，還使勁用鞭子抽打，讓馬快跑。 看起來一度非常拉風(fēng)，但后來免不了人仰馬翻。 2）信任團(tuán)隊(duì)，把大方向弄清楚之后，把其他事情交給團(tuán)隊(duì)成員去搞清楚。 如果帶頭人詳細(xì)規(guī)定了所有細(xì)節(jié)，那么團(tuán)隊(duì)成員干得還有什么勁呢？ 3）避免“微觀管理”。當(dāng)你擔(dān)心或者沒有安全感的時(shí)候，你當(dāng)然會(huì)希望把所有細(xì)節(jié)都搞清楚，但是這樣反而會(huì)出亂子。
|
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 internet was inherently uncontrollable, and I no longer think that. China shows that you can do it pretty effectively. | 優(yōu)秀程序員： 直覺。 但是Peter 說的不是運(yùn)氣，而是長期實(shí)踐之后成為你思維一部分的東西 - 你不知道推理這些東西出來，正如同你不知道如何推理出直覺。 Peter 認(rèn)為優(yōu)秀的程序員必須能在抽象思維 (world of symbols) 中得心應(yīng)手的人。 程序員 vs. 碼農(nóng): Peter 認(rèn)為Coder 把程序員的工作定義得太狹隘了。 就像IT 民工，翻沙，砌墻。 砌墻并不是一個(gè)壞工作，但這只是“建筑”這一過程中的一個(gè)小部分。 "軟件開發(fā)者" 應(yīng)該是一個(gè)好名稱， 雖然并不全面。 所謂 "計(jì)算機(jī)科學(xué)" 不過是工程加上應(yīng)用數(shù)學(xué)。 我原以為互聯(lián)網(wǎng)是根本上無法控制的。。。 |
| 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. | 優(yōu)秀程序員的特點(diǎn): 就是“熱情”， 我們有時(shí)也說 "passion for technology". 但是在面試的時(shí)候你不能問 - 你對(duì)計(jì)算機(jī)技術(shù)有熱情么? 因?yàn)樗谢卮鸲际?yes。 你要在場景中， 對(duì)話中感覺對(duì)方的“熱情”。 如果一個(gè)念了5-7年計(jì)算機(jī)專業(yè)的人，不能 “兩眼放光”地給你講他自己最得意，最激動(dòng)人心的項(xiàng)目或算法，不能回答你的深入提問，除了老師的作業(yè)和實(shí)驗(yàn)室老板叫做的項(xiàng)目之外，沒有別的想法。 你覺得這種人有多少 “熱情”? Ken 還表達(dá)了自己對(duì)C++ 的意見，幾乎所有這本書采訪的牛人都不太喜歡C++， 很有意思，不過這是另外一個(gè)話題了。 |
| Coder
| What they say about good programmer, interview, and design
| My interpretation
|
|
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. |
軟件流程:
因?yàn)镮BM/360 項(xiàng)目的軟件部分遇到了很大的困難，那時(shí)候還沒有什么成文的 "軟件工程"， Fred Brooks 把管硬件的經(jīng)理們調(diào)來，讓他們來管軟件部門， 因?yàn)橛布且粋€(gè)相對(duì)成熟的產(chǎn)業(yè) - 芯片設(shè)計(jì)，測試，等等。 這些“不懂軟件”的同志們參考硬件產(chǎn)業(yè)， 建立了軟件工程的基本流程。
從一個(gè)成熟的產(chǎn)業(yè)中學(xué)習(xí)，是很有效的辦法。 現(xiàn)在我們還可以從軟件工程的一些術(shù)語中看到硬件的影子 - 例如 smoke test 冒煙測試。
好的程序員: 熱情 (前面 Ken 同學(xué)也談到了這一點(diǎn)) |
| 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.
|
給程序員的建議: 寫很多程序。 世界上難的問題/程序很少， 如果一個(gè)人的代碼看起來很難，這通常意味著程序員沒有想清楚。 如果你必須用很復(fù)雜的代碼，把它包裝起來。 程序是用來給人讀的。 避免過早優(yōu)化。 優(yōu)秀程序員:
應(yīng)聘者有沒有刨根問底，好奇心, 準(zhǔn)確的思維? 能快速地學(xué)習(xí)么? 是否對(duì)很多東西都有興趣? 是否有很廣泛的基礎(chǔ)? [仔細(xì)挑選的] 智力題能讓你看到應(yīng)聘者是如何組織材料，解決問題的。 |
|
Donald Knuth (高德納) TAOCP, TeX and METAFONT, literate programming
|
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.
|
... |
[由于在csdn 寫博客碰到一些不能解決的問題, 我決定把博客搬到 http://www.rzrgm.cn/xinz/ ]
我們新一代的學(xué)生, 以后會(huì)不會(huì)也出現(xiàn)一些這樣的牛人呢? 我相信群眾。
浙公網(wǎng)安備 33010602011771號(hào)