梦断代码-读后感1

这几天阅读了梦断代码,这本书
第一章软件时间,第一点讲的是我在在一个大学里玩了一个叫sumer的游戏嗯,它是一个空白面板,只须要我们花几个钟头学点语言就可以改游戏,玩游戏一样容易,当时作者已经沉迷于其中,后来作者担任一个杂志的主编和程序设计员,20世纪90年代,科技行业的兴盛给我们带来了互联网时间的概念,一切皆有可能发生技术产生公司创立创造财富,而且速度惊人,这意味着你没有时间做到尽善尽美,无须担心,因为别人也一样,在做软件的过程中,时间似乎确实时快时慢,如果一切顺利,你会沉浸在心理学称之为留是的状态中,全然忘记时间,如果事有不谐,你又会陷入困境,四顾茫然,举步维艰,无论是哪种情况,始终都会被抛诸脑后,你用的是软件时间,为什么软件要从零开始计数?因为计算机从零开始计数,所以程序员也训练自己,这样计数,以免他们要只是操作的计算机产生误解,最后作者又在大桥上举了一个例子,整个过程设计的精密执行无误,他分毫不差,完全满足了我们对工程一词信心,关于软件缺陷的话题,只能谈上几分钟,人类文明运行与软件之上,但是软件创造艺术却影院处及时,对于专家也是如此,伟大的计算机先驱莫瑞斯威尔克斯在剑桥大学工作室在拖着打孔纸带上楼,给出行计算edase的装载程序,我的未来都将耗费在自己的程序,找错误,上头从威克斯,尽管有许多创新工作中,投一元却一直陷于调试除错之苦,经工作中只有1%的灵感迸发,剩下的是艰难寻找,汗湿重衣,他们的作品永远尚未完成,或未臻至善,区别仅仅是问题,更少的程度罢了 有些人梦想炸毁今天的整座软件大厦,t某种全新织物,有些人则一味盼望找不到,不太顽固,更能响应人类愿望和行为流程的程序员,盼望得到召之即来,挥之即去的软件,盼望得到足赖彝族看依赖的代码梦之所寄行之所为,这就是代码

第二节死定了,讲的是程序员,一般都是落后于进度,软件缺陷列表指的是为解决或开放的问题以及缺陷,在着手修正缺陷的一个钟头内,伯吉斯插画说你就知道它会变成什么样,黑洞式的缺陷及无法确定修正所需时长的缺陷,在bug中应当用特别的警示词标示出来,使用这种宿命论言辞并非脱衣独有的怪癖,面临困境仍不忘幽上一默,是一种程序员文化,日常中的黑洞充满不确定,甚至不可知因素的时间缺陷,每个领域都有延误现象,历史上任何软件项目均曾有隐藏的线缆,对于改进软件开发所做好了,程序员能在规定时间内完成十倍,与普通程序员的工作量,而且完成质量也五倍于普通程序员,若人与人之间的劳动效果如此不同,咋衡量标也无同的努力,都是为了让宪兰保持细节,根据布鲁克斯法则,产生了就是往矣眼期的项目中补充人力,只会使使其继续延迟,即好的程序员能在规定时间内完成十位与普通程序员的工作量,而且完成程序也五倍,与普通程序员若与人的之间劳动效果如此不同,咋衡量标准也无从谈起,决定都含有不确定性,地面还未凝固,怎能站得稳?构建软件最难之处在于决定说什么,而是不是怎么说?赫兹菲尔德告诉我,我的风格是赶快干起来,然后再把它变成我们想要的大东西,这不是平庸之作,是个大东西,不过总得有人干吧!要点在于激情开干,然后顺其自然,船到桥头自然直,做大事没有大压力也可以嘛?或者压力是天才不可或缺的一部分吧,愉悦是金开元的成功,告诉我们,对于创造的工作玩耍是最经济有效的模式

第三节,Agenda,之魂,这咋讲的?是不清楚楚戈尔队osaf有多了解,不过把宝押说他们正在改变世界上是明智之举,这个短语在硅谷由来已久,或者对于大多数程序员所共有的理想主义,直接编制编程的辛劳和挫败,与人敬畏的抽象建模较近,或许面对蜂拥而至的缺陷,大军唯有万丈雄心,能祝你艰难前行,项目并没有真正在改变世界,但它切中要害,正是为改变世界织梦所驱动,不过项目开始谨小慎微,带有怒气些许,心中之痒,服务器只是中间人,中间人可以被踢出局,哪些在数十年前运行大型主机?现在又护卫着服务器机房的大牛们,让每个人都能叫上桌上那个稽核绽放异彩,引入了一种管理数据的新手段,介于传统技术数据库的严格结构和字处理软件的自由格局之间,当他用JAVA,编写,编写程序时发现并不怎么满意,但是他觉得都应该有ajdan之魂,卡普尔说,对了,chandler典型项目不够典型,不过哪个项目够典型的?没有所谓典型的软件项目,安迪赫兹菲尔德喜欢这样说,每个项目都有其不同之处,都有其魂

原文地址:https://www.cnblogs.com/kongfanbing/p/12236385.html

时间: 2024-10-21 08:37:33

梦断代码-读后感1的相关文章

梦断代码读后感3

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

梦断代码读后感2

