雨夜，北京，在家读了《卓越程序员密码》一书，觉得有一些内容值得回味，所以写了这篇读书笔记。
卓越程序员密码
本书的作者是Ka Wai Cheung，一看名字就知道是中国人，的确如此，作者名叫张家为，是一名程序员和设计师，同时也是美国芝加哥“We Are Mammoth”公司的联合创始人，公司名称翻译成中文是“我们是猛犸”，很好玩的一个名字。
出于好奇，我看了We Are Mammoth的网站，网站设计的既有趣又有爱，可想而知，这是一家充满活力的公司。如果大家有兴趣，可以去那里浏览他们的公司主页。
这本《卓越程序员密码》，并不厚，全书总共只有157页，分为9个章节，分别是“引言”、“比喻”、“动力”、“生产力”、“复杂性”、“教学”、 “客户”、“代码”和“自豪感”。直到第8章才提到代码，足以说明这本书其实并不是教你如何编程的，而是教你如何高效的出色的完成任务的。
言归正传，我们来看看这本书里哪些段落是值得回味和思考的。
本书的封面：
【思想相通】
在编程的世界里，我们会和各种各样的“语言”打交道。虽然我主要的服务器端开发语言是C#，但我的工作方法却几乎可以完全应用到Java、PHP、 Ruby和Python上。编程语言虽然有不同，但核心的编程思想、方法和架构却是高度类似的。我们只是用不同的方式来表达而已。
【普通人不了解编程】
大厨用不着琢磨烹饪要怎么比喻，肉汤要是太咸了，你一下就能尝出来了；音乐家也不用这么拐弯抹角地描述歌曲，一个调子听起来太老套，是因为你早先就 听过一样的节奏。别人一下就明白了。然而，编程可不大一样。普通人看不出来什么样的代码优雅，什么样得代码一团糟。我们这个行业非常新。人类做饭、创作音 乐、盖房子都有几千年了，可是考古学家还没在岩壁上发现“人类坐在桌前打字”这种图案。
【不要过度规划】
在传统的建筑行业中，规划是至关重要的。因为要建一个摩天大楼，撤销（ctrl-z）、剪贴（ctrl-x）和拷贝（ctrl-c）都是行不通的。 建筑上没法享受这些简洁而强劲的案件，所以需要非常详尽的说明书。日进斗金的房地产生意和灾难性得头条新闻之间就只有一步之遥。所以，要是打算建造一栋摩 天大楼，把建筑说明书写得详细到让人想吐才是最合理的做法。
反过来，这些就是我们这个行业独有得奢华享受了。软件组件又不需要等着本地的工厂发运字母和数字。打字、编译、测试，然后重复就行了。我们可以在实 际产品上测试代码，而不用对着产品的某种模具测试。在开发过程中，我们可以看着悬索桥断成千上万次，在各种地方断，在各种条件下断，而不用担心浪费材料或 者闹出人命。
在写第一行代码之前做出非常详细的说明书仍然有些好处，但这没能充分利用到这种媒介的优势。“规划、规划、规划”过于强调要花大量时间计划让所有东西臻于完美，而忽视了可以用好实际写代码的工夫。
【扔掉旧代码】
即使我确定要重新实现我前一阵子写过的东西，早先注释掉的东西一般来说也无论如何用不上。我可能把其他地方的逻辑动过了，旧代码里面引用的对象或者方法可能也变了。比起重新干干净净地把代码写对，要把这旧代码救活，我得花上更多的时间在那儿东敲西补。
不要把代码囤积在注释里，删除代码可以让代码库精简。眼前的页面应该精确地反映出软件现在的工作方式，一分不多，一分不少。现在就扔掉旧代码，在编 程中间就不用跳过一堆不相干得垃圾字节。我们以后也用不着去琢磨，这一大团已经注释掉可看起来还很重要的代码，到底还是不是那么重要。
【多元化胜于专业化】
在传统的建筑行业里，让电工兼任水泥浇筑工，或者让铺砖工去装管道都是不现实的事情。他们都各有专长，各司其职。但把同样的理念移植到我们这个行业 就不大站得住脚了。我们工作所用的工具无非就在眼前的这块屏幕上。如果正在搞SQL，也用不着要换个地方才能写HTML或者是在Photoshop里面弄 上一张图，只要在计算机上切换程序就行了。编程的科目之间，没有任何物理上的障碍。
【工作即福利】
在我们这个行业里，长久的动力并不来自于福利。当然，高薪和免费午餐确实不错，能随时玩玩桌上足球机也不赖。但归根结底，长久的动力来自于我们所做 的工作。我所见到的每个有激情的程序员，在谈论起经过长时间苦苦思索才为技术问题找到的优雅解决方案时，都异常兴奋，这比说起在公司编程大会上赢得10% 的加薪要兴奋得多。
【福利可能是毁灭性的】
表面化的福利实际上会削弱人们工作的积极性。是的，在我们面前晃动的胡萝卜可能让我们更加没有工作的激情。
传统的商业激励因素，比如大笔奖金，可能会成功调动员工的积极性，但只能用于那些简单琐碎的工作，类似于把数据从一张表填到另一张表这样的工作。
相反，那些需要批判性分析和创造性解决方案的工作，就像我们每天面对的这些，把金钱奖励挂在员工眼前晃悠则没什么用处。在一些涉及高层次思考的实验中，金钱激励和业绩之间是负相关：给一组特定研究对象的金钱奖励越多，他们最后做的越糟。
#p#
【别在卧室里工作】
正如帕金森定律所说：“工作会不断膨胀，直到占满所有可用的时间之后才会完成。”由于我们可以在一天中的任何时间工作，所以可占用的时间就多了去了。每周40个小时的工作突然就变成了168小时的工作+睡觉+吃喝娱乐。
在家办公是一种奢侈，如果你有幸享受这一点的话，千万不要在卧室办公，最好搞出一个封闭的房间，这样就可以在工作时间结束后从那里离开，在门上挂上“打烊”的牌子，然后去享受生活中的其他乐趣，第二天再继续工作。
这才是真正的生活。
【对闲散项目坚决说不】
我们每个人都有一堆闲散项目，可能是写了一半但从来没完成的软件，也可能是开始写时干劲十足，但因出现更紧迫的事情而戛然而止的代码。可以怪其他工作占用了时间，也可能是我们自己已然失去了兴趣。
这类闲散项目本身没有严格的时间限制，而且不成功也没有什么关系，因此注定要失败。如果它的发布日期不定，只是“未来某年某月某日”，很可能我们近期就不会去完成它。
三个月怎么样？
Jack Dorsey用三个月开发了一个鲜为人知的短信服务，他从构思到发布第一版所花的时间还不到三个月，这个服务就是后来的Twitter。试想一下，如果他年复一年地开发，而不是一旦开始就闪电发布，那么结果可能就大不一样了。
【设定一个最后期限，即使是随便设的】
制定了最后期限，工作才能得以完成，否则产品永远难见曙光。最后期限提升了工作的重要性。如果让一个项目从几个月拖到几年，你的产品可能就失去了开始时所期待得价值了。
最后期限创造了一种紧迫感，敦促你冲过终点线。即使没有人再逼迫你，它也能给你你所需的鞭策。
【去掉时间表中的细节】
我搞软件开发十二年，从来没见过一个项目是完全按计划走的。
功能会变，未预料到的障碍会出现。有时候，我们预计花一个星期的事情，最后花了三个星期。不过，最常见的事情是我们把项目时间制定得过于详细，会让 我们成为时间的奴隶。所以，开始做计划的时候，要少计划些细节。一个八周的项目，找出八个每周要交付的成果，而不是四十个每天要交付的东西。
如果时间表太详细，交付太频繁，开发过程中就没有做试验伙食重新考虑细节的余地。我们便只能严格遵守根据摄像出来的任务所设定的时间表，就好像被一 个无知的“微观经理”一直监督着一样。一旦有几个小任务没按时完成，整个时间表就轰然坍塌了。这一点也不会激发我们的积极性，好的软件不是这么开发出来 的。
【团队是最宝贵的资产】
很多大公司都在兜售“人是我们最宝贵的资产”的陈词滥调，听起来就恶心。这些公司同时在用胸牌编号标识员工，用法购物卡的方式来挽救员工迅速消退的积极性，结果呢，还不是人员流动率居高不下。
说老实话，在我的小咨询公司里，人不是最宝贵的资产。而随着时间建立起来的工作关系才是最重要的。我已经和几乎同一批志趣相投的人一起工作了许多年，这种团队内部的亲密感意味着我们知道每个人喜欢的工作方式。
有些人喜欢细致周到地工作，每一行代码都深思熟虑；有些人则粗枝大叶，再事后清理；有些人经常需要独自工作，单枪匹马解决问题；而有些人则一上来就 需要协作。慢慢地，我们会以不同的方式互相弥补，我们会适应周围的人。随着时间的推移，我们开始凝聚在一起，真的是“凝”在一起。
【当心“知识魔咒”】
一旦你成为了某个领域的专家，就几乎不可能明白对这个领域一无所知是什么感觉。
想想你该如何向一个先天失明的人解释是什么颜色，或者向先天失聪的人解释什么是声音。举个不那么极端的例子，想想律师吧，如果没有各种抽象和限定，他就没法准确回答法律问题。
这种现象就称为“知识魔咒”。
【为简化不妨说谎】
当你教一样新东西的时候，不要认为你所说的每一句话都必须是百分之百正确的。要把一个概念从一开始就将得非常完美，既不现实，效果也不好。高级概念本来就难以理解，这也正是它成为高级概念的原因。
所以，在你成为专家之后，要先把你所在领域中那些错综复杂的细枝末节舍掉。不要讲那些“除了”和“但是要…”之类的特殊情况，因为它们现在不那么重要。稍微把事实扭曲一点没什么大不了的，讲课时，善意的谎言并不见得是件坏事。
【项目管理主要是人的管理】
好的开发人员是软件领域的专家，而好的项目经理是客户领域的专家。他们和电话或邮件那头的人形成了亲密的工作关系。他们知道什么时候可以拖延，或者什么东西对于客户来说是真正重要的。客户工作对于项目经理来说可能是一场情绪上的挣扎。
【代码的迷人特质】
代码不会偷懒；
代码不会嫌烦；
代码很廉价；
代码不会遗忘；
代码运行很快；
可见，代码才是有史以来最伟大得初级程序员。
==
【结语】
这本书里，包含了作者的很多感悟，其中一些思考和沉淀，不光对程序员有益，对于做很多事情都有指导作用。
如果有空，可以看看这本小书，再结合自己之前的工作体会，或许能有自己的一些理解和收获！
谢谢！
