当前位置: 首页 > 读后感 查看格言:《构建之法(第三版)》读后感10篇_读后感_名著读后感_格言网

《构建之法(第三版)》读后感10篇_读后感_名著读后感_格言网

 时间:2020-12-28 23:46:52 来源:人生格言 
请扫描下方二维码浏览本页手机版

《构建之法(第三版)》是一本由邹欣著作,人民邮电出版社出版的平装图书,本书定价:69.00元,页数:464,文章吧小编精心整理的一些读者的读后感,希望对大家能有帮助。

《构建之法(第三版)》读后感(一):读《构建之法》

今年三月,因为课程需要阅读了《构建之法》第三版,这本书风趣简练的文字、清晰的逻辑结构及对软件工程概念简明生动的阐释让我获益匪浅。

作为一个软件工程专业的学生,惭愧的是在拜读这本书之前,我一直对软件工程的概念没有清晰明确的认识。从大一到大三,我们一直在学习编程语言和编程工具,即使经历的课内外项目不少,我们仍然对如何有规划地做好一个软件工程项目没有深入的了解。这本书可以说是我在软件过程管理及软件设计开发流程方面的入门书籍,具体来说,就是帮助我跳出以往添砖加瓦的码农身份,站在产品经理的角度思考一个成熟的软件产品的产生过程。

身为初学者,在阅读本书后,我对软件工程各种概念有了更为深入的理解,例如NABCD分析、用户体验、结对编程等。这本书更让我认识到,对于一个成熟的软件产品而言,重要的不仅是漂亮的代码,更是架构、功能、交互逻辑、用户体验。软件工程行业需要我们能够完成需求、写出简洁没有bug的代码,同时也需要我们能够搭建项目整体框架、剖析用户需求和心理、与团队中不同职能的人相互配合、进行高效率的软件开发。

《构建之法(第三版)》读后感(二):《构建之法》心得

《构建之法》这本书是很长时间以来读到的第一本能够吸引我的专业书。

学习软件工程这门课,老师推荐阅读《构建之法》这本书,于是与它初次相见。

草草读完整本书,我发现《构建之法》的作者文笔十分幽默风趣,书中把很多专业名词或者专业知识用十分通俗的语言表达出来,甚至我们可以在书中看到很多对话形式的文字,通过这些对话,我们可以学到很多专业知识。相比于市面上很多其他专业书,这是唯一一本能够激发我学习兴趣的书,在学习过程中,我惊异于作者的知识面,也惊异于他对于这些专业概念的理解。生动形象的学习一直是高效的方式,通过这本书,我可以乐在其中。由于时间原因,我并没有十分仔细的阅读,但是通过粗略阅读,我依然能够看出整本书的作者的独具匠心。《构建之法》不仅行文风趣,里面覆盖的知识面也十分广泛,对于一些概念的阐述十分详尽清晰,通过阅读这本书,我们可以全面体会软件工程的全貌,了解软件工程中所包含的各种知识,例如:测试,敏捷开发,开发流程,软件需求,用户体验,团队合作等。阅读这些内容,我可以说自己已经入门了软件工程这门学问。

当然,软件工程实际上是一门十分繁琐,复杂的学科,我们不仅需要学习理论,更要将实践与之结合,如此,我们才能真正学到软件工程的精髓。

《构建之法(第三版)》读后感(三):《构建之法》学习心得

作为一名软件工程专业的学生,我在专业课上学习了很多专业课程,能够编写程序,实现某些具体的功能,但这些都偏向于“软件”,而非“工程”。在阅读这本书之前,我也有过与同学组队共同开发一个应用程序的经历,但那时,我们也只知道分析这个程序应该实现哪些功能、可以拆分成哪些模块、每个人可以分配哪些任务。而在阅读了《构建之法》后,我才发现真正的团队开发,真正的软件工程是有很多流程规范的。

就比如说最开始的选题和需求分析阶段,我们以往的理解就是想想要实现什么功能,决定好了就可以开始写代码了。《构建之法》却告诉我们,需求分析没有这么简单,开发者要能发现目标用户的需求,要区分需求的优先级,要编写出明确的规格说明来指导开发,编写代码前还要对软件结构进行分析设计。在软件开发的过程中,分析、设计、管理这些理论工作的重要性,不比写代码的重要性低,这是《构建之法》带给我的最深刻的感受。

