读程序员的怒吼

    读程序员的怒吼有感

    豆瓣上买的电子版，12.00￥。

    真刺激啊，读起来群情激奋啊。好玩好玩呢。修炼的越深，越知道世界的不完美。作为程序员我将奋力前行。

=======================================================================================

《程序员的怒吼》——摘抄：

1.划分派别
  
接下来我会随机列举一堆技术、模式、设计和准则类的东西，它们会被划入六个类别：“无派系”、“保守派”、“中间派”、“自由派”，以及“中 
偏左派”，和“中偏右派”。每种分别列举。注意了，这可不是什么精确的科学分析。不过，它可以为下面的举例分析打下初步的基础。


没什么派系性可言：算法、数据结构、具体数学、复杂度分析、信息论、类型理论、计算理论等等，基本涵盖计算机科学的所有理论。有时候
这些理论也会在学术界引发小题大做的争论，但那不过是小鱼塘里种类相似的鱼在相互咬来咬去，是意料之中的事。总的来说，这些基本数学
理论具有普适性，对编程界的自由派和保守派都一样适用。没错，甚至类型理论也是如此。


属于保守派：可靠性可证实的类型系统；强制静态类型标注；非公有可见性修饰符（如：私有/受保护/内有恶狗 
/等等）；严格而全面的模式；凡警告皆视作错误（all-errors-are-warnings）；泛型与模板；选择显式DOM操作和手写状态机，避免使用DSL
（如XPath、正则表达式）；编译依赖限制；API强制弃用；对数值类型不用类型等效性（即不做自动类型转换）；检查期异常；单程编译器；
异常；单级编译器；软件事务内存(Transactional 
Memory)；基于类型的函数重载；显式配置优先于约定；纯函数式数据结构。任何带有“演算”字眼的编程技术都可归入这一类。


属于中间（或绝对中间）派：单元测试；文档；Lambda；线程；Actor模型、回调；异常；Continuations与CPS；字节码编译；即时编译；唯表
达式语言（没有语句）；多方法（Multimethods）；声明式数据结构；数据结构的文本化语法；类型调度。


属于自由派：Eval函数；元编程；动态作用域；凡错误皆视作警告；反射和动态调用；运行时类型信息（RTTI）；C语言预处理器；Lisp宏；特
定领域语言（大体而言）；可选参数；可扩展语法；向下类型转换；自动类型转换； 
reinterpret_cast；自动字符串化；不同类型之间自动转换；视Nil/Null为可重载语义值（如空表、空串或不存在的值）；调试器；位字段；
隐式转换运算符（如Scala中的implicit定义）；多程编译器；完整命名空间导入；线程局部变量；值分派；基于元数的函数重载；混合类型集
合；API兼容模式；Advice和面向方面编程（AOP）；约定优先于显式配置。


属于过度使用会偏保守的中间派：类型建模、关系建模、对象建模、接口建模、函数式编程（即函数无副作用）。


属于过度使用会偏自由的中间派：动态类加载与动态代码加载、虚拟方法分派、面向缓冲区编程。


哇，这样分类还挺有趣！这个列表远不够完整，但你明白我要说什么就好。


这里能看出一些基本的规律：


自由派一般选择隐式；保守派选显式。


保守派一般性能优先；自由派通常是事后优化。


编译时绑定一般是保守派；运行时/延迟绑定一般是自由派。


整体而言，并发和并行像是很有派系之争的话题，但这种分歧和自由派/保守派之争不相关。


我倒是很愿意继续讲这些分类。但是因为还有更重要的东西要讨论，这些就先讲到这吧。


看过下面几个例子，你就知道这种派系现象是多么广泛和根深蒂固了。


案例一：语言
以下是一些非常粗略的分类。要知道，在每个语言阵营里，都有典型的自由派和保守派子阵营。但是整体而言，语言的功能（和优势）往往决
定它的用法，所以语言的文化特性往往取决于它们的功能特点。


变态自由：汇编语言


极端自由：Perl、Ruby, PHP, shell脚本


非常自由：JavaScript、Visual Basic、Lua


自由：Python、Common Lisp、Smalltalk/Squeak


温和自由：C, 面向对象C, Scheme


温和保守：C++, Java, C#, D, Go


保守：Clojure, Erlang, Pascal


非常保守：Scala, Ada, OCaml, Eiffel


极端保守：Haskell, SML


