《程序员的呐喊》是一本由[美]Steve Yegge著作，人民邮电出版社出版的平装图书，本书定价：45.00元，页数：190，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《程序员的呐喊》读后感(一)：一个熟悉多种语言的老程序员对编程语言、开发流程、google的战略等的思考，比较有趣。

　　作者熟悉二三十种编程语言，写了20多年代码。本书是作者对编程语言、开发流程、google的战略等的思考。比较有趣。

　　前面部分是作者对编程语言的一些思考。作者鄙视C++， Java，面向对象。比较有趣的是作者把编程语言和思想划分为自由和保守两大阵营。自由派希望快速发布，容忍bug和安全上的缺陷，保守派则重视安全和稳健

　　作者认为，设计优秀的弱类型系统比同样优秀的强类型系统更有竞争力。

　　作者推崇精简，认为代码最大的敌人是体格，也就是代码的行数。

　　作者认为Perl和Python两种语言的出现时间差不多，Perl市场占有率高出许多，原因是Perl创始人的天才营销，包括得到了Oreilly出版社的支持

　　作者谈到google的面试。他认为面试官们的个人技能性格阅历都会影响面试结果，面试充满偶然。当然面试通过的充分条件还是有的，作者最看重的是算法和数据结构。

　　作者笔下的Google的开发流程比较完美：有严格的单元测试、设计文档、代码审查，代码库整齐划一，如同出自一人之手；经理至少有一半时间写代码；安静的环境；没有甘特图任务表，优秀的程序员们为了自己的荣誉而努力工作。

　　作者认为google的缺陷是没有做平台的意识，没能做出一个比较大的平台来。亚马逊、facebook则成功地做出了平台。

　　《程序员的呐喊》读后感(二)：程序员的呐喊太长

　　* 软件开发的方式多种多样，不存在谁好谁坏。但是它们都互相看不起

　　* 好的程序员之所以出色是因为熟能生巧

　　* 只要你愿意，随时都可以学习新语言

　　* 如果你想要当经理，那么你可能不是个好经理

　　* Lisp很难掌握，但它是唯一能让你继续快乐的语言

　　* Emacs很难掌握，但却是终生受益的投资

　　* 离开舒适区，时不时的的学点新东西

　　* 为自己写点东西，只有这样你才知道那是不是对的

　　* 多笑一点，这很健康，也让人感觉良好

　　* 记得自嘲，不过不要在公开场合大声自嘲，也不要忘了解释

　　《程序员的呐喊》读后感(三)：。。。。。

　　以下节选自王垠《我和 Google 的故事》

　　。。。。。。。。。

　　最开头的时候 Steve 给了我两个选择：检索 C++ 或者是 Python。我觉得 C++ 的设计太繁琐，所以就选择了看起来好一点的 Python。Steve 就让我去找一个好一点的开源的 Python IDE，然后把里面的语义检索部分挖出来插入到项目里面。可是在看过十个左右的“Python IDE”之后，我发现它们没有一个能够正确的“跳转到定义”。分析其原因，是因为这些 IDE 基本上做的是正则表达式匹配，而完全不理解 Python 的语义。所以我对 Steve 说，我要自己从头写一个。但他反对这个提议，因为他觉得这是三个月的时间之内不可能完成的。不但是我不能，而且就算一个小组的高级程序员也不可能完成。就算完成了，他也不想“维护”这些代码。所以他宁愿让我去拿一个不怎么样的开源项目，因为这样“维护”的工作就转嫁到开源项目身上去了。这也许就是 Google 支持开源运动的原因吧？

　　可是我很清楚的看到，这样一个语义检索，不过是一个抽象解释器 (abstract interpreter)。写解释器是我最在行的，所以我告诉他这是我可以完成的，而且由于设计上的简洁，我的代码的维护代价会比使用一个开源项目小很多。他没有说话。我同时也在进行一些内部培训，看一些视频，折腾 MapReduce 一类的内部工具教程，就这样过了一个星期。我隐约的感觉到 Steve 的不快，因为他不怎么说话了，可是我也没有太在意，仍然傻乎乎的到处凑热闹。到了周五的时候，Steve 下午很早就回家了。另一个组员还待在哪里，不时的叹气。我对她说：“Steve 是不是不高兴了？我知道我说话有点太自信，可能打击到他了。”她好像打满的气球被开了一个洞：“他怎么会被你打击到？你知道他以前做的项目有多厉害吗？他是怕你做不出来。之前有一些 intern 设的目标太高，以至于到最后没有完成他们的项目。”于是她打开 Eclipse，把 JSCompiler 的代码给我看。“你知道我们以前一个类似的项目 JSCompiler，花了多少时间才完成吗？一个小组的人，四年的时间！”她打开其中一个文件，也就是处理符号表的那个模块，说：“看这一个文件就有 9000 多行代码。你三个月能写出这么多代码吗？”我翻了一下白眼，搞笑似地说：“啊～ 怎么可能有 9000 多行？这些人真的知道怎么写这种代码吗……”