可以看到,作者非常强调“人”在软件开发中的作用,软件是应人们的需求而诞生的,开发过程中也要协调开发者之间的工作,开发结束后还有反思的阶段。得益于此书,我对软件工程这一专业有了另一个角度的认知,了解了如何参与到团队中,开发出一个健壮的、有用的软件。当然,最重要的始终是实践,“做中学”,也是本书一直强调的事情,我们要在实践中发现问题、解决问题,在实践中成长。

《构建之法(第三版)》读后感(四):纸上得来终觉浅

大二坐火车时,读了这本书的第一版,当故事书看。当时没有参与过任何项目的开发,虽然我现在也没有多少项目经验。研一,在杨贵福老师所开《软件工程》课上,跟随这本书的第三版体验了一番。单人的项目,由于我有过参加acmicpc竞赛经历,很轻松。结对编程和单元测试也这么过去了。由于知道这种规模的代码如何写,因此没有受到锻炼。团队项目也是。一个团队多达七人,诚然做视频写文档也算工作量,但如果再来一次,我宁可单打独斗。合作者的能力与决心不匹配,就如同几个人向着不同的方向拉车,拉得四分五裂。书中的思想,如测试,如运行,如维护项目,在邹欣老师博客中扩展了很多。提问题是对你如何提高给出角度而不是对你个人的反对,这是我在这门课上最大的收获。倘若真的过一遍书,该有不小收获。找到志同道合的人,读万卷书,行万里路。每个人对成功的定义各不相同,我来定义的话,应当如此。

《构建之法(第三版)》读后感(五):《构建之法》泛读

刚开始看这本书的时候就感觉这和一般的专业书有很大的不同,更有趣味性,像讲故事一样,对刚入门的学生来说很友好。 软件工程是把系统的、有序的、可视化方法应用到开发、运营维护中这样就会遇到各种的问题。例如一个最经典的的问题就是“BUG”,很多人认为BUG就是废材,没有用的东西。但是在邹欣老师的把BUG认为他不是缺陷反而它是一种不能正常发挥的一个功能,所以老师希望我们能够正视你自己的代码的BUG,而不是一味的抛弃他,我们要从BUG中找到有用的信息在软件工程开发的对于BUG的检查。就涉及到单元的测试,单元测试是软件工程开发的一个重要的过程我们对于这个方面一般由作者自己代劳。因为这个是对于你开发时的一个基本的简介所以由作者自己代劳就会使整个程序的或者工程更加的具有可读性,并且更好的去实现他,,当然我们在开发的过程要时刻注意代码的规范问题因为你写的代码不只是是你一个人看,因为软件工程项目的开发会涉及许多的人,所以你的代码规范性就至关重要了。所以一个好的代码不仅要实现好的功能,更要的能让你的团队更好的去维护他。这样目地就达到了。

开篇作者就说了“软件 = 程序 +软件工程”,以前写软件或者说程序,就只是写程序,最多会考虑到数据结构的知识,很少会用到软件工程,但是随着学习的深入,代码量的累积,如果还是和以 前一样只是关心程序只要是可用的,实际可运行的,那么就没有意义了,这样的程序写出来也是没有价值的,首先,软件工程不仅仅就只是涉及到计算机或者软件方 面的知识,相反,软件工程涉及了很对其他学科的知识,比如:管理学、数学、工业设计等等学科,一个合格的软件开发人员如果只是懂得怎样去写程序,那么嗨仅 仅只是初级阶段,更高级的应该是从一个更加高级的层面上去考虑更多的东西,如整个软件的架构。 整本书从实际软件开发的各个阶段出发,详细地分析了软件工程的各个环节,如:需求分析、设计实现、用户体验、软件测试已经最后的发布等等。

