《梦断代码》是一本由罗森伯格著作，电子工业出版社出版的平装图书，本书定价：59.00元，页数：336，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《梦断代码》精选点评：

　　●写一事而写千百事，读读可以大大增广软件视野

　　●主要讲的是一个软件的制作“历史”，其中历经的各种人事、资金、技术、时间规划等各种问题。当时看的时候还不太懂，以后有机会再看一次

　　●作为失败的案例是比较成功的。

　　●~~~~~~~

　　●软件开发为何不能像工程建设一样，标准化？组件化？

　　●一个悲惨的软件的开发故事，一门悲惨的工程学。看了这本书才跳出代码，综观整个软件工程学。非常独特的视角，译名很棒，绝对的梦断。。。说魂断都不为过 :)

　　●边学软件工程边读这本书整个人都不好了，正如译者在最后所言：“六年半时间，上百万美元，几十号顶尖高手，换来幻梦一场......在那软件的花园中，还有多少会渐次凋零呢？”

　　●写一个失败的故事，当小说看还不错 / 有前面的铺垫，再看第九章第十章也不错 / 「养孩子难。葬先亲难。出生和成长；与人同住或无人相伴；尝试去爱；无法去爱；接受他人之死；接受自己之死——都很难。」

　　●一个立志超越outlook的开源项目，六年半时间，上百万美元，几十号顶尖高手，换来幻梦一场。这本书讲述了项目全程，也探讨了那些从有软件开发开始就始终存在的困境和噩梦，包括软件开发是科学工程还是文学艺术这种深奥话题，并一如既往的没有答案。

　　●结构性不好

　　《梦断代码》读后感(一)：很有感觉

　　学习计算机这个专业也有两年多了，有时候很迷茫，不知道自己该学些什么，偶尔在图书馆看到了这本书就借来看看，一看就欲罢不能，这几天心情有些不好，多亏了这本书让我度过了周末，这本书写的不错，让我学到很多，做软件真的不容易，做好软件更难

　　《梦断代码》读后感(二)：Computer science is NOT a science, software engineering is NOT an engineering

　　看完《梦断代码》以后，我一直在思索这本书的主题是什么，想了半天也没有头绪。翻到书一开始的《作者的话》，看到这么一句：「它提出问题，讲述故事」，啊哈，确实如此，作者回避给任何问题一个标准答案，甚至一点倾向都没有，以一个中立的观察者来讲述故事。好的书不仅在于传递知识或观点，更重要的是引发思考。这正是我给本书五星的原因。

　　确实，整本书主线在描述Chandler项目的故事，不断从项目的各种现象中挖掘软件开发中的各种问题，并旁征博引其他项目的故事，罗列大家对问题的各种观点和方法，但是几乎所有提到的问题直到今天都没有明确的结论，比如卡普尔和卡兹维尔的对赌：2029年会不会有计算机通过图灵测试。

　　所有问题的根本是：

　　软件开发是否能找到一个合适的方法论

　　软件开发者是工程师还是艺术家。

　　这个问题，总结了软件开发过程中无数细节问题，这些问题统统没有答案。软件开发领域的圣战比宗教中的还要多。从项目管理到软件设计，只有模糊的建议，以经验性方法为主导，估算工期的方法叫「拍」，拍大腿抑或拍脑袋。从代码到项目形态无不千奇百怪。

　　这本书隐约夹杂着一种无力又沮丧的情感。虽然成书之时Chandler项目还在继续，但是直到现在也没能推出能用的产品，项目可以说是完全失败了。项目中遇到的种种问题，至今也没有答案。

　　扯一些自己的理解。到底为什么不能像造桥一样开发软件？造桥和软件开发的区别在哪？软件开发领域惊人的熵，一方面在于所面向问题域的范围广泛，另一方面在于软件本身技术的高速进化发展，这两方面相互推动。

