构建之法的读后感

七月份读完了构建之法这本书,粗读,基本了解了软件工程这个专业的工作,就业,和前景。目前有如下体会(构建之法这本书正如前言所介绍,适合软件工程的任何阶段去读,我现在只阅读了一遍,还会继续地读下去):

一,      原来,软件工程并不是像我再选专业之前认为的那样,只是一群人在一起敲代码。软件工程的定义是把系统的,有序的,可量化的方法应用到软件的开发,运营和维护上的过程。(构建之法P8),而软件工程这个专业里细分了,软件需求分析,软件设计,软件构建,软件测试,软件维护。以前只是简单的构想,软件只是一个人写完的,在读完了构建之法后,觉得以前的想法很幼稚,软件工程没有个人英雄主义,而是一个团队,一同辛苦努力工作的结果。去写任何一个软件,都要有规范的步骤,分析需求---生成设计文档---设计复审---代码规范---具体设计---具体编码---代码复审---测试。成熟且实用满足需求的软件并不是一蹴而就的,而是一群人的成果。

二,      读完构建之法后,简单了解了软件工程师的就业,和考证,第三章系统讲解了软件工程师的成长之路,引用P59页的图表,SDE初级软件开发工程师(入门。在学校里学到了些技能,尚未在实践中得到充分锻炼)---SDEⅡ中级软件开发工程师(独立。可以写别人交给你的任何东西,不明白时知道去问谁)---Senior SDE高级软件开发工程师(小组领导。影响着3-12名工程师,或者是他们的行政领导;或者是他们的技术带头人)---Principal SDE首席软件开发工程师(团队领导。影响着10人以上的大团队,成为影响团队成败的关键人物)。书中还给出了有中国特色的好工程师的要素。

三,      通读完整本书之后,要成为一个善于交流,说到做到,接受团队赋予的角色,全力投入团队,融入团队的软件工程师。我认为,一个优秀的软件工程师,不管代码写的好与坏,首先要是一个善于交流,懂的合作的人,善于同团队交流,才有利于共同解决问题,才有利于代码复审等后期工作的展开,我相信,当软件公司在招聘人才时,首先会注重他的交流与表达,能否融入这个团队,其次才是写代码的能力。我希望自己在以后的学习过程中,要多与人交流,不能是自己独自一人闭门造车。

四,      第四个感悟就是规范化,读完这本书后,看了看自己大一一年写过的作业,如果不是自己单独给每个VC文件命名,有很多代码自己看完了都不知道这个的功能到底是什么,需要在重新运行一遍。在构建之法中,强调了团队规范的写代码的规定,比如4个空格要优于TAB键,其次在命名变量的时候要选取合适的单词作为变量名,截取我写的代码的片段,自己在没有阅读之前真的是太太太太太不规范了,太太太太太太太随意了

void Student::setStudent()

{

cin >> xuehao;

cin >> nianling;

cin >> name;

cout << "建立信息函数被调用" << endl;

}

学号,年龄等信息直接用拼音表示了出来,在写代码时虽然简单明了,但是现在再反过来看时,真的有些看不懂,不利于后期的改进和他人的阅读。自己第二个的缺点就是,没有注释!没有注释!没有注释!在作业中很多Class类是干什么的现在在看已经忘了,再加上自己代码写得很不规范,导致了我写的程序,连我自己都不明白这段程序是执行什么的,是完成什么功能的。

以上是我的部分感悟,构建之法这本书真的很好!正如前言所说,这本书就应该每个软件工程专业的人人手一本,这本书给我的感觉就是适合一直去读反复地去读,每个不同的阶段去读都会有新的感受。在小学期以后我回去读第二遍,第三遍,获益匪浅的好书!

时间: 2024-10-22 16:41:48

构建之法的读后感的相关文章

关于《构建之法》读后感

关于<构建之法>读后感 翻开<构建之法>,第一眼看到的是其他读者对该书的读后感受评语,看了这些评语便引起了我的好奇心,这本书真有他们说的那么好?软件工程留给我的印象说比较枯燥无味的,那么一本关于软件工程的书即便写的再生动形象始终逃不开枯燥不是?可是书评却恰恰相反,这让我有一种想探究竟的冲动在无形中被勾起了. 看了,发现该书真如其他读者反馈的一样,该书是一本写的有血有肉的,具有强大的实用性及超级趣味性,生动形象的让人很容易读懂的书. 该书的内容主要以设置情景,采用一问一答的形式为软件

读《构建之法》读后感

读<构建之法>读后感 作为一名小白,我也深知“程序+软件工程=软件”.在此之前我们学习过一个个从小到大,从简到繁的程序,到了今天才知道这些只是作为一名合格的程序员的第一步,<构建之法>这本书从专业的角度为我们阐释了什么是软件工程. 通过<构建之法>这本书我初步了解到了如下内容. 第一章讲诉了什么是软件工程,其中还掺杂了几个例子,让我更好的理解软件工程的概念,同时使我觉得这本书不会太枯燥无味,加强了我看书的耐性. 第二章向我们讲诉了单元测试,回归测试,效能分析工具.但是读

《构建之法》读后感_3137102206_吴思婷

