顶级程序员的心得.docx
《顶级程序员的心得.docx》由会员分享，可在线阅读，更多相关《顶级程序员的心得.docx（11页珍藏版）》请在冰豆网上搜索。
顶级程序员的心得
顶级程序员的心得-CodersatWork收藏
此文于2010-12-01被推荐到CSDN首页
如何被推荐？
[原文在www.yishan.cc连载, 现在合成一篇]
读了“CodersatWork”, 对15位顶级程序员的采访，总共600页。
从采访的模式看，有点像“艺术人生”，一般都是音乐起，讲小时候的故事，你怎么开始写程序的?
（Brad同学5岁开始写）；不过后来并没有神秘嘉宾上场，也没有声泪俱下的宣泄。
无论如何，这些看似冗长的问答中有不少精辟的言论。
我摘录了一些关于挑选，面试程序员，优秀程序员的特点，和程序设计的句子。
下面是这些程序员的心得，和我的几句解释：
Coder
Whattheysayaboutgoodprogrammer,interview,anddesign
Myinterpretation
JamieZawinski,
LISPhacker,
earlyNetscapedeveloper,
nightclubowner
StayawayfrombigfanofC++templates;
Abilitytoarguetheirpointisimportant.
Curiosityisakeyskillforprogrammers.
TherearepeoplegraduatingwithCSdegreeswho’dneverwrittenC.Theystartedinjavaandtheystayedthere. Thatjustseemedbizarreandwrong.
不喜欢过度崇拜C++模板的程序员；
程序员的表达能力，说服能力好奇心很重要；
很多学生拿到了CS学位，但是从来没写过C程序，他们学了Java，仅此而已。
这是非常奇怪和不对的。
BradFitzpatrick
creatorofmemcached,Perlbal,MogileFS.
interviewquestion:
Writeaclasstodoarbitrary,bigintmanipulationwithmultiplicationanddivision
写一个大数的类，可以做乘除法。
DouglasCrockford
creatorofJSON
GoodProgrammer:
TheyhavetoreadKnuth（TAOCP）; theyarereallyliterateinwhateverlanguagetheywritetootherhumans.
Iinvitethecandidatetobringinapieceofcodehe’sreallyproudofandwalkusthruit.
读过Knuth的TAOCP;
有很强的文字表达能力和沟通能力。
请应聘者带自己最得意的代码来，给大家看看。
BrendanEich,
CreatorofJavaScript
hiring:
（relyonreferralfromteammember）
Brightpeoplelikeeachotherandcanjudgeeachother. Idon’tgivepeoplepuzzlestosolve. Wegivethemfairlypracticalproblems,Notesotericpuzzlesormath-ythings.
（他有时通过同事的推荐来招人）
聪明的人会互相欣赏，评价。
我不想通过智力题来判断程序员，我们给应聘者相当实际的问题，而不是那些奇怪的智力题或者数学题。
JoshuaBloch
JavaArchitect,authorof“EffectiveJava”
Aboutprogramming:
TheolderIget,themoreIrealizeitisn’tjustaboutmakingitwork;it’saboutproducinganartifactthatisreadable,maintainable,andefficient. … it’seasiertooptimizedcorrectcodethantocorrectoptimizedcode.
“doyoueveruseUMLasadesigntool?
”
No.Ithinkit’snicetobeabletomakediagramsthatotherpeoplecanunderstand. ButhonestlyIcan’tevenrememberwhichcomponentsaresupposedtoberoundorsquare.
关于编程:
我越来越意识到写程序不是仅仅把程序写出来，而是要让你写的程序可读，可维护，并且高效。
优化正确的程序要比改正已优化（但是有错）的程序要容易。
“你曾经用过UML设计工具么?
”
没有。
能把设计画成图，让别人理解当然很好。
但是说实话我记不起来哪些模块应该是圆形，哪些是方形。
JoeArmstrong
creatorofErlang,andOTP.
Interviewquestion:
“whatwasthemostfunprojectyoueverwrote;showmethecodeforthisstuff;howwouldyousolvethisproblem?
”
I’mnotsohunguponwhattheyknowaboutlanguageXorY. theyareeithergoodatalllanguagesorgoodatnone.
Youhavetohaveagoodmemorytobeareasonableprogrammer.
面试问题:
“你写过的最好玩的项目是什么?
让我看看代码，你是怎么解决这个问题的?
”
我并不一味要求他们已经知道某一两种语言。
好的程序员精通一种语言后，就会触类旁通，能学好所有语言。
好记性对一个好程序员很重要。
Coder
Whattheysayaboutgoodprogrammer,interview,anddesign
Myinterpretation
SimonPeytonJones
Haskellarchitect,MSR-Cambridgeresearcher
BeautifulCode:
agreeswithTonyHoarethatgoodcodeshouldobviouslyhavenobugs,ratherthanhavingnoobviousbugs. but“lookingatthebarecodemaynotbeenough, it’snotacharacteristicofbeautifulcodethatyoushouldbeabletojustlookatthebarecodeandseewhyit’sright. （AVLtreeisoneexample）
漂亮的代码:
像TonyHoare说的那样–它们明显没有bug;而不是没有明显的bug.
但是“漂亮”并不意味着看着源代码就能马上读懂。
例如AVL树,光看代码你不懂为什么这些子树要转来转去。
但是如果你理解了它的核心思想，看到它维护了这个不变量（invariant）从而保证log级的访问速度，你就会说，”啊，明显理当如此。
”
PeterNorvig
InchargeofResearchatGoogle, NASA.
MadefunofPowerPointAutoContentWizard
Advicetoschool:
Teachmoreonteamwork. “whenIwasinschool,workingasateamwascalledcheating”.
Successfulprogrammer:
Thebravadoandwillingnessto“goahead”withincompletebutessentialinfo.
Interview:
Idon’tlikethetrickpuzzlequestions. It’simportanttohavesomeonethatyoucangetalongwith. More, Cantheytechnicallydowhattheysaidtheycando?
Youreallywanttohavepeoplewritecodeontheboard.
XP,pairprogramming:
10%ofthetimeistoshareisimportant, butifdoingitmostofthetime,itwon’tbeaseffective.
UML:
IneverlikedanyoftheseUML-typeoftools. Ifyoucan’tdoitinthelanguageitselfthat’saweaknessofthelanguage.
学校教育:
应该教更多的团队合作，“我上学的时候，团队合作被认为是作弊”（现在有些学校还是这样）。
成功的程序员:
他们更多的是“我只要懂得我需要的，就可以开始干活了”，而不是“我得完全理解某个领域，才能开始”。
面试:
不喜欢用智力题目，要依赖于面对面的问答来判断这个应聘者是否能够和团队合得来，更重要的是，让他们在黑板上写代码，看看他们是否真的能“说到做到”。
XP,结对编程:
10%的时间用来交流是很重要的，但是如果大部分时间都用来结对，那效率不会太高。
UML:
我从来不喜欢这类工具，如果你不能在计算机语言中表达（UML要表达的东西），那这是这种语言的弱点。
GuySteele
HelpcreatedCommonLispandScheme,Emacs
Codewriting:
Whenyouarewritingcodeyou’rewritingasmuchforhumanreadersasforthecomputer.
Ifefficiencyisimportant,I’lloftenresorttoatrick.AndthenIrealizethatwillmisleadahuman. Andyouhavetocommentitordosomethingtoflagthat,tomakeitmorereadable.
代码:
当你写代码的时候，你写给机器看，同时也写给人看。
如果效率很重要，我会用一些小技巧。
这些技巧会误导读代码的人，你得加上注释，或者类似的东西标注一下，让它更可读。
PeterNorvig同学在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. 最后没有人再发邮件了
后来, JPL的同志认为，Lockheed的同志们估计已经搞定了。
Lockheed的同志认为，JPL的同志们没再追问这个问题，可能已经不是问题了。
错误:
这个问题从来没有收录到NASA的错误跟踪系统（Bugtrackingsystem），只是在email中交流，导致最后没有人对这个问题负责。
在错误跟踪系统中，总得有一个人“拥有”这一个bug，这样可以避免推诿责任。
（MSF也很重视这一点）
十个月之后，1999年9月23日，卫星抵达火星大气层，错误的导航参数造成卫星坠入大气层烧毁。
单单卫星的造价就高达一亿两千五百万美元。
Coder
Whattheysayaboutgoodprogrammer,interview,anddesign
Myinterpretation
DanIngalls
GuruofSmalltalk;inventorofBitBltoperation,workingonLivelyKernalnow.
Tipsonagoodtechnicalleader:
1）clearvision;
2）trustpeople; geteverythingfigureout,butleaveitopentoteammembertodoit.
3）avoidmicromanagement. ifyou’reworriedandyou’reinsecure,andsoyou’refeelinglikeyouhvetonaileverythingdown.
AlanKayisagoodexampleforsuchgreatleader.
技术带头人:
1）清楚的远景。
没有清楚的远景，只有强大技术能力的团队，就像盲人骑瞎马，还使劲用鞭子抽打，让马快跑。
看起来一度非常拉风，但后来免不了人仰马翻。
2）信任团队，把大方向弄清楚之后，把其他事情交给团队成员去搞清楚。
如果带头人详细规定了所有细节，那么团队成员干得还有什么劲呢？
3）避免“微观管理”。
当你担心或者没有安全感的时候，你当然会希望把所有细节都搞清楚，但是这样反而会出乱子。
LPeterDeutsch
veteranofXeroxPARC, authorofGhostscript;
nowheisintomusiccomposition.
skillsofgoodprogrammer:
intuition–noluck,butexperiencethathadsimplygotteninternalizedsofardownthatididn’thaveconsciousaccesstotheprocess.
programmer–peoplewhofeelcomfortableswimmingaroundintheworldofsymbols.
programmervs.coder:
"Coder"isstronglyassociatedwiththesmallestandmostnarrowlyfocusedpartofthatwholesoftwarebuildingendeavour. "coder"representssuchasmallcornerofthewholeprocesss.
agoodtitleshouldbe:
softwaredeveloper.
computerscience=enginnering+appliedmathematics.
Iwould'vethoughtthattheinterntwasinherentlyuncontrollable,andinolongerthinkthat.Chinashowsthatyoucandoitprettyeffectively.
优秀程序员：
直觉。
但是Peter说的不是运气，而是长期实践之后成为你思维一部分的东西-你不知道推理这些东西出来，正如同你不知道如何推理出直觉。
Peter认为优秀的程序员必须能在抽象思维（worldofsymbols）中得心应手的人。
程序员vs.码农:
Peter认为Coder把程序员的工作定义得太狭隘了。
就像IT民工，翻沙，砌墙。
砌墙并不是一个坏工作，但这只是“建筑”这一过程中的一个小部分。
"软件开发者"应该是一个好名称，虽然并不全面。
所谓"计算机科学"不过是工程加上应用数学。
我原以为互联网是根本上无法控制的。
。
。
KenThompson
creatorofUnix.
Talentedprogrammers:
it'sjustenthusiasm.youaskthemwhat'sthemostinterestingprogramtheyworkedon, getthemtodescribeitanditsalgorthmsandwhat'sgoingon. iftheycan'twithstandmyquestioningontheirprogram,thentheyarenotgood.
enthusiasmisnotsomethingyouaskdirectly,butintheconversationyou'llcomewiththeenthusiasm-ometer.
优秀程序员的特点:
就是“热情”，我们有时也说"passionfortechnology".
但是在面试的时候你不能问-你对计算机技术有热情么?
因为所有回答都是yes。
你要在场景中，对话中感觉对方的“热情”。
如果一个念了5-7年计算机专业的人，不能“两眼放光”地给你讲他自己最得意，最激动人心的项目或算法，不能回答你的深入提问，除了老师的作业和实验室老板叫做的项目之外，没有别的想法。
你觉得这种人有多少“热情”?
Ken还表达了自己对C++的意见，几乎所有这本书采访的牛人都不太喜欢C++，很有意思，不过这是另外一个话题了。
Coder
Whattheysayaboutgoodprogrammer,interview,anddesign
Myinterpretation
FranAllen
firstwomanwinnerofTuringAward
Softwareprocess:
didsoftware-developmentprocesssavetheIBM/360project?
it'swasabsolutelynecessary, butitwaspainfulforthesoftwarepeopleto[adjustto]designreviews,designspecs,allofthisstuff.
goodprogrammer:
basicthreshold:
findoutwhatthey'reexcitedabout.
iftheycan'tgetenthusiasticaboutsomething, they'renotgoingtogetchargedupinagroup.
软件流程:
因为IBM/360项目的软件部分遇到了很大的困难，那时候还没有什么成文的"软件工程"，FredBrooks把管硬件的经理们调来，让他们来管软件部门，因为硬件是一个相对成熟的产业-芯片设计，测试，等等。
这些“不懂软件”的同志们参考硬件产业，建立了软件工程的基本流程。
从一个成熟的产业中学习，是很有效的办法。
现在我们还可以从软件工程的一些术语中看到硬件的影子-例如smoketest冒烟测试。
好的程序员:
热情（前面Ken同学也谈到了这一点）
BernieCosell
czarofPDP-1
pioneerofAPPANET, thecoreofthelaterinternet
advicetoprogrammer:
writealotofprograms.
thereisveryfewinherentlyhardprograms.ifthecodelooksveryhard,that'salmostalwaysanindicationthatitwaspoorlythoughtthruough. ifyouhavecomplicatedcode,putitinanencapulatedplace.
programsaremeanttoberead.
avoidprem
升级会员 