顶级程序员的心得 Coders at Work (II)
正在讀 “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? 可以每天兩次啟動小推進器，來調整太空船的航向，在這一過程中，有人發現了導航功能的一些不正?，F象, 于是 -
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 (II)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 博客写作在App
- 下一篇： first review of team