　　桥梁工程、建筑工程以及其他传统工程行业发展至今，面向的问题域已经非常固定和精确。而软件行业所面对的问题域却是无时无刻在变化的。1000年前的桥现在还在使用，而我们写的软件能用多久，10年？按现在互联网行业的状况，如果一年不做更新就被市场淘汰，10年之后，估计都找不到能运行程序的环境。

　　计算机技术近20年的发展速度有目共睹，从硬件到软件，技术更新换代速度之快，任何行业都望尘莫及。如今绝大部分的建筑都是钢筋混凝土结构，而常用的通用编程语言不下10种，各类编程框架更是数不胜数，并且在不断变化，如此对比可见一斑。何况写代码只是软件工程的内部方法，横向来看，软件工程的内部问题又包括计算、控制论、系统工程、人机交互等等。

　　这样来看，软件开发中遇到的问题，一方面是对问题域的理解和抽象的问题，另一方面是对软件开发技术本身的理解。软件开发团队，需要同时应对这两种难题

　　能不能像造桥一样写软件的问题，被细化分解成了两个问题：

　　软件工程的问题域什么时候能够收敛？

　　软件技术本身何时能够稳定？

　　这又是两个无法作答的问题。。。挫败感顿起

　　或许软件工程正好处在一个这样的阶段，刚刚兴起，发展迅速，体系模糊。亦或者软件工程并不是一种工程，它只是别的真正的工程领域中解决问题的工具。不过这个工具很复杂，材料是代码，建造方法是计算、系统工程和人机界面。Who knows.

　　《梦断代码》读后感(三)：软件开发的那点事，梦想和现实的差距

　　本书所谈到的内容，无外乎在证明软件开发确实是一件件颇为痛苦的事情——以Chandler为主线，讲述了这款PIM工具从筹备到诞生的过程，其间穿插了各种小故事，反映出来的问题，均是现实工作中真实存在的，甚至多数是现在还能见到的（意味着什么，我就不明说了）。

　　之前用过Chandler，感觉功能不尽人意，得知它也纯属看了它的新闻，一时好奇才去安装使用。如同之前所了解到的一样，Chandler一直处于很纠结的状态，所以无法落笔进行设计。和文中所提到的内容一样，团队将Chandler想象得过于重要，收集了过多的需求——过度设计了，导致在实现的过程困难重重。

　　另外，除了Chandler这条主线外，书中还穿插了很多小的故事——基本上现在各种熟知的语言、软件，如Python、Java、Wiki等都在书中有提到。

　　把软件和工程关联在一起，本意是没错的，可是你能想象的到，一幢设计好的大楼在建筑过程中又要改来改去，甚至可能推翻之前的一些——这种楼你敢住吗？没错，国内很多软件相信都是这么来的~

　　文中提到，要解决当务之急，轮子到处都有，关键是要合理利用。反观国内很多企业，从不考虑利用的问题，而是不断地发明轮子（至于到底是不是自己发明的就不得而知了），还高举着“自主知识产权”的牌子，真实令人无语。

　　反思目前的公司，不会做集成，工具其实都还可用。公司喜欢重复发明轮子，不解决当务之急，而是取远水（投入大量人力物力，如同Chandler一样，还木有影呢——据说要实际投入使用得明年或者更晚……）。想想，公司还真是有钱有时间啊……重新发明轮子，那总得有突破吧？关键问题是没有新的东西（代码重新敲一遍就成自己的了？）。

　　感慨的东西不少，以后再一点一点结合实际反思。

　　不过，Chandler现在怎么样了？最灵活的数据结构是XML么？

　　下面是一些摘录的内容：

　　只有在任务能够分派给许多互相之间无需沟通的工作者时，任何月才可以互换。

　　注重序列约束，避免先决条件处理出现问题。

　　从小项目开始，而且永远不要期望它变大。如果这么想，就会做过度设计，把它想象得过于重要。更坏的情况是，你可能会被自己想象中的艰难工作所吓倒。所以要从小处起步，着力考虑细节。别去想大途径和好设计。如果项目没解决某些眼前的需求，多半就是过度设计了。