案例二、技术公司
为了好玩，我们来对四个有些类似的技术公司的软件价值观做个对比。
1）Facebook——诊断为：极端自由派。
2）亚马逊——诊断为：自由派。
3）谷歌——诊断为：保守派。
4）微软——诊断为：变态保守。
5）最后再派送一个：苹果公司。诊断为：没概念。他们市场做得太好，所以派系不派系的显得无关紧要了。








2.你如何解决以下问题……（bianyiyuanli）
你是一名程序员，对吧？好，那我给你假设几种状况，看你如何将它们化解。
状况1:你正在吭哧吭哧地写Java代码。你们公司有明确的代码规范。这规范精细到想象力所及的最微小的细节，且绝无商量余地。那你如何设
置你的编辑器来自动将你的代码整理成合乎规范的样子？


状况2:你的公司代码中对AJAX的使用相当频繁，而你的Javascript代码库也日渐增大，几乎与所有其它语言的代码增长的速度一样快。你打算
开始折腾JSDoc，也就是某种意义上JavaDoc在JavaScript语言上的伪克隆版，用它来自动解析你的代码，产生对应的文档。随即你发现JSDoc只
是一个不成器的草包，其本质是一团遇上你的代码有50％机率会内存区段出错而退出的Perl脚本，而且——且先忍我说完——你发誓说你再也不写
一行Perl程序，因为，好吧，它可是Perl语言呢，你自己找一个你喜欢的理由罢。那么你该用什么办法自力更生写出一个JSDoc的代码解析器来
？请牢记，你的解析器要能靠自身之力对你的JavaScript代码进行至少粗略的分析。


状况3: 
你的公司有一个巨大的C++代码库，是长年累月劳动的结晶，参与者众多，没有上百人也有数十人。你发现这些代码需要进行一番伤筋动骨的重
构，譬如说，从32位架构升级至64位架构、或者改换访问数据库事务的操作、或者（老天保佑你）你需要升级C++编译器，而升到新版之后，它
所对应的C++语法和语义又再一次变了。你被授予完成重构的重任。你该如何着手？


状况4：某个同事写出了一套绝妙的新网页版代码审查系统。大家都纷纷转移到了那个系统去。你用了这个新系统一段时间才发现，你很怀念旧
系统中的源代码高亮的功能，因为新系统中没有。你的时间虽然不多，但尚能抽出一个星期的业余时间。那如果你要把源代码高亮功能从无变
有，你该怎么办？（假设你们公司在99％的代码中都用到了多达5至8种语言。）


状况5：你的项目中突然出现了一条有点稀奇古怪的需求：你得要兼容一款新的硬件路由器。这也许是因为项目中充斥的Web 
2.0内容让边界路由器或流量监控器不堪重负，谁知道是什么原因呢。总之，你只需知道，根据系统管理员和网络工程师反映给你的情况，你要
用某种方法直接与路由器进行通信并操作它们。这些路由器有独立的IP地址、Telnet界面和一套专有的命令行语言。你向路由器发送命令，路
由器就回传一些响应。每个命令都有规定的语法和参数格式，但是路由器回传的内容要自行解析（因为回传内容的格式并没有文档描述，不过
你总是可以对其进行反向工程来破译吧），以从中搜索特定的模式，从而知晓何时为你奇幻的上传和下载功能将路由器设为正确的状态。那你
用什么工具来完成这个需求？


状况6：你们公司的项目开始越发有点不对劲。参与项目的工程师都是聪明人，而且都在用最时新的、最好的敏捷开发和面向对象开发的软件工
程原理和编程语言。他们完全无可挑剔。但是因为某些原因，你的代码库还是变得如此复杂，以至于整个项目的完成时间全乱了套。即使是简
单的改动完成起来都似乎遥遥无期。工程师们开始讨论重新设计这个项目。虽然过去五年间，这个项目经历了N次这样的推倒重来，但这一次将
会是脱胎换骨、一口气修理完所有问题的大重修。那你要先给你手的工程师每人发一张什么颜色的纸条？哇，啊不，不好意思，我是问你如何
保证这次他们一定能成功？