敏捷(Agile)开发,也是一个很早就提出来的技术解决方案,敏捷是一系列的价值观和方法论的集合,前人通过 不断地实践,总结出来的开发方法及开发过程,对我们现在的开发有很强的指导意义,敏捷开发的原则很多,其中印象最深的就是“经常发布可用的软件,发布间隔 可以从几周到几个月,能短则短”,以及“可用的软件是衡量项目进展的主要指标”,我的理解是敏捷开发强调的是“小而美”,定期地完成一个小版本的软件项 目,比只是最终发布产品要好的多,这样也有利于产品的迭代,敏捷中的Scrum方法论,看起来简直就是无与伦比:要做什么- 当前要解决什么 - 冲刺- 得到一个增量版本。分阶段地不断递进地解决问题,但是敏捷也有很多的弊端,敏捷宣言不是圣旨,不必完全尊从,就像是Scrum, 实际执行的时候也不是看上去那么美好,在一个复杂的项目中,往往不能带给团队更多的惊喜,所以,敏捷慎用 。

最后来说说软件测试,不仅仅是这本书中,几乎所有的介绍测试相关的书籍,都对测试讲得很多很多,说到测试,大家最熟悉的就是黑盒、白盒测试等,要写好一个不错的测试,首先要有一个好的测试方法,如:Unit Test、Function Test、Structure Test、System Test等等,测试方法多种多样,关键是怎样找出合适的测试方法最好地完成测试,怎样写一个Test Case?这个好像很麻烦,你必须首先知道并熟悉这个需求,要写出一个完整的测试过程,要考虑好测试的边界值的选取,极端情况下程序的健壮性,所以写好一个测试不简单。 学好软件工程也是不简单的。

《构建之法(第三版)》读后感(六):读《构建之法》之感

专业原因,我有幸读了《软件工程》这本书。这本书内容详实、条理清晰,从一个个虚拟的软件开发故事出发来进行讲解,生动形象,浅显易懂。本书一共有17章,每章都有一个明确的中心主题。结合课程作业,我获益匪浅。

其中令我印象最为深刻的是第8章(需求分析)、第10章(典型用户和场景)、第11章(软件设计与实现)。以前每次做项目或做课程作业,我们总想着只要能实现功能就可以了,大体任务已确定就开始着手写代码。没有需求分析,没有项目规范,也没有完善的源代码管理体系。经常会在写了一部分后才意识到还有更重要的前序功能没有实现,于是“捡了芝麻丢了西瓜”,最后一片混乱,看似功能都实现了但其实每个功能都不完善,bug多多。典型用户和场景的分析有助于开发人员站在实际用户的角度上去思考问题,加强产品和用户的紧密联系;前期的需求分析有利于开发人员更好地梳理项目,明确项目到底需要实现哪些功能;确定功能的优先级可以帮助开发人员确定功能实现的顺序及其重要性,合理分配时间精力和资源,以达到效率的最大化;完善的源代码管理有助于开发小组人员之间的沟通合作,减小项目整合的难度,加强版本控制与管理。比如码云、github等等,都是很好的版本控制工具,团队合作的项目一定要对其加以合理应用,才能有效提高项目开发的效率。

其次还有第5章(团队和流程)和第6章(敏捷流程)。对于规模较大的项目而言,团队合作至关重要。团队要有一致的目标和详细明确的分工才有可能按照预期计划完成项目。这时,团队的合作模式就至关重要了。不同的项目适用于不同的合作模式,我们在开发、运营、维护软件的过程中所具有的技术、做法、习惯和思想等都应该统一在“软件开发流程”里,以提高软件的开发、运营和维护的效率,提升用户的满意度及软件的可靠性和可维护性。

这本书还有其他很多方面的讲解,以“软件开发”为核心,从各个方面细致讲述了软件工程,对于我们开发出符合用户需求的、在预计时间内“足够好”的、可维护可持续发展的软件产品具有很大的指导意义,值得细细品读。

《构建之法(第三版)》读后感(七):《构建之法》书评

作为一名软件工程的学生,我的最直观的印象就是这本书给了我一个初步的对于一整个项目开发的过程的概念图,让我找准了自己感兴趣的方向和准确的定位以及今后还需努力的方向。

本书作者以激发学习兴趣为目的,通过对话、类比等方式来阐释专业知识。内容从前期准备、软件工程师的个人能力和发展到合作项目的过程中的团队和流程问题,以及软件工程中的不同角色和作用以及项目后期的测试与发布都有涉及,而且详尽地、尽可能浅显易懂的让读者明白概念和理论,同时也面向实战,强调做中学。在我自己的团队项目过程中,各个过程中都有参考本书资料,通过阅读这本书的相关部分,我明白了项目的重点、文档的编写、后期要注意的事项以及各种困难的解决方法,十分实用。

