Dreaming in Code读后感摘抄

　　《Dreaming in Code》是一本由Scott Rosenberg著作，Crown出版的Hardcover图书，本书定价：CDN$ 34.00，页数：416，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《Dreaming in Code》精选点评：

　　●在书店读过中文版

　　●感觉一般

　　●yeah, we fucked up, but it's not my fault.

　　●作者语言很有趣~~。。。比unix思想里的geek幽默有意思多了。。

　　●我同意，一个人开发软件，效率最高。

　　●看不出感觉来。。。

　　●以前读过中文版

　　●这是一本好书 只想解答一个问题: WHY Software is SO hard?

　　●真是train wreck in slow motion。。这书很适合给不是dev但要和dev打交道的人科普+打预防针。对dev来说这种案例太似曾相识了，一路看下来只想呵呵呵呵呵。事后诸葛地说，一开始就严重over-engineering，对核心技术Python+wxWidgets没经验，对P2P同步这样可以做学术研究的课题一直只有空想，不玩脱倒怪了。问题是一开始就背负了那么大的抱负，这些问题又怎样避免？

　　●Fabulous！！

　　《Dreaming in Code》读后感(一)：软件工程案例分析经典之作

　　在合适的时间，遇到了合适的书。从事软件行业这几年，有诸多感触，和书中描述的基本是一致的:

　　1.项目的工作量无法准确预估；

　　2.要打造一个产品，远比最初估计的难得多；

　　3.需求，需求远比开发本身重要，最难的是决定要做什么，而不是如何做；

　　4. 不要过度设计，重造车轮，框架，顶层设计，从可行的简单方案开干；

　　5.选择比努力更重要，做正确的决策。

　　以史为鉴，可以少被坑，可惜的是程序员大多是自娱自乐的自闭症患者，也不会去翻历史资料。其实早在1968年，就有一群当时的专家聚集一堂，讨论软件为什么那么难。看看1968年NATO软件工程大会上的报告里的建议吧:Small teams.Feedback from users early in the design process.Do something smal, useful, now. It should be easy to explain.

　　Those who cannot remember the past are condemned to repeat it.

　　软件工程到今天还没有脱离手工作坊作业阶段，所谓的各种方法论:CMM, 敏捷,XP，都不是真正的解决方案，只能说解决了特定范围的一定问题 。2015年的今天，依然没有银弹。

　　此外，从Chandler的开发曲折之路可以发现，其实国外程序员也是人，十几号人折腾了三四年，也没有弄出一个像样的产品来。不过，可能要怪的不是程序员，方向比努力更重要，Kapor和项目管理者，以及需求和设计团队的决策才是最大的失败。毕竟，如果决定了要做什么，做成什么样，问题就已经解决了一大半，但是管理团队既没有决心，也没有能力把产品设计做好。即使一开始选错了有没什么关系，倒是先做出一个有用的东西来啊。

　　《Dreaming in Code》读后感(二)：外国大牛也不过如此

　　花了一周的时间，看完了《Dreaming in Code》（梦断代码），看得我心潮起伏。对里面那帮家伙的评价也起起落落。最终的结论是：外国大牛也不过如此。

　　别看他们名头那么响，做了那么多超有名的项目，实际的能力（软件开发能力与项目管理能力）看来相当有限。感想很多，想到一点说一点吧。

　　1、以前有一篇文章叫“谦卑的程序员”，有这么一段话：“优秀的程序员很清楚自己的能力是有限的，所以他对待编程任务的态度是完全谦卑的，特别是，他们会象逃避瘟疫那样逃避‘聪明的技巧’”。但是，那些所谓的大牛，却一点的不知道这一点。一开始他们就决定要做一个桌面软件，然后打算用python+wxWidgets来实现。到后来我才知道，这帮家伙居然一个都不懂python的桌面开发。那个他们伟大的梦想——要打通所有的数据间的隔阂——究竟意味着多少技术难度，他们心里也一点数都没有。总之，这些“大牛”，让人想到的是自我感觉良好的“半瓶醋”。他们的目标太伟大了，这是我在看到这本书的中段的时候的体会。技术要最新潮的，软件要革命性的，要平台化以支持插件的，用户体验要最好的，代码要开源的，唯独工期是不确定的。越是伟大的目标，越是需要强有力的风险控制能力。再引用一遍范总的格言：“欲望不要超过能力”。而他们，就根本没有意识到自己的能力严重不足。

　　2、一个team中，牛人太多了！如何才能良好的合作呢？他们永远在开会，却始终议而不决，大家都是管过“大团队”的。要他们几个人合作起来Coding，就太难了。