　　大型软件生产已经成为一种管理上的恐慌事务。它常被看作是无利可图的沼泽，既费钱又没完没了。

　　抽空了解的内容：

　　A、祖尔测试（Joel Test）——不会叫人头疼的CMM：

　　1. 你们使用源代码控制吗？

　　2. 你们每步都做构建吗？

　　3. 你们做每日构建吗？

　　4. 你们有缺陷数据库吗？

　　5. 你们会在写新代码之前修复缺陷吗？

　　6. 你们有与当前工作吻合的进度安排吗？

　　7. 你们有规约吗？

　　8. 程序员工作环境安静吗？

　　9. 你们采用了市面上最好的工具吗？

　　10. 你们有测试人员吗？

　　11. 你们会要求应聘者在面试时写代码吗？

　　12. 你们做走廊可用性测试吗？

　　、BaseCamp，RoR，37Singal的设计哲学

　　C、SketchPad的输入时间、日期的方式十分高效。

　　D、Big Design Up Front

　　《梦断代码》读后感(四)：时间轴+读书笔记

　　* 读这本书真得是消耗了太多的精力，倒不是书不好，而是自己太浮躁，很多书读不进去。

　　* 第一次借这本书应该是2019年，没看几页就满30天，还。

　　* 第二次是2019年初，毕业前，还是读不进去。

　　* 这一次是2019年2月，在独墅湖图书馆借的，超期60天，终于字啊5月5日看完。

　　* 其实真正看这本书，加起来也不到一周时间，27万字的非技术书籍，不需要花太多时间，可我这过去的90个/800多个日夜，都做了些什么呢？

　　* 喊了无数遍浮躁，从来没安静下来过。

　　终于读完了，长嘘一口气，记了3700字的读书笔记，贴上来分享下吧，虽然有点乱。

　　时间轴

　　* 2002-10 第一个官方声明（挖了很大一个坑，群众的期待太高）

　　* 2002-10 kapor start to write blog

　　* 2002-11后台工作陷入困境

　　* 2003-01-底 第一次集成~

　　* 2003-02-20 pre-alpha发布

　　* 2003-03 toy到岗，development manager，制定开发计划

　　* 2003-04-21 v0.1 第一个公众预览版，24小时15000次下载

　　* 2003-06 roy开博客

　　*

　　* 1. 反思进度为什么特别慢

　　*

　　* 更民主，缺少等级结构

　　* 遵从集体意见，作决定很慢

　　* 等级结构是把顽固程序猿组织起来的有效手段

　　* 在网景，写代码是重中之重，解放人力有助于写代码就是好决定；在OSAF，很难为写代码扫清障碍

　　* 2. 新项目，重起炉灶，不确定性大

　　* 3. 幻想多于代码；hertz让开发者停止设计，开始编码->先干起来，再变成大东西->激情开干，然后顺其自然

　　* 2003-07-17 第一章 死定了

　　* 2003-09-25 chandler v0.2 比v0.1还差

　　* 2003-10 首席开发经理 micheal toy辞职

　　* 2004-02-26 chandler v0.3 包括CPIA的工作版和更新的资料库

　　* 2004-05-18 老大kapor宣布退出团队会议，不负责细节，授权给经理自治

　　* 2004-04-01

　　*

　　* microsoft宣布longhorn推迟发布

　　* google在愚人节发布gmail，包含很多特性，比如邮件不用文件夹，用搜索，AJAX

　　* osaf和ms都步履维艰，新一代产品以web形式出现

　　* 2004-09-07 开始用贴纸而不是excel记录work item->v0.4 27张，v0.5 45张，v0.5 33张，v0.7以后33张，太多了->此计大秒

　　* 2004-秋天 v0.4

　　* 2005-03-29 v0.5

　　* 2005-11 v0.6