读<梦断代码>已有一段时间了,书中的开发软件的经验是给我们最大最宝贵的收获,虽然书还没读到最后但仅仅读到现在他给我的收获已经很多,此次的感受就针对书中的团队合作做一些总结. 梦断代码主要就是讲了一个开源软件项目——Chandler的失败案例,此软件开始的规划是十分庞大的,团队的开发者也是给与了此软件很大的厚望和努力,团队的开发者也是软件开发的精英团队但最终他还是难逃失败的厄运,这不仅仅说明了软件难做,这也同样说明了软件开发过程中的每一个步骤都是十分重要的从需求分析到软件测试甚至软件维护都是至关

梦断代码读后感1

今天开始读梦断代码了. 书中说道,“关于软件缺陷的话题,只要谈上几分钟,必会有人拍案叹道,‘为什么就是不能像造桥那样造软件?’”的确,掩卷长思,为神马不能像造桥那样造软件哪!细想起来,两者之间的根本不同在于,一个是体力劳动,以机械为主:一个是脑力劳动,以人为主.人,从来就不是一个确定的东西,有喜怒哀乐,有自己的偏爱和偏见,充满了各种不确定性,以它为主的项目,自然不可能做到分毫不差.软件工程的主要目的,就是尽量把这种不确定性从项目中剥离出来,使做软件真正成为一个工程,而不是个人英雄主义的胡拼乱凑.

梦断代码 读后感2

团队开发要有好的初期规划以及明确的项目目标,目标变来变去是很多项目失败的根本.连自己都不知道做什么,还能指望做出什么来.这同样说明了需求分析的重要性,要了解客户的需求从客户的角度看问题.所以所谓的目标就是客户的需求,满足了客户的需求目标也就算达到了.其次,确定好目标后在软件开发的关键过程中团队的配合协作十分重要,尽最大可能发挥自己在团队中的作用相互协作多做总结多讨论问题,这是很重要的步骤,梦断代码中的团队合作已经相当不错了,但还难逃失败,我们的团队所以更应该努力做到更好.   在<梦断代码>这

梦断代码读后感(二)

<梦断代码>内容简介: 软件乃是人类自以为最有把握,实则最难掌控的技术.<梦断代码>作者罗森伯格对OSAF主持的Chandler项目进行田野调查,跟踪经年,试图借由Chandler项目的开发过程揭示软件开发中的一些根本性大问题.<梦断代码>是讲一事,也是讲百千事:是写一软件,也是写百千软件:是写一群人,也是写百千万人.任何一个在软件领域稍有经验的技术人员看完<梦断代码>,必掩卷长叹:做软件难. 作者简介 Scott Rosenberg:作家,编辑,1981年

梦断代码读后感(三)

梦断代码: 一群人像是守护着一个刚出生的婴儿,细心呵护,无微不至.将所有精力都投入对他的照顾,可是,到头来功亏一溃,驮着巨石上山但是却在最后阶段滚了下来.初时紧紧是一个小小的问题,但后来却逐渐扩大,成为压死骆驼的最后一根稻草!! 但是我也看到了他们的奋不顾身 ,这是一种精神,一种值得我们学习的精神! 如果我以后也从事这门工作的话,希望我也能和他们一样,拥有为之奋斗的精神!!

梦断代码读后感之终结篇

好吧,历时一个月之久的梦断代码阅读计划终于结束了,在王老师的要求之下,我粗略的浏览了一遍这本书,看到自己喜欢的地方就放慢脚步,细细品味. <梦断代码>是讲一事,也是讲百千事:是写一软件,也是写百千软件:是写一群人,也是写百千万人.诚然这本书里有一个大故事,大故事里面又包含了许多小故事,虽然他最后失败了,但是他给我们留下了许多的启发和感受. 读完这本书最大的感受就是做软件真难,有时候真的不是特别的理解他们为什么浪费自己的时间去做面对那些枯燥的代码,一遍又一遍的去调试修改那些程序,他们有时候就像一

梦断代码读后感——终结

<梦断代码>这本书读了将近一个月的时间,终于读完了,虽然没有细读,但是还是了解了它的大概内容,知道在讲些什么.本来计划每三章就发一篇读书笔记的,因为时间很紧,就没按计划来,我一般都是晚上看,看完就来不及发了,一直拖到都看完. 这本书的译后记提到了Chandler项目的结局,它失败了,它成了众多失败软件项目中的一个.这个结局无疑又加重了自己看完这本书后心情的沉重:做软件真不容易. 今天的软件项目,已经成为一个错综复杂的建筑工程,不断变化的应用环境(包括使用者),使得软件需求被不断更新,今天100

梦断代码 读后感

这几天的学习中空余时间大体浏览了一下梦断代码这本书,但确实没有很细致的阅读.但依然有所收获. 开头的第0章就是打破人们固定的定型思维,章节从第0章开始,作者无意搞笑只是想说明一点程序员的计数方式从0开始,仔细一想确实如此,难的不说就说最基本的数组便是从0开始储存. 第一章 死定了  布鲁克斯法则:向已延误的项目中补充人力,只会使其继续延误.这句定理说明人多力量大在软件行业不一定能成立,进行中的项目补充人力只会花费更多的时间对新人进行讲解. 第二章Agenda之魂 该篇主要讲了卡普尔的一些故事,在