同时通过阅读这本书,我们可以全面体会软件工程的全貌,了解软件工程中所包含的各种知识,例如:测试,敏捷开发,开发流程,软件需求,用户体验,团队合作等。阅读这些内容,让我懂得在软件开发的过程中,分析、设计、管理这些理论工作的重要性,不比写代码的重要性低,且规范化的流程可以帮助我们更快、更高效的完成任务,而且出现错误能够及时补救。虽然在做团队作业过程中,要实时上传项目进展、定期展开会议、制作燃尽图、UML图等等工作,但是最终确实学会了很多技能、也明白了这些过程的必要性与重要性。

另外,这本书让我明白软件开发是一件很愉快、很有意思的工作,有很大的实用性,而且“人”在开发过程中起到的作用是非常大的,每个人都不应该被忽视。可以说这本书让我受益匪浅。

《构建之法(第三版)》读后感(八):《构建之法》书评

这是一本很有趣的软件工程类的书籍,很容易被带入到书中的软件工程类的故事中,这里推荐给学习软件工程的同学。

初览

看到这本书的前言(第三版—第一版)的时候,就在想这应该是一本很有趣的软件工程类的书籍,于是就被带入到书中的软件工程类的故事中,这里推荐给学习软件工程的同学。

在第1章概论中,以程序员阿超为儿子的幼儿园编写程序到最后需要为一个学校构建一个系统为例,从源程序切入,向读者们描绘了软件工程的大致轮廓。和其他书本的介绍方式不同,该书并没有直接从软件工程的领域入手,直接讲解需求分析、软件测试这些领域的内容和具体实践,而是先教导我们如何成为一个入门级别的软件工程师。

作为一名软件工程专业的学生,很深刻地认识到,校内软件工程专业和计算机科学与技术专业的性质差别。和书中提到的类似,相比于偏理论的计算机科学,软件工程似乎更注重培养学生的工程经验,而这本《构建之法》正是我们学习工程的一个得力助手。

不得不说,这本书的风格独特,文笔活泼,用故事讲解理论,用实例展示细节,很容易阅读。想要初步了解软件工程师的工作和成长可以深读2-4章,从个人技术到完成个人项目,再到团队协作和规范编码,优秀的工程师不仅能编写出让人赏心悦目的代码,也常常会在项目中发挥举足轻重的作用。

实战

作为软件工程这门课程的辅助教材,《构建之法》一书给我们的项目作业提供了很大的帮助。从团队作业的这几个阶段来看,老师应该是希望我们采用敏捷开发的流程,先选定一个需求方向,找到完成产品需要做的事情,然后进行组内讨论和分析,完成初步的功能设计(包括原型图设计、UML图设计、数据库设计),再开始进行代码编写。代码编写的过程包括实现和测试。在敏捷开发过程中,会有一个冲刺阶段,我们实战中分了两个阶段—两周的alpha阶段和两周的beta阶段。理想化的冲刺阶段应该是每日例会和每日汇报,然而对现在一群“丧气满满”、不注重课程作业的大三学生来讲,真的很困难。在团队作业(预计“秘密团队”模式,最后还是变成了“主治医师模式”)中,毫无疑问地遇到了很多困难,比如使用angularjs的语法时出现的新旧分歧,很多功能没有人认领这些问题,分歧部分我们俩讨论了一下按照一种语法进行修改,没有人认领的功能在alpha阶段未实现,到beta阶段才实现。

遗憾

很遗憾的是,在项目开发的这一个月之内,很少有时间去读《构建之法》和《软件工程》这两本书,忽略了其中提到的一些方法和细节,再次攻读《构建之法》,发现无论是项目还是个人都有很多需要改进的地方。关于需求分析部分,老师让每个组选择一个内容,每个人都要求按照NABCD的模式阐明观点。事实上由于空间和时间的原因(当然也是因为能力不足,暂时不会进行大数据分析),需求差不多是按照个人意愿来选择的,这样的坏处是不能够了解到真正的市场需求,只局限于提出该需求的个人或者同类型有限制的小群体。相比于正规的软件开发,我们在作业中表现的态度还是过于草率。典型用户和场景这一部分的分析还得感谢老师的建议,帮我们锁定了用户范围。基本功能实现后,请用户体验测试(班级其他同学)时,用户也的确遇到了一些问题并且善意地提出了建议,例如某些功能不明显、界面设计风格有点突兀等。总体来说,老师为我们这个课程制定的学习路线是很好的,对一些idea的看法也很成熟,我很喜欢年轻老师,也谢谢老师给我们推荐了一本好书。