　　* 人物表

　　*

　　* mitchell kapor 莲花创始人,OSAF发起人，资助者

　　* michael toy

　　*

　　* rogue龙与地下城

　　* SGI部门管理

　　* 网景创始人之一

　　* andy hertzfield / matintosh kernel

　　* john anderson系统架构师，mac

　　* lou montulli

　　* jed burgess新手

　　* katie parlante，stanford girl , 新手

　　* roy & aleks totic，在网景发家，后来在湖边无所事事，又出来干活。干了6个月后离开chandler，“我太具破坏性，想把事情快速地推动起来，组织里有些人希望谨慎，安全的开发方式”，roy去eclipse做python模块, aleks回湖区搞创投

　　* chi-chao Lam,PM

　　* Pieter Hartsook,PR记者，分析师

　　* David McCusker 数据存储

　　* jage jibs-stanford GUI

　　* mimi Yin，UI designer

　　* lisa 杜索特:2004-03加入，负责webDAV标准

　　读书笔记

　　* 我看到了什么：

　　*

　　* 很多软工的名言/总结（摘录于书中）

　　* 硅谷不同工程师的生活

　　* 只有任务分工给互相无需沟通的人，人和月才是可以互换的

　　* 软件受到“序列约束”，限制了任务的分解程度

　　* 开源：

　　*

　　* 只要有足够多的beta半测试人员和开发者，bug发现很快(这是chrome区别于IE的地方，商业公司也能用开源的思路开发软件)

　　* 反对声音：

　　*

　　* 技术支持少

　　* 分支，另立山头

　　* 莲花的anenda失败

　　*

　　* 太超前

　　* 错过公司的战略，无辜牺牲

　　* 创新和灵活性对于用户来说太多

　　* 写软件灾难的书很多

　　*

　　* 《软件开发滑铁卢》《死亡之旅》《软件极限》

　　* 故事总是这样的：一群激情洋溢的程序猿，面对棘手问题，被坏经理/需求。。最后等会计师和律师收拾残局

　　* 没有银弹

　　*

　　* 构建软件系统最难的就是精确定义要做什么东西

　　* 选项太多，随性而为，心血来潮

　　* 后台陷入迷宫后

　　*

　　* 请别重复发明python和zope，开发者已经创造出来，积累大批绝佳的技术财富

　　* 做好项目的关键在于复用，继承成功经验，而不是重造轮子。

　　* 看看用多少代码就可以写出来吧

　　* 《人件集》

　　*

　　* 程序员喜欢写代码

　　* 而不是看文档，看别人的代码

　　* 同等条件下，喜欢重头设计制造

　　* 不肯研究别人，甚至都不看一眼

　　* =>开源和google改变了这种情况，缩短寻找的时间

　　* per/python也提供大量的库，省的耗时造轮子

　　* 库多了，也会搞不清哪里有，会重复

　　* =>信息过载是最大挑战！

　　* sourceforge/github上面肯定有人造好了，只是：找不到/找到太多选择

　　* 可复用软件悖论

　　*

　　* 总能找到满足大部分需要的代码，然后，那部分做不到的，恰好是这个项目需要创新的地方->创建项目的出发点~

　　* 他基本上一事无成，不管原因何在，总之就是没做出东西来。

　　* 他开始干，而且做到了， 尽管有点脆弱~

　　* toy他具有衡量好的development manager的唯一资质：有据可查

　　*

　　* 不擅长处理人员事务：指导、绩效考核等

　　* 《硅谷革命》revolution of vally

　　*

　　* 回忆macintosh岁月

　　* 软件开发对【绩效考核】有天然的抵抗力

　　*

　　* 行数不是衡量好参数

　　* 难以划分成难度或尺寸相似的单元，时间也估不准，bug修复的难易也不同

　　* 不同程序员生产力差10倍，配置人员和预估时间一样充满挫败感

　　* Linux对做大型开源项目的建议：别做大项目

