读《梦断代码》有感
这本书大概看了一周多，慢慢悠悠地读了一部分。它刚开始是老师推荐的，现在有机会就在网上搜索到了这本书，就读了起来。这本书读起来很流畅，它并不需要像读一般的技术类书籍一样去理解，我甚至可以把它当小说看。书从一开始就勾引起了我的兴趣，非常明显，它描述的是在日常中能够经常碰到的工作场景，真想知道这些技术大牛们的日常开发也会不会像我们一样。大致速读了几章后发现，虽然这些技术大牛们开发的项目目标比我们伟大多了，但是日常开发遇到的问题也大同小异：比如需求不明确，人员流失，沟通不顺畅,bug难修复等一些很常见的问题，就感觉一下子拉近了我和那些大牛之间的距离。这大概是我在阅读之前没有想到的问题：我从来没有读一本专业书像这本书一样。
看完这本书，难免会有很多的想法，现在我有一些小故事想分享一下（都是在网上刷微博看到的）：
故事一：某位开发人员计划修改一个bug，需要4小时，但是实际上8个小时也没做出来，甚至给他8天也解决不了。文中提到的这个bug最终被解决是在几个月后。有时候让程序员去修改这种棘手的bug，正如这位开发人员所说：有时候，你一觉醒来，脑中灵光乍现，于是迎刃而解，玄学解决问题（不）。
故事二：开发模式的选择。书中提到了“大教堂与集市”这本书，大教堂的模式可以说是传统的开发模式，而集市模式被很多开源项目采用,比如Apache Web服务器,Linux（一大堆让人不想搞懂的名词）。不知道我们以后的开发会选用哪种模式呢。
故事三：历史上有很多失败的项目，就比如FBI耗资1亿7千万美元，为了研发出具有更高反恐能力的计算机的项目，（当然最终失败了，）失败原因是FBI受到９／１１事件的刺激把需求列表陡然拉长（甲方乙方永远不变的话题）。美国国内税务局至今用的系统是20世纪60年代开发的，在95年曾试图升级，但是在它花费了20亿美金后，国会取消了这个失败的项目，失败原因：需求在不断的改变，预算和进度安排不切实际等。04年英国养老金系统全面停止运作，事故原因说起来也好笑：在把７台window 2000升级至window XP时，不小心把升级范围扩展到数千台没准备好的机器上（不论在哪个地方都会出现这种常识性错误呢）。所以，如果你正在做的项目失败了，别太气馁：你不是第一个，也不是最后一个。（不过在周围的人里，你总能感觉坏事只发生在自己一个头上，真的难哦。）
故事四：项目语言的选择。书中提到的项目经过了大家无数次的讨论，最终决定使用Python。但是在项目的后期，另外一个Python高手加入后，曾经隐晦的说过，其实大家在用编写Java代码的方法编写Python（这不就是窜台吗）。这让我想起，虽然大家都说其实语言是相通的，如果你一门语言很熟练了，其他语言也大致相通的。但是毕竟每个语言都有自己不同的特性，所以项目组有机会选择语言的话，一定要去考虑一下主要的开发人员对哪种语言最熟练，在编程里选择最熟悉的语言往往是最好的。（不然肯定要磨叽到哭。）
故事五：以时间来驱动版本的发布。书中提到项目的0.2版是一个很烂的版本，但是还是发布了，因为承诺的发布时间到了。虽然书中的项目组汲取这次的教训，不再以时间来驱动，但是我觉得用时间驱动版本发布也不失为一种比较有效的方式，它让开发人员有一个奋斗的目标，（感觉更多的是压力，）会促使（明明就压力使人干活）程序员尽快完善自己的开发模块。
故事六：GTD（get things Done）,是一本书的名字，这本书的中心思想是让大家把所有要做的事情写下来，让脑子清空。我觉得这种方式挺不错。有一次，我觉得事情太多，一般而言在这样的情况下我都会开始烦躁不安，不知道该从哪件事开始，（然后我就开始拖延，）后来想到这个做法，我就一股脑地把脑子里想的事情全部写下来，然后再一件一件来做。（希望我不要做到一半去摸鱼。）
大概也就是这一些故事，然后加了点感想，（更多的是吐槽好吗，）书是非常有趣的了，我希望以后还能有更多像这样类型的书可以读。（读小说多快乐。）