梦断代码的书评 (61)

LazyLorna 2009-02-11 10:47:10

小处着手更容易成功

引:本文是半年前收到《梦断代码》样书后写的书评。我很高兴自己作为行业外人士也能看懂,尽管韩磊说有过项目经验的人会更能理解书中所讲的那些事。 期待了半年,终于看到韩磊的译作《梦断代码》完成了。收到样书一口气读完,诸多感慨,就像韩磊说:真正开发过软件的读者会对...  (展开)
xinz 2009-01-25 15:53:32 Crown2007版

读后感 (I) 驱动和责任

几个星期前,我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》的中文版 《梦断代码》,要求写读后感。这本书讲了这样的故事:一群很有经验的代码牛人在先进软件开发模式的指导下,没有资金压力,在更多大牛的带领下,原计划用一到两年的时间开发出一个备受...  (展开)
lusu 2008-10-05 17:12:55

随便的感想

这篇书评可能有关键情节透露

看的是这本书的中文版《梦断代码》,公司图书角借的。 一边读,一边感慨 --- 一个好的愿景,一帮牛人,不缺技术不缺钱,最终的结果却不如人愿。 对于书中的很多牛人来说,Chandler可能是他们的第二个系统,难道这就是人月神话中的The second-system effect? 在开发之旅中的...  (展开)
Nicolas 2008-09-20 18:11:04

金子般的反思

失败了就进行反思. 1.定位不能逆时代的潮流, 互联网的趋势不可逆转. 2.人员沟通与合作是永远的重点 3.软件开发方法的质疑 4.计算机的历史与将向何处去. 作者思考得很多, 但也只是反思, 却也没有什么办法. 也许软件还在混沌中. 书中很多历史故事确实勾起了很多的记忆与思考. 不...  (展开)
revolc 2012-09-27 11:36:21

一群牛人的失败之作

作者以一个项目参与者的角度记录了一个伟大的设想最后变成一个失败的项目。究其原因,是为了要跨平台,采用了不熟悉的语言与技术;项目没有个明晰的计划;需求各种变幻;想要憋个完美的产品,而不是先出个雏形然后不断迭代慢慢打磨。 其实,硬件条件不可谓不好,宽松的办公环...  (展开)
列纳 2011-09-04 16:33:39

梦醒代码

《梦断代码》这本书主线颇多,所有内容都需要读者具备一定的软件行业知识——比如说厂商和产品部分,你应该很清楚Lotus、IBM System 360、Outlook、Exchange、Gmail等的功能和推出时间、技术创新;编程部分,你应该了解C++、Java、Python、Ruby、P2P和服务器的不同;编程思想部...  (展开)
caicai 2009-04-18 13:35:37

不仅仅是一个软件开发故事

作者深刻的笔触,让人真实地感觉到软件难做,做一个优秀的软件更难,但是不仅仅讲述了开源软件Chandler项目的开发,还增加了作者自己的观察思考以及其他软件开发人员的观点。 为什么软件开发不能像建造房屋那样按时完成呢,没有人能给出一个确定的答案?文中详细描述了...  (展开)
2009-02-18 13:29:52

软件,写小说,听音乐

1.一个作家,或者说想成为作家的人,通常都会研读一些前辈的作品。 音乐家也是如此,多少会听一些前辈 的音乐,在前辈的音乐上有所创新。 软件开发呢?不知道有多少人是大量阅读前辈的作品--代码? 2.软件开发项目充斥着项目延迟,从简单的解决方法考虑,就是制定计划,接着...  (展开)
forestgump 2008-09-22 15:26:52

软件乌托邦--理想主义的失败

这篇书评可能有关键情节透露

终于断断续续地读完了. 几个月前偶然看到刘韧对此书的评论,又试读了译者网站上发布的"第0章 软件时间",当即决定买下. 拿到书后,发现后面的几章读起来颇为费劲,语言和思维的跳跃性很大,不断出现大量的人物和典故.在我读完另外几本书后,对硅谷的历史和人物脉络逐步清晰,方能一...  (展开)
魏智勇 2019-02-26 22:35:24