　　3、还有一个证明他们不是“大牛”的证据是，他们缺乏技术决断力，那几年里流行起来的很多技术，他们都有随波逐流的冲动。比如他们尝试过RDF 来描述数据；尝试过Python的ZOPE；憧憬过P2P（但是他们的团队里没有一个懂P2P的）；企图从wxWidgets转到Mozilla的 XUL。。。怎么说呢？这样的摇摆和见异思迁，简直是典型的初哥的作风。真正的大牛，对于技术的趋势，以及如何在项目中运用，心中都自有判断的。

　　4、据说Chandler 1.0也正式发布了，我去下载了一个，希望能够有惊喜发生~~还是奇慢无比，根本就不具备实用价值！

　　5、如果是我来做这个项目的话，首先就不会在这么多个方面同时冒险。其次，在项目开始之前会先安排一个技术可行性的研究阶段。最重要的一点，我会早点把不称职的“大牛”开走。

　　《Dreaming in Code》读后感(三)：读后感（III）远虑和近忧

　　完整评论：

　　Kapor 的团队看起来非常重视“远景”， 他们似乎没有近忧 - 这也许是致命的。

　　他们对于软件的基本架构/infrastructure 非常关心，例如对于存储系统，它们提出了下列需求：[p103]

　　it has to make life easy for the Python programmers

　　it has to operate efficiently over a network

　　it needs to be able to handle very large individual date items and very large numbers of items

　　it has to be reliable, using database "transactions."

　　it has to support searching and indexing

　　[0] User experience //Kapor 后来加上去的，似乎不相干的一条远景。

　　后来对于Data Storage，又有如下构想：[p109]

　　rovide programmers with as revolutionary a data model as users

　　data can live anywhere.

　　Data is safe from corruption.

　　Data is quick to get.

　　Data can be large.

　　非常令人佩服的远虑。 如果一个项目能同时实现其中3个目标，就已经能实用并吸引客户，开始赚钱了。 但是Chandler 项目的同志们不满足于只实现两三个，他们要实现全部5个梦想。

　　一群牛人在 “没有近忧，只有远虑” 的条件下讨论问题，最后只能议而不决。 在一次次延续到深夜的讨论中，有人感慨 - "How is this night different from all other nights？" //[p110]

　　没有近忧，或者说不用为近忧而负责 - “我们这个月的目标没完成不要紧，但是我们的远景一定要讨论好”。 导致了项目不能收敛 - 一个项目的一个里程碑中，不确定的事情应该越来越少，bug 也越来越少，直到产品发布。

　　Making firm technical choices was hard in the absence of a settled design, and settling on a design was hard in the absence of a technical roadmap. [p150 - 151]

　　正因为大家没有近忧，所以大家可以继续等待，设计要等技术决定后才好做，而技术的选择要等设计决定后才好开始。就这样，大家折腾到2005年的时候，他们才从高瞻远睹的远虑的云端中下来，有了第一个脚踏实地的计划：

　　ut for the first time, at least, they could see they had a plan grounded in reality, rooted in estimates that ... [p232]

　　Kapor 毕竟是聪明人，很多年以后，他说到了教训：

　　We've consistently overinvested in infrastructure and design... [p342]

　　收敛的另一个特点是 - 做过了的决定，就要执行，不要反复。事实上，Chandler 团队在很多决定上摇摆不定。 架构师Hertzfeld 度假回来，发现他带领其他同事奋战一个夏天得到的 Document Architecture 被扔到一边，原来 Kapor 决定 “We'll have to come back and realign things” [p168]。 如果你是做义务劳动的 Hertzfeld，你还能做下去么？

　　回到 “远景”， 我相信几乎没有合适的解决方案能满足“远景” 中的所有要求，很难找到 “多快好省” 的解决方案（书中提到 fast|cheap|good 不能兼得，这也是MSF 中 time | resource | feature 三个元素的矛盾）。但是往往存在若干方案，从不同的角度逼近最优，但是有各自令人讨厌的缺点。我们能否有智慧来选择这样一个方案，把近忧，远虑都慢慢解决？

　　我自己在微软正在做一个创新项目，前几天一位加入这个项目不久的优秀的开发人员对我说，我们去年设计的数据库问题太多了，如果我们早就像我这样设计，估计会好很多。我不是数据库的专家，我只能对他说，如果我们当时坚持要做到今天这样才发布，这个项目也许就做不到今天了。

　　换句话说，正是因为早期那些不完美，但是及时的设计，让后来者有挑剔这些不完美的奢侈机会。

　　我们每个人在使用这些不完美的软件（Windows, Outlook, 甚至Linux）的时候，都应该感谢当初设计者做出了正确决定，而那些坚持完美设计远景的项目，它们都到哪去了？

　　《Dreaming in Code》读后感(四)：读后感 (I) 驱动和责任

　　几个星期前，我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》的中文版 《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了中文版，也有一些感想如下。

　　1）驱动

