该作品已下架
原创作品非小说程序员的怒吼
程序员的怒吼

程序员的怒吼

A Programmer's Rantings

作者[美] Steve Yegge

译者陈邃常青

类别行业

提供方豆瓣阅读同文馆

字数约 162,000 字

上架时间尚未上架

作品简介

◎本作品由豆瓣阅读同文馆取得作者授权并组织翻译◎

Steve Yegge，从业二十余年的资深程序员，Google 员工，Amazon 前员工，直言不讳的业界大牛，写过很多让人觉得不爽但又觉得「特别对」的文章。本书是 Steve Yegge的博客精选集，探讨了关于编程语言、代码哲学、Google 企业文化、面试经验等问题，犀利幽默又不失专业，非常值得参考。

原书为电子书，由Hyperink 结集出版，并授予豆瓣阅读译为简体中文并发布数字版的权利。

作品目录

  1. 版权信息
  2. 前言
  3. 第一章 编程语言理念
  4. 作者注：巴别塔
  5. 巴别塔
  6. C语言
  7. C++
  8. Lisp
  9. Java
  10. Perl
  11. Ruby
  12. Python
  13. 结语
  14. 作者注：名词王国的动作
  15. 名词王国的动作
  16. 垃圾满了
  17. 名词王国
  18. 邻国的动词
  19. 如果你的洞挖得够深……
  20. Java国人幸福吗？
  21. StateManager.getConsiderationSetter("Noun Oriented Thinking," State.HARMFUL).run()
  22. 作者注：神秘大巴笔记
  23. 神秘大巴笔记
  24. 真实世界的政治派系和软件领域的派系相关吗？
  25. 两党制不是一种有缺陷的模式吗？
  26. 这么说，安全工程师就是最保守的了，对吗？
  27. 所以……静态类型爱好者是保守主义者喽？
  28. 划分派别
  29. 这里能看出一些基本的规律：
  30. 案例分析
  31. 特别案例分析：Clojure语言
  32. 总结
  33. 作者注：摩尔定律是胡扯
  34. 摩尔定律是胡扯
  35. 重要抉择
  36. 编程最大的问题
  37. 一步步来
  38. 作者注：转换
  39. 转换
  40. 发现重构
  41. 如今的重构
  42. 重奏
  43. 点按生产力
  44. 作者注：弱类型够强吗？
  45. 弱类型够强吗？
  46. 静态类型的优势
  47. 静态类型的弊端
  48. 怎样才对？
  49. 大案例分析
  50. 我为什么支持弱类型？
  51. 弱类型够强吗？
  52. 第二章 代码哲学
  53. 作者注：软件需要哲学家
  54. 软件需要哲学家
  55. 作者注：代码最大的敌人
  56. 代码最大的敌人
  57. 少数派观点
  58. 看不见的膨胀
  59. 设计模式不是特性
  60. 数百万行代码
  61. IDE能解决问题吗？
  62. 合理的代码规模
  63. 下一个Java
  64. 作者注：一点反对反炒作的意见
  65. 一点反对反炒作的意见
  66. 作者注：小鹿斑比遇上哥斯拉
  67. 小鹿斑比遇上哥斯拉
  68. 一门优质编程语言的衰亡
  69. 爱与金钱
  70. 哥斯拉又踩死了小鹿斑比
  71. 文化之事
  72. Ruby
  73. 作者注：程序员的数学之道
  74. 程序员的数学之道
  75. 告别传统观念
  76. 你曾学会的（又忘掉了的）数学
  77. 学校没有教会你的数学
  78. 学习数学的正确之道
  79. 何时做习题最有用？
  80. 这些对我有什么帮助？
  81. 作者注：富人程序员的食单
  82. 富人程序员的食单
  83. 行军床和大胡子
  84. 你如何解决以下问题……
  85. 编译器的工作原理
  86. 编译器为何重要，第一部分
  87. 如果你不修编译器课程……
  88. 恶心莫过于大系统
  89. 编译器的阴暗面
  90. 第三章 在谷歌
  91. 作者注：谷歌求职攻略
  92. 谷歌求职攻略
  93. 注意事项和事先声明
  94. 面试前热身
  95. 精神上的准备
  96. 技术面试准备技巧
  97. 其它数据结构
  98. 其它事项
  99. 作者注：好也是敏捷，坏也是敏捷
  100. 好也是敏捷，坏也是敏捷
  101. 坏的敏捷开发
  102. 好的敏捷开发
  103. 突显特征对比强迫之鞭
  104. 日历的暴政
  105. 坏敏捷开发的更多细节
  106. 敏捷开发之好，不在于其名
  107. 作者注：谷歌还能否长盛不衰？
  108. 谷歌还能否长盛不衰？
  109. 作者注：吐槽谷歌平台
  110. 吐槽谷歌平台
  111. 最、重要、的、事情。
  112. 第四章 结束语

