《卓越程序员密码》书评

亚马逊5星书评

1、这些文章将会改变我的工作方式作者：Thomas Duff我喜欢那种将很多有关技术（这本书是软件开发）的文章和思想汇集在一起的图书，这样我就可以仔细思考作为一种职业我要做什么。Ka Wai Cheung的这本书就非常切合我的这个想法。我常常认为，如果能从一本书中发现一两个精华之处，就像这本，那么这就是一本畅销书。对我来说，这本书就符合并超越了这个标准。这本书里的文章（共52篇）本质上没有一篇是谈技术的，你不可能从中学到有关算法或系统架构的新方法。相反，书中深入探讨了如何思考和开展工作的思维模式和概念，“比喻”一节中的前两篇文章就是这样探讨软件开发的。因为我们将建造软件与传统的建筑行业等同起来，所以在写代码之前都会过度地计划系统，并确定好每一件事。然而在现实中，代码是灵活可变的，而砖和砂浆是不能轻易固定的。“建造”的比喻，意味着我们在写代码之前要计划、计划、再计划（思考一下瀑布开发和敏捷开发），从而限制了生产力。比喻并没有错，但必须谨慎，不能引喻失义。我认为，“教学”一章很吸引人。具体说，“为简化不妨说谎”所阐述的问题就曾让我在太多的场合深受其害。当我试图教某人一种新技巧或一个新特性时，总是想把每一件事都讲得非常完美，比如所有的边界情况、不重要的奇怪情况、发布时所掩盖的错误。问题是，学生连基本概念都不理解，更别说那些深奥的学问了。不要把所有的知识一股脑地塞给他们，那只是在说谎。请告诉他们，事情在95%的情况下是如何工作的。在他们掌握基础知识之前，不要提例外情况。一旦他们理解了这些知识，你可以再补充这些内容。这篇文章将会改变我向别人传递信息的方式。每个人都有不同的背景，不同的工作经验，他们对这本书的感受也会不同。但我可以确定地说，这本书非常值得一读，你很容易就会发现二三个让你不虚此价的精华之处。2、拿起就放不下作者：Tyler Ashbaugh我根本就放不下这本书，一星期就看完了！我可以肯定，今后我还会回顾这本书的。经验丰富的人知道但忽视了的、新人需要知道的好技巧，在书中比比皆是。Ka Wai Cheung做了件非常好的事儿，将这些内容组织成了容易理解的文章。我购买过很多关于计算机编程的书，通常都是技术性的参考手册。而读这本书，就像是坐在那儿和作者对话。我不认为每个读者都会和我一样，欣慰地知道有人与我关于软件应该如何开发的观点相同，但希望每个读者都能从之前未曾想到的、新的软件开发方式中获得启发。我只希望，这是我读过的这类图书的第一本，而不是唯一的一本。我希望看到，书中的某些章节能以类似的模式加以扩展。我强烈推荐计算机领域的每个人都看看这本书，我已经向很多朋友推荐了这本书。3、短，但有启发作者：Jack D. Herrington这是一本有趣的书，能给你启发、见解，甚至一些编码建议。不过，编码建议只是你的额外收获，它不是这本书的要点。这本书集中阐述了作为职业的软件开发的方方面面。如何教人，如何与客户打交道，如何把事情做好，或许最重要的是如何注重实效，并获得乐趣。你想要在这里了解一些晦涩的C#语法构造吗?这里没有。总之，这正是谷歌当下所倡导的。如果你是一位严肃、愿意奉献一生的工程师，想要提个神回到有趣的开发工作中，那就买这本书看看吧。

读书笔记：富有激情的手艺人和思想者&厨子

“对于忠告,你所能做的,就是把它送给别人,因为它对你没有任何用处。”-- 王尔德软件开发行业的从业人员成千上万，你如何保证自己出色地完成自己的工作？ch1吸收他人的第一手教训和忠告。ch2我们从事的行业是艺术和逻辑关系紧密。有时如一个艺术家激情四射、有时也像一名工程师“呆板”。行业充满了比喻，我们用比喻向外人描述自己的工作。但是我们编写的代码普通人是无法看出他的优雅和糟糕。不像大厨做出的肉汤尝一口就能尝出问到是否太闲；不像音乐家的谱曲一听就能听出调子、节奏是否老套。当我们将编程的独特性讲述给普通、解决软件问题的决策方式，我们需要使用“元语言 ”。元语言是用来谈论、观察和分析另一种语言另一种（对象语言）的语言。他可以是自然语言，如学习外语时用于解释外文的本民族语言，也可以是一套语言符号。

一本教方法论的书

每个人应该都能从这本书中学到点东西。工作的人应该会学到的更多。我还是个学生，但是也从这本书中学到了不少东西，鼓励自己多思考，对“消闲”项目说不，安排免打扰时间等。举例来说，QQ、看论七八糟的新闻原先占据了我很多时间，并且把我一天的时间切割了，让我不能够大段的时间专心做实验，思考问题。看过这本书之后，我现在已经习惯白天不上QQ，少看新闻了，是个不小的进步。所以，推荐下。

避免常犯的错误

文中以信条的方式，告诫软件开发者不要去犯一些常见的错误。每一条信条都用比较简短、精辟的文字介绍。我觉得这种书籍的作用就是如果你觉得对，就照着去做就行了。如果觉得不对，也没有什么关系，等真正遇到作者也遇到过的问题的时候，自己亲身经历一次理解得会更深刻。比较有意思的一点是：作者一开始就说谨慎使用比喻，在文中第七页说道：“比喻和现实之间的界限可能会比较模糊。比喻可能让我们过于重视那些不重要的东西，而对真正重要的掉以轻心。 ”然后，在后面很多地方却使用比喻来论证其道理，这未免也缺少一些说服力。总之，本书还是值得一看的。尤其是遇到一些非技术的难题时，本书的经验和教训或许能给我们一些启示。

