梦断代码
出版时间：2011-6 出版社：电子工业出版社 作者：罗森伯格 页数：336 译者：韩磊
Tag标签：无
内容概要
软件乃是人类自以为最有把握，实则最难掌控的技术。本书作者罗森伯格对OSAF主持的Chandler项目进行田野调查，跟踪经年，试图借由Chandler项目的开发过程揭示软件开发中的一些根本性大问题。
本书是讲一事，也是讲百千事；是写一软件，也是写百千软件；是写一群人，也是写百千万人。任何一个在软件领域稍有经验的技术人员看完本书，必掩卷长叹：做软件难。
作者简介
作者：（美国）罗森伯格（Scott Rosenberg） 译者：韩磊罗森伯格（Scott Rosenberg），作家，编辑，1981年毕业于哈佛大学，1995年与他人共同创办了SaIon网站，此后担任其首席技术编辑达数年之久，并负责技术工作。从1986到1995年，一直为San Francisco Examiner写作，最初写剧评，后来又写影评和“数字文化”专栏。所写的剧评曾于1989年获George Jean Nathan奖。在进2kExaminerz前，一直为Boston Phoenix写评、影评和书评。韩磊，技术管理者和作译者。2001年创办CoDelphi.com中文开发在线网站；2003年历任网站总监、副总经理、《程序员》杂志和CSDN网站总编辑等职；2010年加入21世纪报系，现任21世纪新媒体副总经理、CTO。拥有美国Borland“Delphi产品专家”及“微软最有价值专家”称号。曾领导开发多个网站和移动应用项目。译有《C#编程风格（Elements of C#Style）》、《梦断代码（DreaminginCode）》、《代码整洁之道（Clean Code）》，与刘韧合著有《网络媒体教程》，与戴飞合译有《Beginning C#Objects：对象到代码》。
书籍目录
第0章 软件时间
第1章 死定了[2003年7月]
第2章 Agenda之魂[1968年～2001年]
第3章 原型与Python[2001年～2002年11月]
第4章 乐高王国[2002年11月～2003年8月]
第5章 管束奇客和狗[2003年4月～8月]
第6章 搞掂设计方案[2003年7月～11月]
第7章 细节视图[2004年1月～5月]
第8章 白板上的即时贴[2004年6月～10月]
第9章 方法
第10章 工程师和艺术家[2004年1月～5月]
第11章 通往狗食版之路[2004年11月～2005年11月]
尾声 长赌 [2005年～2029年及以后]
译后记
附录A 专有名词对译表
章节摘录
版权页：插图：
编辑推荐
《梦断代码》：人类文明运行于软件之上。但创造软件的艺术却仍旧藏身于暗处，秘不示人，即便对于那些专家也是如此。而 且，做软件的野心越大，败状也就越惨烈。《梦断代码》讲述了米奇•卡普尔开创的chandler开源项目（该项目旨在打造全新的电子邮件和日程安排软件），作者 耗时3年，深入chandler开发过程，书中讲述了该项目和开发者的许多故事，以此来回答“为什么打造超卓软件那么难”。难以做好。难以按时交付。难以使用。跟着罗森伯格在软件丛林里转了一圈，回到现实中，当年米奇•卡普尔辞去OSAF主席一职，并且撤走投资，OSAFAF全职人员也立即从27人减少至10人。一时间外界议论纷纷。六年半时间，上百万美元，几十号顶尖高手，换来幻梦一场，《梦断代码》正可做它的墓志铭。
图书封面
图书标签Tags
无
评论、评分、阅读与下载
用户评论 (总计17条)
- 软件乃是人类自以为最有把握，实则最难掌控的技术。本书作者罗森伯格对OSAF主持的Chandler项目进行田野调查，跟踪经年，试图借由Chandler项目的开发过程揭示软件开发中的一些根本性大问题。本书是讲一事，也是讲百千事；是写一软件，也是写百千软件；是写一群人，也是写百千万人。任何一个在软件领域稍有经验的技术人员看完本书，必掩卷长叹：做软件难。
- 详细描述了一群界内大牛做一个小软件却失败了，没有原因分析和说教，一切都是自然的描述，每个人都能够体会到不同的失败原因。恰恰是这样，如果项目失败了，站在不同的视角都会发现问题，问题是为什么却避免不了？这就是软件开发！
如果你的老板不写代码，给他买这本书读读 - 这本书看了已经一半多了，就看完的这些部分说点自己想说的。开始看的时候，还是很轻松很调侃的在看老外大牛们的囧事。可是越看越发现这个项目里的很多扯淡的事情其实每天都发生在自己的身边。冷汗啊，一身一身的出，想想以前的很多事情，那真是不停的后怕。
做技术的人，尤其是对技术痴迷的人，遇到一个问题首先想到的不是用户的体验，而是自己在技术上的快感。好像不用点什么新鲜的技术就对不起客户似的。其实呢？其实客户懂什么叫P2P吗？懂什么叫SOA吗？懂什么叫AJAX吗？这些其实都不是用户关心的。用户关心的是什么？用户关心的只是实现！只要能实现客户的业务需求，那用什么技术用什么方式真的有很大关系吗？
在国内做项目，尤其是政府项目，都是关系先行。这种形式其实在某个方面给我们带来很大的好处的。其实大家仔细想想如果每个项目都按照合同的约定来完成的话，我们有几个项目是可以收到钱的？我们又有几个项目是可以不失败的？
客户是上帝。可是我们真的是把客户作为上帝，还是把我们自己的技术欲望作为上帝了呢？
终于把这本书看完了，大牛们的项目也终于失败了。看到后期一直在想一个问题。程序员到底是建筑工人还是艺术家？
现在，国内受印度软件外包模式的影响，认为程序员就是建筑工人。一个完整的程序建立过程就是一栋建筑的构建过程。可是在实际过程呢？我们永远无法准确估计进度，就像我们永远不知道下一个巧克力是什么味道。
“好，没问题，月底肯定能完成！”
“哦！出了点小问题，再有一个礼拜吧？”
“程序已经发到测试部了！有没有问题问测试吧！”
“哦！这个我们没有考虑到等等吧，我们尽快！”
“什么？你什么时候说过这个问题啊？”
工程进度！？好像成了一个谜，而且是一个永远无法破解的谜！无法估计，无法考核。程序员总在认为自己的工作不是在累砖和泥！认为自己在从事一个艺术品，可是谁听说过艺术品还有规定工期和逻辑性的？
所以问题还是绕回到最初，我们到底是在干什么？我是为谁在做？ - 用非常多的篇幅，详细介绍了软件开发历史。总体结论是开发复杂软件很难。
- 写的蛮好懂的，关于软件行业的问题思考了很多，对于以后蛮有参考价值的。
不过显得也太悲观了一点。。。 - 这本书道出了软件人面临的困境，共鸣啊~
- 每一句话都值得深思，是作者用多年的时间一直跟踪着一个软件开发小组写下的思考，又不仅限于思考，值得收藏
- 非常喜欢这本书，引人入胜
- 没开始读，应该很不错的说
- 没有想象中的枯燥，很有意思
- 书很旧了，泛黄
- 感觉英文名翻译成中文好拗口哦
- 看着质量还可以，类容看着也还简单。
- 但是内容不如想象中的好
- 封面有撕裂，看上去很不舒服！
- 看起来太啰嗦,太啰嗦
- 简直就是盗版中的盗版中，没见过这么差纸质的