热门划线

  1. 不幸的是，大多数程序员，因为自认为“知道如何编程”，基本上都属于狭隘一族，遇到跟自己不同的人，就想给对方打上“错误”标签。这是人性，是我们最容易陷入的圈套之一，我曾经也是如此。9 人
  2. 卡尔，宗教已经不是大众的精神鸦片了。集成开发环境才是。7 人
  3. 过早优化代码是万恶之源。先让代码运行起来是第一位的，代码正确比性能重要，而迭代原型又比正确性重要。7 人
  4. 所有的计算都是抽象概念的层层推进，在抽象程度低的东西基础上依次构建抽象程度更高的。你不会直接以分子为单位去建一座城市。以程度太低的抽象物为基本单位，会让你陷入麻烦。6 人
  5. 程序员和开车的人总是跟自己说，我可以等“需要的时候”再学习新技能和新学问。但他们心里都明白，等到“需要的时候”，就“太晚”了。5 人
  6. 当人们的驾驶观念发生冲突时，他们的车就会撞到一起。而当理念一致，一个地区的人都以“同样的方式”开车时，事故率就会降到最低，哪怕这些人开车的方式在外人看来跟疯了一样。4 人
  7. 他们形成一个个文化孤岛，然后认定自己的方式是最佳的，而且是唯一选择。4 人
  8. C语言和Lisp语言是截然相反的两种语言，它们各自所擅长的，恰恰对方表现比较差的地方。4 人
  9. 如果说C语言是最接近计算机运行方式的语言，Lisp则与运算本身进行的方式最为接近。4 人
  10. 语言塑造世界。愚蠢的语言只能造就愚蠢的世界。4 人
  11. 亲不尊，熟生蔑。4 人
  12. Emacs是用一百年都不会过时的编辑器。4 人
  13. Python原本可以征服世界，但它有两个致命缺点：空格问题和冰霜问题。4 人
  14. 回头等你只有一堆碎片时间能用来学习的时候，会更加痛苦。4 人
  15. 史蒂芬·斯基纳（Steven Skiena）的《算法设计手册（The Algorithm Design Manua）》4 人
  16. 编程世界也有很多亚文化群，一旦把他们凑到一起，也会发生冲突。3 人
  17. 经过多年的反复试错，我发现让很多人听你讲述的最佳办法是“讲故事”。而你如果不入戏，不享受这个过程，就讲不成好故事。3 人
  18. 我觉得，只要能把《Scheme入门》(The Little Schemer)和《Scheme高手》(The Seasoned Schemer)这两本书里的测试题都做下来，就差不多了。3 人
  19. 如果你想勇攀学习曲线高峰，找时间学习就好，让它变成一种习惯。没有别的方法。不管是想提高编程、数学水平，还是健身、放风筝，甚至是比死亡还可怕的人类第一大恐惧之事——公开演讲，你所要做的只是，迈开脚步，循序渐进。3 人
  20. 编译流程的第一个阶段是语义剖析。3 人
  21. 我能看清很多经验丰富的程序员都看不懂的编程模式。2 人
  22. 你得让自己养成笑的习惯——笑自己，笑别人，笑这个疯狂的世界——否则你最终可能会完全笑不出来。2 人
  23. 我发现到处都有狭隘主义的存在2 人
  24. 程序员在业界和学术界聚集，也会发展出“地方口音”、习惯、禁忌、传说和其他文化副产品。他们形成一个个文化孤岛，然后认定自己的方式是最佳的，而且是唯一选择。2 人
  25. 甚至2 人
  26. Scheme2 人
  27. 它不能自知，因为它不是内省型的语言。2 人
  28. C++就不一样了，它基本上没法解析2 人
  29. 有个亚马逊工程师曾说我们的代码库是座“巨大的屎山，而且是你能见到的最大的一座，每次需要修复什么东西，都得爬到这座山的最深处。”2 人
  30. 要知道，客服部应用程序组是当时亚马逊第一个双披萨组。不管是当时还是现在，他们都是完全自主的。没人跟他们讨论，也没人帮忙，什么都是自己做。他们没有网页开发人员，也没有支持工程师，没有squat 。可以说，除了相当靠谱的工程师和人才培养文化，毛都没。他们也只需要这些。2 人
  31. 但C++有些不错的功能，Java却没有，比如：传引用（给栈对象）、typedef、宏、操作符重载。这些东西有时还挺好用。2 人
  32. 如果程序员本身不怎么样，用什么语言都会写出烂代码。但这个世界上大多数都是这样的程序员。2 人
  33. 拿不定主意的时候，就选择雇这种Java工程师：会好多种语言，讨厌J2EE和 EJB那种海绵般的大构架，会用Emacs。这些都是不错的经验法则。Perl2 人
  34. Ruby2 人
  35. 不久，Perl也会出局。因为有一种叫Ruby的新语言终于被译成了英文。2 人
  36. 就其本质而言，保守主义其实就是风险管理。2 人
  37. 当你从大学（或者高中）毕业，就会面临一个简单的选择，要么继续学习，要么停止。有一个再容易不过的推导方式，可以帮你判断自己是否还在学习。它是这样的：没有痛苦，就没有收获。学习不是件容易的事。如果你觉得容易，那就是在随波逐流，而不是让自己更擅长一些以前做不到的、全新的东西。2 人
  38. 即修复你的代码，然后再也不犯这样外行的错误。2 人
  39. 使用强静态类型系统的人似乎更少做单元测试。不过，这点有可能是我个人的错觉。2 人
  40. 。比如，在被逼无奈的情况下，一个采用CORBA的团队最后可能会给每个接口调用添加一个XML字符串参数，以便在他们一开始选用的死板的类型系统中找到一个“突破口”。2 人
  41. 依赖注入是一种极为复杂的基础结构，作用是让Java以某种方式变得更加动态，但更高级的语言天然就能做到这一点。 而且你肯定也猜到了，依赖注入(DI)也会使你的Java代码库更加庞大2 人
  42. 对于程序员而言，最有用的离散数学分支莫过于概率论。2 人
  43. 代数和线性代数2 人
  44. 学习数学的正确之道应当是广度优先搜索，而非深度优先搜索。你需要先探查一番你所处的空间，记下相关事物的名称、知道所为何物。2 人
  45. 长期热身的意思是：在面试前一两个星期中温习知识并做一些习题。你需要将你的精神调整到在白板上解题的“模式”。如果你能在白板上解决问题，那任何其它的媒介（笔记本电脑、共享文档，无论什么媒介）对你来说都将是小菜一碟。所以你要为白板面试做准备。短期热身的意思是：面试前一晚睡个好觉，面试当天早上做密集、快速的热身练习。2 人
  46. 无论你被问到什么问题，都先以图的思维去思考。图是一种最基础和灵活表现任何关系的方式，随便拿一个有趣设计类的问题都有50%的概率多少与图有些关系。2 人
  47. 请一定确认你实在是没法用图论的方法解决某个问题，再尝试别的方法。这个建议很重要！2 人