　　* demo day很有效果，每次例会让大家演示小进步，使大家欢腾

　　* 特性驱动还是进度驱动？两者都有

　　* 【布鲁克是法则】人月神话

　　* 跟踪进度是为了协调工作，而不是表扬和批评谁。//要求两周发布一次里程碑，但是这也耗掉了很多时间

　　* 【招人】如果多招一倍的人呢？第一年会拖慢进度，第三年才会开始有回报->可是我们的work item大概是两年时间->懂了

　　* 【工作环境】环境宜人，午餐很好，时间弹性，气氛融洽。mimi yin可以早上去上瑜伽课，晚点到；某人可以在西雅图一个岛上工作，几个月来一次bay area

　　* 【软件开发计划】

　　*

　　* 提供详细计划和日程安排， watts humphrey,IBM OS360项目管理大师

　　*

　　* 1. 计划是强制性的

　　* 2. 计划是自底向上，由程序员的经验而来，而不是管理者拍脑袋和市场期望而来

　　* 后来watts做出CMM模型

　　*

　　* 第一级什么都没做

　　* 第二级组这做些计划，跟踪，配置管理

　　* 第三级定义过程，如何工作，如何完成任务，可训练的事项

　　* 第四级有跟踪自己工作的框架

　　* 第五级持续改进过程

　　* 瀑布模型

　　* 螺旋模型，更快迭代周期的小瀑布

　　* Kent Beck等17人： Agile software development

　　*

　　* XP extreme Programming

　　*

　　* 适用于有经验coder组成的小团队

　　* 先写测试

　　* 和客户一起

　　* 结对编程，多人看

　　* Joel spolsky on software

　　*

　　* joel test: 12 question

　　*

　　1. source version control

　　2. step build？

　　3. daily build

　　4. bug datebase

　　5. fix bug before write new code

　　6. work item match work doing

　　7. rules

　　8. quiet environment

　　9. best tools in the world

　　10. tester

　　11. write code when interview

　　12. 走廊测试（随便拉个人过来做测试）

　　* 12分最佳，11可以接受，10分以下很差，因为微软一直是12分

　　* 微软质量高，但太慢。

　　*

　　* 就像军队内务，保持战斗力，但耗时间。

　　* 微软80%-90%时间都在做内务

　　* 37 signals

　　*

　　* 一个在丹麦的程序猿搞定，只做web,因为时差，每天讨论时间很少，程序员专心工作

　　* 用ruby，后来把框架抽出，就是ruby on rails

　　* “灵活性被过分高估，约束才是解放”，约束程序员的可选手段，让编程更简单

　　* google也是小团队，开发周期紧迫，上线再根据反馈改进

　　* 更多阅读

　　*

　　* chrome的开发方式

　　*

　　* http://en.wikipedia.org/wiki/Google_Chrome

　　* http://www.niallkennedy.com/blog/2008/09/google-chrome.html

　　* 开源的团队！

　　* 每次build，都依赖很多外面的东西

　　* cm的开发方式，steve Kondik

　　*

　　* 第三方rom,短时间内发布最新android的优化版本

　　* 3000+ development & user

　　* 7人核心core team

　　* 市场

　　*

　　* 很多厂商没精力升级非主力机型的rom，cm吸收这些用户

　　* 硬件成熟使得rom作用越来越大

　　* 中国是主要市场，有一切：用户，rom，碎片化生态圈，没google的控制

　　附我的短评：

　　精彩的软件工程故事书，讲的不仅仅是chandler开发的故事，还引经据典，讲述和总结了很多其他软件的开发过程/不同软件开发理念等等。

　　初期看这本书，其实是想了解基金会+开源这种软件开发模式。

　　读完这本书，发现看到的不仅仅是chandler的开发，也是很多其他软件的开发过程。

　　内容很丰富，很适合作为软工入门学生的科普书籍。如果我是老师的话，我会推荐这本书给本科生。