《机电传动大作业》笔记一

没有想象中的枯燥,甚至有些有趣.这就是我对<梦断代码>这一本书的第一印象.而且,作为一本面向程序员的书籍,作者很有意义地从第0章开始,那我也从第0章开始说.这第一次读书笔记是针对0~2 章的. 首先,作者一开始就向我们介绍了程序员的真实生活:代码.日期.紧张.焦虑.这是我从书中体会出来代表程序员的词 语.我第一次感到编程可能是一件辛苦的事,回想自己编程的时候,只是歇一歇简单的短的程序,没有压力,没有焦虑,但是在真正的公司.项目中,程序员要面对的是茫茫代码以及对未来的未知,因为没有人能确定自己从

读书笔记:<梦断代码Dreaming in Code> 拿到<梦断代码>书后,一口气翻了一遍,然后又用了3天时间仔细读了一遍,也不禁掩卷长叹一声,做软件难.虽难,仍要继续走下去,可以把软件的范围限制得小一些,用敏捷方法等过程会使软件失败的风险小一些,毕竟我们还没有写书上所说的那样的大型软件. 第0章 软件时间 一开始看到第0章并没有感觉多么奇怪,可能程序员的思维方式已经固化在大脑中了,但读到作者关于第0章无意搞笑时,也不禁哑然失笑,为什么程序员要 从0开始计数?因为计算机从0开始计

08梦断代码阅读笔记有感之二 在梦断代码的一开始我们就学会了如何去写代码,如何成功的去做一个软件工程师. 在现在人的严重,也许软件工程师写出的代码只是让人在玩游戏,在用一些简单的用代码写出的软件.只是认为工程师在不断地重复着一个动作:写代码.但我只能说你们大错特错,就像在文章中说的那样,其实软件工程师是在:“改变世界”,他们利用他们的手用键盘在电脑上打出一行一行的代码,程序产生了,一个新的软件也就产生了.而且,众所周知的,工程师做一个软件,总是在无限制的更新他的内容,让我们的软件更加的先进化,就

09梦断代码阅读笔记之三 这是最后一篇的阅读笔记,我发现时间真的过的好快好快. 想想以前,我们总是在应付一切的差事,但是真正的到最后,我们才发现,到最后吃亏的还是我们自己. 从前的我们,我们总是对自己大脑中的东西一片一片的特别的混乱.其实我们就像作者所说的,我们就像放任胡乱的cd随地的乱放,到最后不知道哪是哪.我们应该学会分类去放置,例如:我们可以根据歌唱者的名字,音乐的类型等等,其实这些东西对于我们写代码也同样的试用,刚开始的上大一时候,我们第一次的学习C++,我们只是随时随地的在写代码,并不

通过对<梦断代码>的初步阅读,感觉以前订的阅读计划似乎并不能满足笔记的需要,因为就第0章便让我感到书中有很多话值得我去记下来,无论是将来工作或者生活或许都有点用处吧. 就像作者说的书是讲一事,也是讲百千事:是写一软件,也是写百千软件:是写一群人,也是写百千万人.读完第0章书给我的感觉没有了课本上的枯燥,有了我喜欢的故事情节,让我了解了一个程序员的真实生活与成长.第0章作为编过程的我们或许已经想到为啥不从第一章开始了吧,因为我们要记住从0开始计数. 兴趣很重要!Sumer或许就是让主角爱上编程的

<梦断代码>读书笔记 第2篇 第7章:细节视图 第8章:白板上的即时贴 第9章:方法 第10章:工程师和艺术家 第11章:通往狗食版之路 “读书时我喜欢上数学课——这类东西之所以能吸引我,是因为我知道自己做对了.”在书里面我找到了自己刚接触计算机时不喜欢编程可能的原因:我不知道自己是否做对了,也没有很顺利就做对的时候,慢慢地导致排斥编程,特别是一点思路也没有,或者知道这个程序将会花费我很多时间时情绪很糟糕,所以它不能吸引我.到现在,每次找到程序中不对的地方再修改正确,即使消耗很多时间,也会有一

<梦断代码>读书笔记 第0篇 第0章:软件时间 第1章:死定了 第2章:Agenda之魂 从老师布置这个作业之后,我便按照自己的计划开始阅读识字以来的第一本关于软件工程的小说——<梦断代码>,周一至周五每天睡前读几页. 首先,第一遍从第0章至第1章看完,我愣是不知道书上到底在说些什么,感觉这小说跟教科书一样好催眠,说实话,每次还没看多少行就困得不行了.所以,我看了第二遍(而且还寻思着再看不懂也不看第三遍了),果然,我还是没有与作者产生共鸣.不过,在再次阅读的过程中我勾画了一些给自己

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

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

最近阅读了罗森伯格的<梦断代码>,算是近距离观察了十几年前软件开发的状态.这本书是作者对OSAF主持的Chandler项目进行田野调查  而写的一本书.本书是在讲一事,也是在讲百千事:是写一软件,也是在写千百软件.在描述Chandler项目的过程当中亦提出了很多观点,带给我们很多思考.让我们这些软件工程专业的学生对软件开发有了一个更深层次的认知. 在本书第一章,作者为我们介绍了一个布鲁克斯法则:"往已延误的项目里补充人力,只会使其继续延误". 布鲁克斯曾是IBM的资深程序经