状况7：你开了一间小的、轻量级的创业公司，公司里到处都是年轻人。他们染着蓝色的头发、戴着鼻环、钉着舌钉、穿着黑色嘻哈风的衣服、
手持iPhone和各式当下年轻人们喜欢的玩意儿。你使用Ruby on 
Rails来构建你的网站，以目前的用户规模看来这套系统尚能应付。（其实你从未花力气测量过网站的延时与用户数的函数关系，因为你从未想
过这会是个问题。）你最近读到一篇文章，说Rails隐藏着一个极为可怕的安全漏洞，网站用户只需向你的公开网站传送特定格式的GET请求，
即可代表你的公司上传任意内容的公司财报。于是你赶忙下载了新版的Rails，开始阅读其中的单元测试代码，想要找出这个漏洞到底在哪里，
因为开发者并没有明示漏洞的位置。最后结论是你需要对目前的代码进行一番大手术，从中移除一个特定的编码套路（而且这套路很神奇的没
法用grep选取出来），并以人工的方式换成另一种编码套路。那你该怎么办呢？


状况8：有个喝得烂醉的博主给你举了七个奇怪的状况，问你认为这七种状况之间有什么共通的地方。你心里已经有答案了吗？


答案在这儿。什么，你觉得我在用夸张的修辞手法和你说话？
状况1对策：你去游说你的公司，将编码规范改为Eclipse所默认接受的规范，无论这规范与你公司现有的差得是不是十万八千里。


状况2对策：你向JSDoc的邮件列表发信求助，问是否有人遇到同样的问题。有些人说他们也遇到这个问题。然后这问题就定格在了那里，不了
了之了。


状况3对策：你就丢盔弃甲辞职了。哎呀。其实早在你开始解析到第一个逗号时你就知道你要辞职了。


状况4对策：先就这么硬撑着。代码高亮我们不要，它是蠢货专用的。或者你就把GNU Source 
Highlight拼凑进来，一边欣赏着其能覆盖到上古语言Fortran和Ada的解析力，一边凑和着用其破烂不堪的语法高亮结果。


状况5对策：用Perl。这是编程语言中的瑞士军刀。你用这把军刀把自己开膛破肚，光荣阵亡，这个问题也就理所当然转移给了别人。


状况6对策：粉色的纸条（也就是解雇信）。


状况7对策：手动修改。啊，反正你的网站一共也只有10000行程序。跟我一起喊：它只不过是天书般的Rails而已嘛！所以这个问题其实是个圈
套。


状况8对策：有。你就一边翻这篇文章一边用眼睛快速扫来扫去，翻到最后只为知道计算机专业最重要的课是什么。你知道Steve君最喜欢在冗
长的故事最后来个意外结尾，是吧。


这样你就差不多啦。你已经有了足够的本领来应对几乎任何可能在编程中遇到的突发状况了。所以显然你不需要明白bianyiyuanli是怎么回事
嘛。








3.第四章 结束语
如果你真的通读了全书，哇，我表示非常吃惊和感动。如果你还感兴趣，去这些文章的出处，还能找到更多内容。
因为出版到书里的内容需要主旨集中且易于掌控，所以本书只能收录我全部写作的大约百分之十至十五。
如果想见识我剩下的文章，可以在网上搜索“Stevey’s Blog Rants”（是我自从2005年6月以来启用的新博客）
和“Stevey’s Drunken Blog Rants”（堆放2005年6月之前的旧文的地方）。
如果你直接翻到最后一页想知道我有没有加入一节长话短说的全书摘要，那好吧，我想我就在此成全你的愿望吧。


长话短说：


软件开发是有许多方法的。它们彼此不同而又同样合理，而且全都讨厌对方。


杰出的程序员之所以杰出是因为他们勤于练习。


当一门编程语言你用得很舒服时，就是该马上抛弃这门语言去用一门新语言写代码的时候了。


如果成为一名经理是你最想完成的事，那你多半也只能成为一个很差劲的经理。


Lisp虽然很难掌握，但是它是唯一一直以来让我感到快乐的语言。


Emacs虽然很难掌握，但掌握它是一门投资，让我现在享受到了红利。


每过一段时间就要走出你的舒适圈，去学一些新的东西。


自己从头造轮子。这是你能确保它是正确的东西的唯一方法。


要多笑。多笑对健康有益，而且能让你心情好。


你也要笑自己，但不是在公开场合没有缘由的笑。


若你有想法，请别犹豫，联系我。我的邮件是steve.yegge@gmail.com 。我的生活有时会比较忙乱，
所以我并不一定有时间回复每一封收到的邮件。但我一定会看这些邮件，一定会回复评论，也一定会从所有来信中学到一些收获。