《梦断代码》摘录及感悟

1 摘录

1.1 软件开发艰巨

"好的软件开发工作始于打造开发人员本人。"仅仅要是做某种取悦自己活满足自己的东西。程序猿就会动力十足,努力做到最好。

侯世达定律:做事所花费的时间总是比你预期的要长,即使你的预期中考虑了侯世达定律。特别是在进行有关提高效率的讨论时(如《人月神话》和极限编程)。

其自指的特征反映了即便意识到任务的复杂性。估计花费的时间仍是困难的。

一切倒塌又得以重建,再造它们的人满心欢喜——William Butler Yeats 《天青石雕》(Lapic Lazuli)

软件相对于现代技术的差别是,软件是唯一不考虑质量(測试之前)的领域

我在尽力保持耐心、不做蠢事,即使接受有东西没做完的事实。

也须要了解做了什么,否则等于引火自焚。<注:可见,当时主人公有多么的无奈>

如今我们身处地狱般的境界。有那么多的好主意要拿来毙掉

用贴纸、每块仅仅表示大致同等的工作量

产品经理与开发经理之间的拔河赛

低估了实现项目远大抱负所需的代价,组建一个project团队要比想象中更难

个人自以为懂得非常多

时间——特性——金钱:这一黄金三角之中往往仅仅能选二,而不得不抛弃第三个

别做大项目 (linus)

<如今的软件开发并不会比之前的好过多少,基本上也是依照数据、设计模型、讨论、測试、集成这种流程进行。

做项目时的喜悦,项目公布时的痛苦,代码检查等>

1.2 软件不断创新

一次重新,那些大度在技术工业的太阳底下不再有新奇失误的人输个精光。

具备延迟绑定动态为例精髓的语言:20世纪50年代的 lisp。20世纪70年代的 SmallTalk

GMail 消除了浏览器在用户每次操作时与server进行信息交换的须要

Mozilla 奇客精英,黑洞达数年之久,失去关键程序猿的支持,但终于诞生了 Firefox

为之奋斗的未来惊鸿一瞥——而那未来仍是如此令人痛苦地遥远

当萨奇回答说开发时间仅仅有两个小时时,相片blog,基于chandler。基于现有熟悉的项目开发能加快项目的进度?

1.3 怀有改变世界之心的大神

卡普尔:非常多的名誉,充足的资金,想要很多其它的荣誉:假设你做了还有一件了不起的事情。就让世界看到你的实力。

20世纪80年代。瓦茨·汉弗里从 IBM 退休,之前在 IBM 成功运行强制进度计划后。发个宏愿:离开 IBM 后。我要改变世界的软件开发方式。

由于安坐在沙滩上,实在太无聊!

程序猿:获得杰出源码,杰出软件架构,软件设计师,生命历程。获取诗歌艺术硕士学位。

软件开发人员,为制作一部电影而暂时组合,然后解散,再又一次为拍下一部电影又一次组合

1.4 推荐的资料

《计算机编程艺术》(书)

《哥德尔,埃舍尔,巴赫:集异璧之大成》(书)

《土拨鼠日》(电影)

2 总结

好早就看完这本书了,这真是一本超级好的书。看完之后也是感触良多。一个满是荣誉、財富的人。带着一群世界顶尖程序猿花费好几年开发软件,终于失败不重要。由于一路鼓励了非常多人,甚至机缘巧合地解救了firefox,改变了世界。

一直想写读后感,优点多多。可这读后感啊。一直拖、一直拖了将近一个多月了,到如今还没有写。为了一个月发表四篇博客,就写成这样的形式了。

写文章正如写代码一样,不能一開始考虑太多,不然永远開始不了。

最后。写文章时,发现有同行已写了读后感,大家能够參考:

[http://www.cnblogs.com/banana-totolv/archive/2011/06/08/2074765.html]

时间: 2024-12-05 20:26:40

《梦断代码》摘录及感悟的相关文章

《梦断代码》读书感悟三及对《人月神话》的读书计划

原计划中,<梦断代码>这本书是要在三月月内读完的,前期到时兴致勃勃,但后期却有些懈怠,导致拖延到了今天. 这本书给了我不少的启发,是它简述了程序员的形象,让我明白今后自己的工作环境和位置,让我真正正视计算机行业. 同时,他让我明白了团队的重要性,让我对接受失败做好了准备. 下一本书,我准备阅读<人月神话>,这一次我要加快进度,争取在五一之前读完它,发三篇读书报告.并且,这一次发感悟 一定要随看随发,不能像这一次,等书基本看完才发.

《梦断代码》读书感悟二

不知不觉中,<梦断代码>这本书也被读完了.说实话,这本书多次出乎我的意料. 第一次从老师那听到这本书,我以为这必定是一本专门讲解代码的学术巨著,到手才发现,这是一本类似于小说的书. 随着不断地阅读,虽然没有特别强的专业性,但本书却完整的在我脑中描绘出了一个软件工程师的工作场面. 最出乎意料的,经过多天的工作,书中的项目竟然失败了.. 我对程序开发的失败没什么概念,自开始学习计算机,开发失败的经历少之又少(毕竟失败了也就意味着这一科挂了),老师在布置任务的时候也会尽量布置我们能够解决的. 我很难

《梦断代码》读书感悟一

其实早就应该发这一篇了,我周围的人又读了两章就发感悟的,而我整本书快看完了却还没发过.我总是觉得没什么感悟,只是机械的看书.想来,我还是没能真正地把自己当做一个合格的计算机行业从业者,我很难体会到书中程序员平凡中的不平凡. 在本书中,只要是开发就必然有一个团队,虽然没有特意的强调,但它很明确的告诉我程序的开发是一个团队的项目,单打独斗并不适合现在的潮流.我一向比较倾向于团队合作,只有一个互补的团队才会让个人的实力完全展现出来,有了同伴,才会更快的发现自己的错误与不足. 书中提到了很多开发时遇到的

梦断代码读后感3

梦断代码终于读完了,然而感悟却还没有完.正如作者所说,这是一个关于一队人马并肩托起代码大石.欲将其推上山顶,虽历经磨难,但仍奋力创造某种有用.丰富且持久之物的故事,读罢想来也许最大的收获是对软件工程有了更加深刻的理解. 我们觉得软件难以对付,是因为它不可见,不可见也并非唯一问题,我们也看不见电力.磁力或重力,但却能为多数实用目的可靠地预测其行为,可是我们没有理论可以用来计算对软件尺寸.性能和复杂度的限制,甚至不能以符合逻辑的手段来说明软件产品要做的事情以及它如何做到的问题.就像那个关于软件工程的

梦断代码读书笔记(1)

阅读时间:2018年2月5号 这次主要是读完梦断代码的的前4章之后,记录下来所得到的感悟. 不知道是不是因为没有经历过真正的软件设计,我在读梦断代码的时候感觉到明显的吃力,尽管已经读了大概有4章,还是没有从这4章中提取出一个大致的主线.如果说有的话,就是关于两点:1.软件是个黑洞,无数的公司,企业全都栽在了这个上面:2.关于Chandler的设计,作者好像是以这个软件作为一个模型来揭示关于软件行业的问题. 首先,来说说第一个问题.在没有接触这个之前,我确实是没有想过,软件会是很难,确切的说是软件

梦断代码阅读笔记01

大致浏览了一下<梦断代码>这本书,觉得还是挺感兴趣的.第一章软件时间,作者以一名程序员的身份自述,故事性很强,读起来不会感觉枯燥.在第一章中作者认为程序员与其他人的不同之处在于他们从一开始,而我们从零开始,想来也正是如此,他谈了软件的发展历程以及过程中好多伟大的研究者为其发展而做的贡献,这个行业也是很多前辈付出了诸多努力才推出来的,所以需要我们付出更多的努力去发展他. 第二章中作者讲到我们做任务需要蓝图,也就是需要有计划,提前计划好,按计划来做任务,这样对于碰到一些问题才不至于举手无措,另外在

梦断代码 阅读计划

这学期要学习软件工程这门课,老师给我们推荐了很多和软件工程相关的书籍,并建议我们在本学期内阅读不少于3本,所以我打算从现在开始到清明节放假这一个月内读完第一本书--<梦断代码> 时间安排   第一周:0.1.2章: 第二周:3.4.5章: 第三周:6.7.8章: 第四周:9.10.11章:

读《梦断代码》第0章有感

今天我读了<梦断代码>的第0章,对编写软件又有了新的认识.知道软件虽然能带给我们许多新鲜的.意想不到的功能,但是却也是不确定,不是像建一座桥那样,可以按部就班,一步一步实施的. 首先吸引我注意的就是第0章,开始我还以为写错了,后来通过读书才知道,原来是作者故意这么写的,而他这么写的目的就是要提醒我们:程序员计数从0开始,而不是从1开始.这是因为计算机采用的是二进制.首先作者通过一个游戏Sumer的例子,吸引我们的兴趣.其实意在告诉我们,编程兴趣是最好的老师,当你真正对编程感兴趣的时候,那么你才

《梦断代码》阅读笔记三

这本书终于读完啦~说实话,其实里面很多东西理解的还不是很透彻,以后找机会一定会再去看.第一遍读了<梦断代码>之后,我真的觉得软件开发过程是抽象艰巨的一个事情,我们自以为很有把握,但实际上真的是很难掌控. 就比如说自己吧,之前在做程序的过程中被大大小小无数的问题折磨,碰到这本书的时候,就觉得找到知音了,原来很多问题同样也折磨着这些技术牛人们.比起软件工程的教科书,这本书更加结合实际,书里内容不是放之四海皆准的真理,也不是药到病除的良方,最多只是事实和总结. 另外这个团队的问题吧真的是一个很重要的

《梦断代码》阅读计划

所谓行千里路,读万卷书.学习一门课程不能单单放眼于一本教课书或者课堂上的内容,应该博览群书,从各个方面各个角度来了解该方面的信息,才能更好地学习或者从事这门课程.<梦断代码>这本书显名于外,在老师的极力推荐下我决定将它作为最近一段时间的读物.这本书是由一个个小故事组成的,并不是其他理论书那般枯燥,毕竟最好的学习就是兴趣. 回到这本书,我的计划就是在两个星期内大致地将这本书读完,然后依据其中的精彩之处再细细研读,我认为真正“读”一本书需要做好读书笔记以及自己的感受和收获的总结. 另外,作为一个信