从梦断代码看软件工程的复杂性

软件工程与其他所有行业最大相径庭的一点,可能在于唯有在这一领域,关于失败的专注要多于成功的,软件工程的成功只有一种——按时按照要求完成交付(虽然在大部分情况下这只是一种幻想)——但失败却有着无穷无尽的可能,曾经看到一篇描述某欧洲国家政府软件项目的未经证实的...  (展开)
lethe 2015-07-30 09:14:10 Crown2007版

软件工程案例分析经典之作

这篇书评可能有关键情节透露

在合适的时间,遇到了合适的书。从事软件行业这几年,有诸多感触,和书中描述的基本是一致的: 1.项目的工作量无法准确预估; 2.要打造一个产品,远比最初估计的难得多; 3.需求,需求远比开发本身重要,最难的是决定要做什么,而不是如何做; 4. 不要过度设计,重造车轮,框架...  (展开)
涅瓦纳 2014-08-10 20:41:29

梦断代码

软件乃是人类自以为最有把握,实则最难掌控的技术。本书作者罗森伯格对OSAF主持的Chandler项目进行田野调查,跟踪经年,试图借由Chandler的开发过程揭示软件开发中的一些根本性大问题。. 本书是讲一事,也是讲百千事;是写一软件,也是写百千软件;是写一群人,也是写百千万人...  (展开)
RexKang 2013-12-02 08:23:33 电子工业出版社2011版

软件开发的那点事,梦想和现实的差距

这篇书评可能有关键情节透露

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

长长的旅程啊

书写的不错,不只是对“chandler”项目及其团队的思考,也穿插了很多软件行业中的轶事趣闻。读起来是比较流畅,但是越到后来,越因为"chandler“团队的拖延、迟疑、不果断而郁闷和急躁。唉,做软件真是难呀。  (展开)
無伈 2011-10-24 15:39:44

感觉翻译的有点差

刚看了一个开头,就没有了看下去的兴趣了,只能说这个译者的翻译过于生硬,有些语句完全是直译,有时候看的有点让人摸不着头脑。是不是应该去看原版呢,相信原版应该还是非常值得一读的,不过就是看着有点累了,《Continuous Delivery》已经看的很累了,还得加强英文阅读能力,...  (展开)
天露危城 2011-04-28 22:41:43

为软件写的墓志铭

用三年时间记录一个软件开发的全过程,这个软件很牛,这个作者也很有耐心,看完之后有些伤,伤了做软件的心,伤了有梦的人。 书的内容很广博,不得不佩服作者有学识,作者对软件的认识也是很独到的,很多地方都直切要害,作为软件人我很喜欢作者的这本书。 翻译也很好,语言...  (展开)
drizzlecrj 2010-11-17 22:45:46

技术天才s+激情 != 成功?

非常不错的技术人文书,让人们认识到软件工程的重要性。这么多的技术天才,这么多年的激情,却没有成就Chandler的成功,呜呼哀哉! 刚刚去了Chandler 项目的页面(http://chandlerproject.org/)下载了最新的v1.0.3版试用了下,说实话,我不觉得它值得能打败Outlook...  (展开)
石头金金 2010-10-07 20:38:16

未读完

说实话读之前对他的期望值蛮高,自己也是搞软件的 但是读了一半读不下去了。不知道是翻译水平问题还是自己不喜欢看译本,总觉得语句不顺,且本身内容也比较枯燥。无奈读了一半没读下去。搁浅  (展开)
Nile Black 2010-06-10 09:35:00

[摘录]事故处理方案

软件工程师、硬件工程师和部门经理驾车去瑞士开会。行驶到一处陡峭山路时,刹车突然失灵。汽车不受控制,一路侧滑下去,飞越过紧急的缓冲障碍,奇迹般的蹭的山石停了下来。乘客们有惊无险,不过面临一个问题:他们的车抛锚在半山上,汽车制动无效。该怎么办? “我知道怎么办...  (展开)
<前页 1 2 3 4 后页> (共61条)

订阅梦断代码的书评