<构建之法>读后感 <构建之法>这本书,是由绉欣老师所编著,我是在大三下学期学习这本书的.用一个网络红语来形容这本书,那就是接地气.刚接触到这本书,第一感觉就觉得它与众不同,不同于以往的编程书,它的形式很新颖,排版非常活泼.说实话,可能是因为它每一页的新颖排版方式让书本的每一页看起来文字没有那么密密麻麻,而且还有插图,所以我才会一发下来我就把它翻了一遍. 通过第一章,我大概了解我将要从这本书中学习什么,如何落实学习.邹老师通过设定简单的人物和简短的话语,图文并茂,使得书本远离枯燥无

《构建之法》读后感(一)

写<构建之法>读后感的想法,其来已久,一直未能完成.拖延症爆发的原因大概有二,一是感觉吸收的不够丰富而无法反刍,二是选择不好读后感切入的角度.<构建之法>2014年出的第一版,买到书时已是开学季,想要调整构建之法的模式,需要做很多准备,备课调整的工作来不及.但<构建之法>"给任课老师和助教的建议",既有妥帖的课程安排计划,也有师生关系的明确定位,还给出了直面教学实践问题的建议,这极大增强了将"构建之法"引入软件工程实践教学的底气.

《构建之法》读后感

<构建之法>给我的第一映像是“终于有一本我可以看的下去的关于软件的书了╥﹏╥...”.<构建之法>与其他的软件工程的书不同,没有密密麻麻的字,没有晦涩难懂的词汇,没有让人看不下去的感受.邹欣老师用一种特殊的方式告诉我什么是软件工程. <构建之法>最大的特点是那些虚拟人物的对话,他们之间的对话就是现实中许多工程师在工作中会遇到的问题.在书中邹欣老师通过阿超.国栋.小飞.小李等虚拟人物的对话以及他们答辩.讨论形象生动得说出了工程师们在遇到问题时的困惑,以及思维方式,并对他们

《构建之法》读后感系列之二

关心自己更关爱你 “本是同根生相煎何太急”,大家都是程序员,规范自己的代码结构不光方便自己还方便看代码的人. 还记得大二的操作系统上机,我的代码因为是在vim里编写的,实在是懒得缩进,大括号也没有对齐,结果在编译时候出错,当时找错误真是找瞎了眼.虽然结果最终是正确了,但是助教检查的时候还是善意地指出了我代码结构的规范性问题. 所以看到邹欣老师在<构建之法>第四章指出的代码规范性问题,给我的共鸣还是很明显的.我认为,程序员在成长的过程中,不仅是知识的不断堆砌,更重要的是不断规范自己的过程.书中指

《现代软件工程构建之法》读后感

通过本学期学习的<现代软件工程构建之法>,让我们对于软件工程有了深刻的了解.基于上学期学习的<软件工程>,延伸了我们的知识.配合本学期<软件的测试>让我们懂得了本书的重要性. 本书共分十七章,结合本学期学习的<软件测试>我们对于本书主要从测试入手.本书有关于单元测试的简要介绍,有关于个人开发的流程,两人合作的代码规范和审查,团队的模式和开发流程,还有软件的分析和设计方法,软件各种的测试方法,运用的测试工具等.就我目前只能了解这些,当然还有跟多,还要我们细细体

第五次作业——《构建之法》读后感

作为软件工程专业的一名学生,这学期接触到了<构建之法>——邹欣.这本书从前言部分就引起了我极大的阅读兴趣,邹老师引用<移山之道>这本书的手法创造了一个虚拟的软件创作环境,不仅贴切实际生活,更生动形象的展现出软件工程的丰富内容.可以说这是一本与现实接轨的教材,会让人在对行业从陌生到熟悉的过程中,较少地感到惊讶和出乎意料.整本书详细的介绍了软件工程的各个方面,运用书中人物的对白来解决我们内心的疑问. 这本书很好的告知我们要避免“以程序为中心”思考问题,而懂得以人为中心来思考,毕竟程序要

《构建之法》读后感5

软件工程涉及的范围很广,对于即将投身IT业的学生而言,软件工程的内容又非常重要.读构建之法,尽管本书介绍了不少IT业正在使用的理论和技术,但是,这本书的主要思想并不是介绍所有的新思想和新技术,而是从这些新思想.新技术中总结出对自己在未来的工作中有用的东西. 在整本书中,印象最让我深刻的是"两个人的合作"这一章节.现代的软件产业经过几十年的发展,软件的结构随着用户需求的不断增加,软件的功能不断朝多元化与复杂化发展.不管是两个人的合作还是团队的合作,谈到合作不免提及规范这个词.你写出来的代

《构建之法》读后感和团队项目杂谈

<构建之法>将软件工程的各个组件分门别类,横向地介绍了软件工程这一体系.然后又在每个类别中纵向地由浅入深,逐步递进, 较为完整地让我们这些菜鸟初识软件工程. 经过一个学期的学习,<软件工程>搭配着<构建之法>进行学习,我也对软件工程有着一定的了解.软件=程序+软件工程,个 人认为,如果说程序意味着实现,那么软件工程更加侧重“方法”和“规则”.似乎软件工程是一个新兴的学科,它的方法论是一群富 有经验的大牛从他们丰富的编程经历中提炼的精华和吸取的教训(我个人的臆想),没有特