摘几条对我有启发的

2 规划完备，然后开工不总是有必要。因为软件开发的剪切、撤销或者复原非常方便，几乎没有成本。新版本的发布也很容易。敏捷软件开发。8.工作即福利如果做的是自己喜欢的，那工作本身就是一种福利。17. 对消闲项目坚决说不。虽然自己自己搞着玩，但还是有计划，有deadline。你有几个自己的project半途而废？24. 采用自治小团队的工作形式。程序员最好的工作环境是人员流动率很低的自治小团队。48. 把机器和人的工作区分开让能自动化的全部自动化吧！

简评 +读书笔记

给了3颗星，还行0. 用小短文的形式，写了很多是日常工作中的小经验。1. 内容涵盖面挺广的，都不太深。2. 作者是作坊式的开发者，所以内容有一定局限性3. 一个下午就看完了，重点看了中间的《动力》《生产力》，最后几部分不吸引我，就略读了下面是读书笔记，摘录了一些我个人笔记喜欢的句子，有修改，加入个人观点。P1《引言》编程不想数学物理一样一大堆理论，它还和设计关系紧密，艺术与逻辑一样重要。隐身不适合搞编程，我们要和用户打交道P21《动力》制作软件的过程中，在不同的时间点，可能有不同的东西促使你前进。保持动力的存在于各行各业P26《从喜欢入手》如果你发现自己就是三分钟热度，那么及时停止，损失也不大。用三天（或者一礼拜）踏踏实实地去写程序，你会对自己在做的东西以及剩下的部分何时能够完成有更多的了解。有一点灵感并做出了一点点成绩之后，再去制定切合实际的时间表就容易多了。P27《莫求全》要在行业中生存下来，你最好不是一个完美主义者。我们的产品是通过用户存活下来的。用户基数增长，他会嬗变（本质变化）。新功能会不断涌现，新Bug会不断产生，追求完美会让人精疲力尽。越早接受不完美，就越能保持干劲、坚持到底，最后完成工作就越多。P27《休止一下》两个小时的高质量编程胜过八个小时的煎熬，所以，出去走走，享受一下生活吧。P39《找个争论话题》网络社区的好处在于，你的发言是简历在内容上的，别人不关心你是谁。写作让你斟字酌句，让她趋于完美。你可以自己建一个博客，也可以联系其他有影响力的博客作者，写些客座文章。你会惊讶于这个社区有多么包容。P42《对消闲项目坚决说不》Q我每周花几天，每天花多少时间在这个项目上？Q我什么时候能出demo给人展示Q哪一天release to publicQ哪一天发第一个main update version没有deadline就没有生产力P48《去掉时间表中的细节》搞开发十二年了，从来没有一个项目是完全按照计划走的。所以，开始做计划的时候，要少计划些细节。P55《为良好的工作环境投资》若想知道某项工作好不好，迅速扫一眼办公室，就知道管理层是不是关注开发团队。显示器数/员工数：[1]不关注(1-2)有一定程度关注[2-3)非常关注[3-)走错办公司啦~P56《列张个人待办事项清单》好的代办清单的特质：-一张清单，只有一张-今天、明天、后天、未来-不嵌套，易修改-若干短任务，每个几小时-*每天清理，超过一周在未来，直接删掉P62《安排免打扰时间》那些希望员工发展而不是仅仅关注生存的公司，都需要采取一些方法来将其变成现实，比如google的20%时间做喜欢且与公司相关的项目每天轮流两小时免打扰时间：不用回邮件、不参加会议、不接电话、不收IM，不说话P65《采用自治小团队的工作形式》有些特别大的公司，可以持续招聘，所以一年内把新员工的活力挤榨得一干二净，然后又去市场找人。大公司“繁文缛节、官僚作风、开会无休、优柔寡断、犹豫不决”，然后高举“人是我们的宝贵资产”P67《提高生产力，避谈“我们”》eg:会议上，我们需要加硬件么？=>mike，我们需要加硬件么？P75《关于“简单”的悖论》“一个想法足够复杂，所以很有价值”矛盾就在于此。作为开发者，我们往往把所做软件的价值等同于其复杂性，复杂度越高就等于价值越大。并非功能讨论了好几个小时，我们就得添加好几个功能。我们会很自然觉得，功能数要和投入的时间成正比，不管新功能带来什么好处。一旦你不再天真地任务简单会降低价值，就可以开发出好的软件了。P115《宽容大度，和蔼可亲》充满热情的程序猿容易愤怒。因为不成熟的想法和客人争辩，实在是让人郁闷。打电话给他们，而不是只发邮件。你会惊讶的发现，一个体贴的声音能给你带来很大的转机。P124《写代码是不得已而为之》有些好的答案是在别处发现的。Q别人做过这件事么？我能不能拿到现成源码？Q这个功能重要么？是不是已经有了，只是需要不同的用户体验来实现。Q有没有更简单的实现方式？即使这方式没完全解决问题，是不是也值得做出让步？Q能自动化么？以后不重复劳动啦P126《拿来主义文化》真正伟大的代码别人已经写好了，它们已经发往全世界，帮助我们加快流程。