　　后来具体的对话我忘记了，但是她确实给了我一些压力，再加上 Steve 那个闷声子，真是不好受。所以那个周末我没有出去玩，我下载了一个 Jython，把它的 parser 文件 (ANTLR) 拿出来。然后自己设计了一个更简单的 AST 数据结构，把这个 parser 生成的 AST 转换成我的结构。然后就开始在上面写一个抽象解释器。由于 Java 的限制，我想出了一个更简洁的用 Java 实现解释器的方法，从而避免了使用繁琐的 visitor pattern。一个周末之后，我做出了一个基本的原型。当然因为 Python 语言的复杂性，有很多细节的东西到后来才完全的实现。

　　等到星期一的时候，我告诉 Steve 我做了一个原型出来，而且因为我拿了 Jython 的 parser，我们以后可以用这个理由把这代码 merge 回 Jython，给他们提供功能，让他们帮我们维护代码，对两方都有好处。他居然一点也不高兴，把我叫到一个白板前面，板着脸说：“来，给我讲一下你打算怎么做。”我就画了一个 AST 的类关系图，在里面每个类插入一个叫 interp 的方法，然后指出这个东西就是一个抽象解释器。最后他豁然开朗了一样，说：“好。我相信你知道你在干什么了。就这样做吧。”

　　。。。。。。

　　虽然 Steve “允许”我自己从头做一个 Python 分析器，但这却不是没有压力的。这种感觉就像是“皇帝的新装”里的织布工一样。我扬言自己会做出精美绝伦的布料，皇帝的大臣们却看不见，所以他们就相当的小心。总是对我很敬畏的样子，有时会来问候一下，做得怎么样了。可是一旦扯到深入的话题，却又怕被看穿其实他们不懂很多东西。因为我的教授们研究 Scheme，所以 Steve 有时候也会很激动的表扬 Scheme，或者类似 Scheme 的语言比如 Clojure。这种奉承真的让我受不了，生搬来的术语都是错乱的，所以经常来回两句之后，他就无语了。为什么程序语言总是引起这种宗教的态度，不是抵制就是膜拜？

　　有一次一个 Staff Software Engineer 来访。看我在做这个 Python 分析器，很鄙夷的样子，说：“你做那个东西干什么。Python 本来是没有类型的，怎么推导得出类型来？我倒希望 Java 的类型推导做得更好一些，不用手写很多类型。”显然他不知道什么是类型推导，他也不知道如何把 Java 的类型推导做得更好。很多人把自己的命运寄托在语言的设计者身上，自己没有能力去改进它们，所以他们才会对程序语言顶礼膜拜。

　　《程序员的呐喊》读后感(四)：书本编排有点乱

　　内容跳来跳去，但总体来说里面解决了我一些设计模式，代码重构，与项目，敏捷方面的疑问

　　第一章 编程语言的宗教

　　咸鱼白菜各有所好，各类编程语言都有大家的喜爱的特性

　　明显地在大公司会产生很多分水岭，如强弱型语言

　　重构，不是重写，是不断优化成已修改，可阅读，易理解的代码，设置用自动工具，DSL等快速响应需求提高效率

　　就像清理衣柜同事保证不掉任何东西，只要换大些衣柜，把东西分门别类

　　强弱类型语言其实都是为了数据模型，定义接口与需求来服务

　　强类型语言（c java等）类型确定，java等面向对象语言，定义接口规范，让系统稳定，性能高效

　　弱类型语言（Python，ruby等）快速响应需求变化数据模型，重用重新编译

　　第二章 代码里的哲学