　　到底是什么驱动程序员和管理人员，测试人员长年累月投入到一个软件项目中去？

　　有理论认为，传统的软件公司用工资，职位，绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作（大教堂/Cathedral模式）。其实，用开源，社区，共享的模式会更好（集市/Bazaar模式）也许更好。正如在第26页所说的 [所有页码都是指英文版]

　　... it maps an alternate universe for programming in which time is simply less important because the work is cooperative rather than corporate, the workers are all volunteers, and the motivation is fun and ego, not financial reward. [p26]

　　这理论听起来很好，但是我想起了两个故事：

　　1) 美国的一个肥皂剧Seinfield里有一集，讲了一个混混Kramer 热心地加入了一家公司，义务打工，起初他的口头幽默和热情感动了团队，领导委以重任，不料Kramer 根本没法儿把事情做好。最后领导只好找他谈话，Kramer 承认自己不行，他说- 但是俺是义务给你们打工的！ 领导说，对，这就是让我们为难的地方。。。

　　项目中来了一位“义务打工的”，照理说，对项目只有帮助，而且别人是“义务”，你怎么好意思把别人赶走？

　　2) 我以前在西雅图的时候参加过一个非营利组织，成员们都是有热情为社区服务，而且义务付出。但是后来有些成员就逐渐找不到了，一些事情也不了了之。 由于大家都是义务贡献，你没法如何要求别人。

　　在Chandler 项目中，Andy Hertzfeld 就是这样一个义务作贡献的大牛。但是他也遇到了同样的"志愿者问题" -

　　They don't know whether to count on you or not. And because you're not getting paid, there's lack of control. [p167]

　　后来这位Hertzfeld 也拍拍屁股走人了，大家可以为 fun 和 Ego 一起工作，但是如果fun 和 ego 都得不到满足，那motivation 也会急剧下降。

　　2）责任

　　和驱动紧密相关的，是责任 - Accountability.

　　在 Hard Drive 这本书中，讲了这样的故事 - 由于Windows 一再拖延，BillG 最后跟 SteveB 说 - 如果今年下雪之前Windows 还没出来，你就别在这儿干了。 书中没有详细讲 SteveB 回头来又和他的团队讲了什么，但是第二天一个员工背着睡袋进驻了办公室。

　　很多年以后，Windows Vista 也经历了很长的拖延，在又一次宣布拖延之后，人们发现 Windows 团队中一个赫赫有名的 VP 已经卷起铺盖走了。

　　我们回过头来看，在Chandler 项目长达7年的拖延中，有没有发生过各位项目管理者引咎辞职的事？ 好像没有。 [有不少人离开，但是没有人直接为项目延期负责] 既然我上一次拖延没有什么惩罚，那我为什么一定要拼了老命要避免下一次拖延呢？

　　在传统意义上的软件公司，如果项目延期，那项目原计划的收入就拿不到，拖延的时间再长一些，员工就得走人，否则整个公司都被拖垮了。在“集市”，社区，共享的模式下，大家都是义务，大家都在玩票，大家都做贡献，但是对最终项目不直接负责任，那到底谁负直接责任呢？

　　在《移山之道》 中，我讲了下面的例子：

　　阿超：我今天在“顶球”网吧看到大牛他爹在下棋，围观者支招的不少，有的说上马，有的说拱卒，有的说出车。大牛他爹一会儿招法就乱了，眼看局势不灵了，围观者一哄而散，老崔后来也没法，只好认输了。

　　一个围棋国手在一次重要的对局后，听到旁观者对棋局的进程有很多不同的看法，他也没有过多争辩，只是说：“无责任的旁观者和有重大责任的当局者的看法自然是不一样的”。

　　无责任的旁观者在支招后，如果不灵，他可以面不改色地继续支招，甚至可以给另一位对局者支招，不管最后谁输谁赢，旁观者随时都能安心地离开，回家吃饭。有重大责任的当局者在走了损招或败招之后，他很可能就要认输下台，丢掉比赛的奖金和头衔。

　　我在清华大学的这一次《现代软件工程》课，我发现有些学生好像不是特别投入，后来了解到，由于申请学校用的GPA只计算前三年的成绩，第四学年课程的分数就和申请学校没有什么关系了，所以比较“鸡肋”。有一个同学说，如果这门课是在第三学年，那许多同学们会非常计较分数，排名。现在，只要能过就可以了。怪不得一两个项目中出现了 “花最少的努力，能过就行” 的心态。

　　一个软件团队可以制定出动人的远景/Vision， 但是如果大家没有搞清楚驱动项目的各种因素和每个角色应付的责任，那Vision只是一句话而已。

　　《Dreaming in Code》读后感(五)：读后感（II）交流和时间

　　[part 2]

　　时间和交流：时间对每一个人都是公平的，对每一个软件项目也是这样。

