每逢读书笔记上交作业时刻,班级blog页面上总能看到<人月神话>相关的读书笔记,本次软工课邓老师推荐的第一篇读书笔记也是写的<人月神话>,算是对它“耳濡目染”了.本周,我终于抽空读了这本书,感觉确实名不虚传.以下,我将从几方面谈谈我的感想. 一.焦油坑与银弹 书中将大型项目形象地比作焦油坑,开发者往往在巨大的项目里遇到纷繁复杂的问题,并在其中越陷越深,难以掌握全貌和本质.在我看来,软件的开发确实存在其固有问题,在一个开发团队开始挖坑时,由于思路的些许偏差.交流和认知水平的些许欠缺或…

 本周在考虑阅读材料时,我翻阅了<移山之道>,正好看到这一章:两人合作,心想:正好,我们正值结对作业的紧要关头,书中两人合作的宝贵经验和教诲应当对我们有很大帮助.于是,我开始一边在ddl苦海中扑腾挣扎,一边抽空读完了这一章,确实受益匪浅. 这一章首先由一个时间估计的小故事引入:从北京火车站到八达岭长城需要多久.书中两位同学分别考虑不同情况,给出了截然不同的估计,由此引出项目管理要素三角形:功能.资源和时间.这三者在项目中相互制约,维持其平衡方能做好项目.回想这一周我们奋战的经历,首先时间方面紧…

编程中,调试几乎是必不可少的,一劳永逸.一次完成预想功能而完全不出bug的情况凤毛麟角,出现bug→调试→再出现bug→再调试……基本是软件工程中的常态.可以说,软件调试是每个coder的必修课,而<软件调试修炼之道>便是一本调试教科书,考虑到前两次大作业中出现的各种bug,我有必要系统地学习debug的一些思想和技巧,因此本周我阅读了这本书的Part 1:问题的核心.这一部分由五章组成:山重水复疑无路,重现问题,诊断,修复缺陷,反思.以下我将分别浅谈我的阅读感想. 1.概览调试:流程.问题和…

本周我阅读了某同学推荐的<创新者>,这本书实际上是两个世纪以来信息技术的编年史,从巴贝奇的差分机到如今互联网时代的超级计算机,作者通过各个时代里一位位杰出的创新者,将计算机诞生.发展.崛起和蓬勃的历程娓娓道来.从一篇篇人入胜的创新者传记中,我看到了埃达·洛夫莱斯的诗意想象.技术热忱与自信坚强,见证了阿塔纳索夫的灵感眷顾与没落,感慨于莫奇利“集百家之长”的智慧……创新者们站在时代的最前沿,推动着历史车轮滚滚前行,也以亲身经历展示着创新之道. 一.创新:想象与实践 想象,是创新者不可或缺的要素.回…

这也许是和候红老师的最后的几节课了吧,侯老师是一个很有思想深度,很关心同学的好老师. 一开学就布置了阅读<人月神话>的作业,说实话,我没有看,以我的速度可能2.3个小时就看完了,但是我觉得没有什么意义,在网上找了一个洗的很好的总结,大概看了看,并加入了一些自己的看法,因为目前才大三,没有什么项目开发经验,所以只能从平时的编程中遇到的问题来看待<人与神话>这本书. 参考: <人月神话>读书笔记——陈浩要安静(http://www.jianshu.com/p/da8a683…

写了这么久的读书笔记,涉及到问题大多是一些如何把软件工程做好,如何把自己的职业生涯做好.但总感觉逻辑链上缺了一环,亦即:我们为什么要把软件工程做好,我们成为一名优秀的职业生涯的意义到底在于什么?我觉得如果这个问题不去想,那么这段三段论便不是完整的,不知道为什么要做的事情而去做,未免太浑浑噩噩了,说实话,就有点行尸走肉的感觉. 本来以为程序员的自我修养这本书能够解答我心中的疑惑,然而翻开这本书,却是一些列关于系统软件如何运行和装载的问题.窃以为,如果是关于这种如何提高自身技能的书,不应该用<程序员…

读书笔记第三周:人月神话   这本书主要讲述了如何管理一个软件开发团队的问题,其中如何提高团队的效率可以说是本书的重点之一了.感觉这本书地中文版翻译得比较晦涩,很多表达比较模糊,看起来有些吃力,因此下周我可能会考虑借一下英文原版来看.本周的话我看了前两章,我觉得重要的收获有四点   第一,作者与我们交流了一名码农的职业的乐趣,编程是可以创建事物的,而这有着纯粹的快乐,如同小孩子玩泥巴一样.其次,编程可以造出对他人有用的东西,这也是人的一种自我实现,实现自我的社会价值.同时,编程的精妙,将各种复杂…

<Practices of an Agile Developer:Woring in the Real World>读书笔记  本周我阅读了<高效程序员的45个习惯:敏捷开发修炼之道>(标题中书名的中文译名)一书,本书并未繁复啰嗦地具体告诉读者如何在软件开发的每一步中做到敏捷,而是从宏观层面介绍了成为高效开发人员需要具备的习惯.观念和思想方法. 所谓敏捷,书中有一句精辟概扩:“敏捷开发即在一个高度协作的环境中,不断地使用反馈进行自我调整和完善”.简而言之,敏捷开发意味着“小团队”“…

几乎是计算机软件开发的发展历史     人月神话,增加人手并不一定能提高开发速度. 原因在于,有些任务是无法分解的,存在先后顺序.无法同步进行. 增加人手,增加的是沟通成本,相互牵制.可以分解的任务就可以通过增加人手来加快速度.但是不能分解的任务,增加人手只会增加开发时长.打个通俗比方,怀孕需要12个月,增加人手,也不能加快时间. 作者赞赏的是,小型精干的技术团队是最好的.沟通成本低,开发效率高. 厨师煎一个蛋,需要5分钟,而顾客期望2分钟.怎么都达不到,2分钟的办法是,把火开大可以快速点(类似…

第一次听说人月神话还是在大一上学期的导论课那会儿,那会儿好像就已经确定了自己要学软件,于是就去问王建民老师能不能给我推荐几本软件工程方面的书,我想要提前自己学学,以为老师会给我推荐一些某种语言类的学习书,但是貌似不是,他推荐的一堆书里面其中就有这本<人月神话>,当时的我真的不理解,别的书还好,像是梦断代码,好歹里面有个代码俩字儿,但这个……那个人月是啥意思,人和月亮的神话故事??可是这和软件工程又有什么关系呢?也许是单纯因为好奇心吧,趁着双十一我就买了一本,但是好奇心来得快去的也快,书到手以后…