《构建之法(第三版)》读后感(九):《构建之法》-实用与趣味并存的软件工程必读书目

初读《构建之法》,其强大的实用性和超级趣味性吸引了我,作为一名软件工程专业的本科学生,能够通过此书来学习软件工程,有一种莫大的荣幸,很感谢邹欣先生,能够让我在极大的阅读兴趣中学习了解软件工程的许多思想和实用方法。

在知识层面,这可以说是一本匠心独运、干活满满的软件工程书籍;其中的很多知识点,值得整理和深刻记忆;书籍从软件、软件工程的定义入手,逐步讲解了包括单元测试、个人开发流程等个人技术流程;软件工程师思维、职业发展等未来发展方向;代码规范、复审等合作内容;软件团队模式、开发流程等团队内容;敏捷开发相关内容;简介微软使用的MSF软件工程模式;需求分析;PM;典型用户场景和案例;包括后续的软件测试;用户体验;质量保证;个人绩效和职业道德等;几乎涉及了作为现阶段专业学生所需要的一切软件工程方面的知识,从知识的脉络到整体逻辑,都能够很好的一步步带领阅读者,从基础的个人层面到团队合作;从软件开始阶段的需求分析到测试发布逐步了解学习,最终形成完整的知识架构体系。

本书的阅读体验可以说是极好的,作者传递知识的方式充满趣味性又不失严谨,关键的是,干货知识满满却能够很好的被阅读者逐步吸收消化。更令我印象深刻的是,这本书对于软件工程学生在各方面潜移默化的严格要求和激励,以及其在学生心目中书里的好的软件、好的软件工程开发团队的标准,更深层次的,帮助学生了解此行业入职后的工作方向、未来发展方向等,这些都是重要的知识。对于迷茫中的本科学生,此书不仅充实了在软件工程方面的硬知识,更梳理了此行业未来的发展方向,帮助学生更好的对未来发展、团队定位进行思考;同时,编程之美的思想深深的影响着阅读者,编程真的真的是一门艺术,每一个项目都是一个做工精美的工艺品,怀着这样的心情和标准去编程,能够做得更好。

作者本人拥有北京大学计算机软件专业学士学位,并在微软开发团队工作多年的经验,《构建之法》第三版也是作者继《移山之道》,《编程之美》后的又一作品,其专业性、实用性、创新性都有很高的保证,通读此书,受益良多,希望更多的读者能够和我一样,在这本书中学到现代软件工程的理念、思想、知识,同时对行业和未来方向有更多的理解和思考。

《构建之法(第三版)》读后感(十):读《构建之法》的感悟

本人是一名大三学生,本学期有一门叫做“软件工程”的课程,在第一节课上,老师推荐了《构建之法》这本书,于是便有幸的接触了这样一本有趣的书。

软件工程作为软件开发的一个基础的知识领域,比起去学一门编程语言,它的入门要麻烦许多。软件工程作为工程学的一个子类,需要从软件开发需求分析开始讲起,然后概要设计,到最后的软件提交发布。这个过程包含许许多多的细节。市场上有许许多多软件工程的教辅书,这些书通常采用比较经典的瀑布模型,从需求分析,概要设计开始讲起,直到项目提交发布。但是这样的目录编排会露出许多实际项目开发的细节,但《构建之法》这本书启动过程比较平滑,从环境和知识准备,再项目规划和组织,再到最后的产品发布,更新。整个过程递进的较为平滑,循序渐进。此外《构建之法》这本书中含有讨论协作环节以及场景介绍。一方面可以生动活泼的讲述所要表达的知识,另一方面可以带动读者真真正正的进入项目开发的实际过程中。

总之,邹欣老师的《构建之法》这本书是一本不错的教辅书,无论你是刚开始学习软件工程还是已经踏入职业岗位,这本书都值得一读!

请用微信扫添加公众号