　　early all software projects require only 1/6 of their time for the writing of code and fully 1/2 of their schedule for testing and fixing bugs. But it was rare project manager who actually planned to allocate developers' time according to such a breakdown. [p17]

　　书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。 随着人数的增加，依赖关系的复杂，新手，老手员工之间的不同步，交流的成本会随着几何级数增加。在这里插播一个有奖竟猜：

　　当Windows 研发团队在开发Windows 2000的时候，团队内部每天有多少封e-mail 交流？

　　a) 90

　　) 900

　　c) 9,000

　　d) 90,000

　　对每一个团队成员来说，他/她不仅要完成手头工作，还有报告自己的进展（通过email 或其他形式），回答别人的问题，了解其他人的进展。每个人的时间都是有限的，那怎么能保证我们在应付所有的交流/沟通之后，能有时间完成“手头工作”？

　　一个微软的同事前两天跟我说，他们最近没写什么代码，集中精力做“planning” 去了，大家写了很多PowerPoint，改了很多PowerPoint。然后给VP, General Manger 做了两轮汇报，然后根据VP们的意见再修改，再汇报。。。 PowerPoint 的风格变得非常专业和花哨，但是他们仍然没有完成Planning，进入实质开发阶段。华丽的 PowerPoint 中的每一个条目，也需要花PM 很多时间才能写明白，让VP 了解，同时也要花一线dev/test 很多时间才能实现，但是VP，PM 和 Dev/Test 面对同一个条目，他们心里想的是同一回事么？

　　外部交流

　　在Chandler 项目中，幸运的是，他们没有这么多VP 要汇报 （真正的VP - Al Gore 只露了一个小脸），但是我注意到他们用于交流的时间也非常多。例如

　　Every day the developers shared a chat room via Internet Relay Chat (IRC) [p139]

　　1 internal and 4 external email list set up.

　　logs, wiki's...

　　这些都是花时间的！我看到团队成员还要回复素未谋面的爱好者的各种问题（例如质问他们为何不用某某框架，等等），当然这种透明度也满足了很多人的好奇心，开源，社区的优点么。。。 另一方面，项目管理人员发现他们面对着大量的任务没有时间完成。就像第一章 Doomed 的开篇就说到：

　　John is doomed, he has 500 hours of work scheduled between now and the next release... [p11]

　　团队中其他人也好不到哪里去。那在这种情况下，是花时间继续参加各种讨论，blog，提供Transparency，满足大众的好奇心，还是集中精力把自己“手头的事” 搞定？我从书中没有看到经验丰富的管理人员这时候采取了什么措施。事实上，在产品发布之后，没有证据表明，那些在IRC，Email，BBS 上发了很多议论的爱好者未必真正下载并使用你根据他们的意见开发出来的软件。那这么忙于交流是为嘛？!

　　事实上，这么多交流和信息并不能帮助人们回答一个最重要的问题 -

　　What had each programmer accomplished in the past week, and what task was next？ [p141]

　　我的故事 - 在MS Outlook97 发布之后，网上对这个V1 版本有很多意见，也有很多期待。 其中很多用户在 NewsGroup (新闻组) BBS 上发表了强烈的建议，要求Outlook 支持直接阅读 NewsGroup/BBS 的内容，当时只有Outlook Express 有这个功能。Outlook 的开发成员一度认为用户的要求太强烈了，如果我们没有这个功能，可能V2就会很不受欢迎 （几个dev 已经做了一个初始版本）。 但是大家仔细分析后发现，在BBS上强烈发言的，就是那么几个人，因为他们老用BBS，因此他们的需求特别强烈，并且好像声势浩大，但是别的大部分用户根本就不上BBS，因此也没机会表达意见。所以Outlook 决定不做 NewsGroup 的功能，一直到现在。

　　内部的交流

　　除了外部的交流，还有内部的交流，随着一个人经验的增多，会有很多其他人来找你，为大大小小的事咨询你的意见。然而你自己也有无数的任务要完成，怎么办？微软的员工对这种情况也不陌生，微软团队允许一些人 “Go Dark”，他们可以关起门自己干活，敲门不答应，不回答一般的email，不参加会议等等。

　　据说很早以前，BillG 把开发OS/2 API 的任务交给了一个牛人，这位前辈接受任务之后，并没有开新闻发布会，建立email distribution list, 或者QQ 群，而是挂了一个和下面类似的牌子在办公室门外，把门一关，一个人闷头开发去了。

　　我们知道交流很重要，但是软件不是在QQ 群中交流出来的（当然，有人在QQ 群中交流别人写好的软件），而是一些人一行行写出来的。 这个过程需要集中注意力，避免打扰。在一个 “集市” 风格， “共享” 的开发氛围中，如何能保证关起门来开发呢？

　　//答案是 d)