《卓越程序员密码》读后感10篇
《卓越程序员密码》是一本由[美] Ka Wai Cheung著作，人民邮电出版社出版的平装图书，本书定价：29.00元，页数：172，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
给了3颗星，还行
1. 内容涵盖面挺广的，都不太深。
3. 一个下午就看完了，重点看了中间的《动力》《生产力》，最后几部分不吸引我，就略读了
下面是读书笔记，摘录了一些我个人笔记喜欢的句子，有修改，加入个人观点。
1《引言》
编程不想数学物理一样一大堆理论，它还和设计关系紧密，艺术与逻辑一样重要。
21《动力》
制作软件的过程中，在不同的时间点，可能有不同的东西促使你前进。保持动力的存在于各行各业
26《从喜欢入手》
用三天（或者一礼拜）踏踏实实地去写程序，你会对自己在做的东西以及剩下的部分何时能够完成有更多的了解。
有一点灵感并做出了一点点成绩之后，再去制定切合实际的时间表就容易多了。
27《莫求全》
我们的产品是通过用户存活下来的。用户基数增长，他会嬗变（本质变化）。新功能会不断涌现，新Bug会不断产生，追求完美会让人精疲力尽。
越早接受不完美，就越能保持干劲、坚持到底，最后完成工作就越多。
27《休止一下》
两个小时的高质量编程胜过八个小时的煎熬，所以，出去走走，享受一下生活吧。
网络社区的好处在于，你的发言是简历在内容上的，别人不关心你是谁。
写作让你斟字酌句，让她趋于完美。
你可以自己建一个博客，也可以联系其他有影响力的博客作者，写些客座文章。你会惊讶于这个社区有多么包容。
Q我每周花几天，每天花多少时间在这个项目上？
Q哪一天release to public
Q哪一天发第一个main update version
没有deadline就没有生产力
48《去掉时间表中的细节》
所以，开始做计划的时候，要少计划些细节。
若想知道某项工作好不好，迅速扫一眼办公室，就知道管理层是不是关注开发团队。
显示器数/员工数：
[1]不关注
(1-2)有一定程度关注
[2-3)非常关注
[3-)走错办公司啦~
好的代办清单的特质：
-一张清单，只有一张
-不嵌套，易修改
-若干短任务，每个几小时
-*每天清理，超过一周在未来，直接删掉
62《安排免打扰时间》
那些希望员工发展而不是仅仅关注生存的公司，都需要采取一些方法来将其变成现实，比如google的20%时间做喜欢且与公司相关的项目
每天轮流两小时免打扰时间：不用回邮件、不参加会议、不接电话、不收IM，不说话
65《采用自治小团队的工作形式》
有些特别大的公司，可以持续招聘，所以一年内把新员工的活力挤榨得一干二净，然后又去市场找人。
大公司“繁文缛节、官僚作风、开会无休、优柔寡断、犹豫不决”，然后高举“人是我们的宝贵资产”
67《提高生产力，避谈“我们”》
eg:会议上，我们需要加硬件么？=>mike，我们需要加硬件么？
矛盾就在于此。作为开发者，我们往往把所做软件的价值等同于其复杂性，复杂度越高就等于价值越大。
并非功能讨论了好几个小时，我们就得添加好几个功能。
我们会很自然觉得，功能数要和投入的时间成正比，不管新功能带来什么好处。
一旦你不再天真地任务简单会降低价值，就可以开发出好的软件了。
打电话给他们，而不是只发邮件。你会惊讶的发现，一个体贴的声音能给你带来很大的转机。
有些好的答案是在别处发现的。
Q别人做过这件事么？我能不能拿到现成源码？
Q这个功能重要么？是不是已经有了，只是需要不同的用户体验来实现。
Q有没有更简单的实现方式？即使这方式没完全解决问题，是不是也值得做出让步？
真正伟大的代码别人已经写好了，它们已经发往全世界，帮助我们加快流程。
《卓越程序员密码》读后感(二)：避免常犯的错误
文中以信条的方式，告诫软件开发者不要去犯一些常见的错误。每一条信条都用比较简短、精辟的文字介绍。我觉得这种书籍的作用就是如果你觉得对，就照着去做就行了。如果觉得不对，也没有什么关系，等真正遇到作者也遇到过的问题的时候，自己亲身经历一次理解得会更深刻。
比较有意思的一点是：作者一开始就说谨慎使用比喻，在文中第七页说道：“比喻和现实之间的界限可能会比较模糊。比喻可能让我们过于重视那些不重要的东西，而对真正重要的掉以轻心。 ”然后，在后面很多地方却使用比喻来论证其道理，这未免也缺少一些说服力。
总之，本书还是值得一看的。尤其是遇到一些非技术的难题时，本书的经验和教训或许能给我们一些启示。
《卓越程序员密码》读后感(三)：读书笔记：富有激情的手艺人和思想者&厨子
“对于忠告,你所能做的,就是把它送给别人,因为它对你没有任何用处。”
-- 王尔德
软件开发行业的从业人员成千上万，你如何保证自己出色地完成自己的工作？
ch1
吸收他人的第一手教训和忠告。
ch2
我们从事的行业是艺术和逻辑关系紧密。有时如一个艺术家激情四射、有时也像一名工程师“呆板”。
行业充满了比喻，我们用比喻向外人描述自己的工作。但是我们编写的代码普通人是无法看出他的优雅和糟糕。不像大厨做出的肉汤尝一口就能尝出问到是否太闲；不像音乐家的谱曲一听就能听出调子、节奏是否老套。
当我们将编程的独特性讲述给普通、解决软件问题的决策方式，我们需要使用“元语言 ”。
元语言是用来谈论、观察和分析另一种语言另一种（对象语言）的语言。他可以是自然语言，如学习外语时用于解释外文的本民族语言，也可以是一套语言符号。
《卓越程序员密码》读后感(四)：亚马逊5星书评
1、这些文章将会改变我的工作方式
作者：Thomas Duff
我喜欢那种将很多有关技术（这本书是软件开发）的文章和思想汇集在一起的图书，这样我就可以仔细思考作为一种职业我要做什么。Ka Wai Cheung的这本书就非常切合我的这个想法。我常常认为，如果能从一本书中发现一两个精华之处，就像这本，那么这就是一本畅销书。对我来说，这本书就符合并超越了这个标准。
这本书里的文章（共52篇）本质上没有一篇是谈技术的，你不可能从中学到有关算法或系统架构的新方法。相反，书中深入探讨了如何思考和开展工作的思维模式和概念，“比喻”一节中的前两篇文章就是这样探讨软件开发的。因为我们将建造软件与传统的建筑行业等同起来，所以在写代码之前都会过度地计划系统，并确定好每一件事。然而在现实中，代码是灵活可变的，而砖和砂浆是不能轻易固定的。“建造”的比喻，意味着我们在写代码之前要计划、计划、再计划（思考一下瀑布开发和敏捷开发），从而限制了生产力。比喻并没有错，但必须谨慎，不能引喻失义。
我认为，“教学”一章很吸引人。具体说，“为简化不妨说谎”所阐述的问题就曾让我在太多的场合深受其害。当我试图教某人一种新技巧或一个新特性时，总是想把每一件事都讲得非常完美，比如所有的边界情况、不重要的奇怪情况、发布时所掩盖的错误。问题是，学生连基本概念都不理解，更别说那些深奥的学问了。不要把所有的知识一股脑地塞给他们，那只是在说谎。请告诉他们，事情在95%的情况下是如何工作的。在他们掌握基础知识之前，不要提例外情况。一旦他们理解了这些知识，你可以再补充这些内容。这篇文章将会改变我向别人传递信息的方式。
每个人都有不同的背景，不同的工作经验，他们对这本书的感受也会不同。但我可以确定地说，这本书非常值得一读，你很容易就会发现二三个让你不虚此价的精华之处。
2、拿起就放不下
作者：Tyler Ashbaugh
我根本就放不下这本书，一星期就看完了！我可以肯定，今后我还会回顾这本书的。经验丰富的人知道但忽视了的、新人需要知道的好技巧，在书中比比皆是。Ka Wai Cheung做了件非常好的事儿，将这些内容组织成了容易理解的文章。我购买过很多关于计算机编程的书，通常都是技术性的参考手册。而读这本书，就像是坐在那儿和作者对话。我不认为每个读者都会和我一样，欣慰地知道有人与我关于软件应该如何开发的观点相同，但希望每个读者都能从之前未曾想到的、新的软件开发方式中获得启发。我只希望，这是我读过的这类图书的第一本，而不是唯一的一本。我希望看到，书中的某些章节能以类似的模式加以扩展。我强烈推荐计算机领域的每个人都看看这本书，我已经向很多朋友推荐了这本书。
3、短，但有启发
作者：Jack D. Herrington
这是一本有趣的书，能给你启发、见解，甚至一些编码建议。不过，编码建议只是你的额外收获，它不是这本书的要点。这本书集中阐述了作为职业的软件开发的方方面面。如何教人，如何与客户打交道，如何把事情做好，或许最重要的是如何注重实效，并获得乐趣。你想要在这里了解一些晦涩的C#语法构造吗？这里没有。总之，这正是谷歌当下所倡导的。
如果你是一位严肃、愿意奉献一生的工程师，想要提个神回到有趣的开发工作中，那就买这本书看看吧。
《卓越程序员密码》读后感(五)：摘几条对我有启发的
不总是有必要。
因为软件开发的剪切、撤销或者复原非常方便，几乎没有成本。新版本的发布也很容易。
敏捷软件开发。
8.工作即福利
如果做的是自己喜欢的，那工作本身就是一种福利。
17. 对消闲项目坚决说不。
虽然自己自己搞着玩，但还是有计划，有deadline。
你有几个自己的project半途而废？
24. 采用自治小团队的工作形式。
程序员最好的工作环境是人员流动率很低的自治小团队。
让能自动化的全部自动化吧！