　　语言社区就是一个宗教，有人捍卫，其他人也会不断攻击对方，千万不要失去质疑的心，去了解其他特性与修复问题

　　代码的天敌，庞大的代码量，无章的代码逻辑，难以维护，响应需求

　　小数派 他们不喜欢复杂膨胀的代码，他们得观点是把代码管理得好好，利用工具如，不断重构，单元测试，自动化测试，提高效率

　　设计模式不是特性，他是23个衣柜，分别装不同的东西，使其整洁

　　合理代码量 没有标准，就是要跟上你编写语言的新特性或者利用其他方面重写功能，新语言，或原来语言的新特性，来不断优化

　　反对反宣传 其实就是语言社区的一个推广，语言不断去继承或吸收其他语言特性，加上维护者的推广吸引开发者，如python 本身好语言，但是为何又不能够给java 更加广泛应用，处理有大公司支持，还有很多书籍覆盖

　　斑比和哥斯拉 说了各个语言他们特性优点缺点，是反对反宣传的延伸

　　程序员的数学 教导我们需要通过程序思维去学习，可以通过工作问题去寻找一些数学方面东西去了解

　　学习数学的正确方法，先广度，理解每一点又来解决什么问题，如除法，求余数，其实就是不断减去你想除的直到不能够在减，剩余的数

　　数学是锻炼思维，界定问题，适量习题能够了解应用，如写代码，

　　土豪程序员的美餐不过就是让自己做喜欢东西，动手做

　　编译原理需要学习，编译原理本质就是把一个符号流转变成另外一个符号流，图像分析，自然语言分析等

　　一般分三个步骤 解析，类型检查，生成代码，这样都有效地改善代码，变成自动化，使用DSL等

　　学习计算一定需要动手

　　第三章 关于google

　　大公司面试，关键看你基本功，算法与数据结构，重思维

　　敏捷好与坏

　　坏，照搬理论，没有因地制宜，还是用以前思想用敏捷去包装

　　好，内部激发，让工程师去主动驱动，奖励形式，每个项目都是一个创业项目，这样就达到人的交互，产品快速迭代，激发创新

　　其实就是不要照搬理论，需要转换自己公司实际情况，无非就是要让人这个物体不断去参与，这个物体是用户，是开发者，是公司，是产品。不断去交互，让大家活起来

　　其他部分没有兴趣略

　　《程序员的呐喊》读后感(五)：本书的几个点

　　翻译确实不错，但是排版有些问题。我猜人邮是雇的实习生用word排的。

　　本书的几个点

　　* 各种编程语言的大讨论，最后勉强胜出的是Ruby

　　ython也没什么问题，就是社区文化太死板、说教味太浓，一想，还真是。使用方法的对与不对还应该交给那些学习Python的聪明人去决定，而不是由大老爹改语言告诉你什么好什么不好。只给些convention和idiom不好吗？P43有一个各种语言的分类列表

　　* Emacs是最好用的编辑器

　　虽然我是个五年Vim党，但Steve的说辞真的让我动心了。虽然有过几次不成功的尝试，但这次我又详细地读了一些资料。貌似在插件的扩展性上Emacs确实要胜过Vimｓｃｒｉｐｔ。而Vim内嵌Python的方法怎么看也不能算是一种长久的解决方式。而且想想自己配置的那么多前缀组合快捷键，似乎没有模式也不是什么大不了的事情

　　* Steve Yegge的面试心经

　　拜托，这可是一线工程师和面试官Steve Yegge的面试心经。面试中硬技能和软技能都帮你点出来了，还有一些实用的小细节，比如面试自带细头的马克笔，真的是第一次见。拿来做《Cracking the Code Interview》的后续或许真的不错，我是指《The Algorithm Design Manual》

　　http://steve-yegge.blogspot.jp/2008/03/get-that-job-at-google.html

　　* Steve Yegge在文中推荐了很多书

　　等有时间重读的时候，我再试着把它们整理出来吧

　　* 书最后有TL;DR

　　也算是简单明了地概括了一些主旨，不只是文章的主旨，还有……呃……一些人生的经验

　　* 编程与驾驶

　　好吧，如果Steve Yegge硬把编程比作驾驶的话，那他一定是个标准的老司机——北京的哥。甭管是什么路况信息，还是什么国家大事、国际风云，总之一句话，给您侃晕菜了算。