构建之法 第四章 读后感

在第四章中说“合作的最小单位是两个人“,两个工程师相互看代码并给出自己的意见,所以代码的规范性是极其重要的,我们的代码不仅要让机器读懂也要人也能读懂,在第四章的学习中,我也尝试着和别人结对来编写一个程序,效果相当的不错,规范的代码让我们都能够方便读懂对方的程序,同时也能提高彼此的能力,取长补短,形成互补。

4.1大节提到的代码规范,我们编写代码时要注重代码风格规范和代码设计规范,无论是类名,对象名,缩进还是行宽什么的,在结对子编程时都要有所规定,不然到后面出现的类或是对象多了,就很容易混乱,分不清楚谁是谁。要学会封装,编写函数,将功能模块具体化,减少主方法里面的代码,避免大规模的出错。

4.4中提到了代码复审,在平时编程程序时,我也会从头到尾的查看自己的代码,运行程序,若是多次结果相同,无误就可以了。没有想过发现代码错误外,还去思考逻辑是否有误,算法够不够优化等其他问题。他人能否觉得我所编写的程序是否简单易懂,能否从中学习。

4.5结对编程,两人合作,一同思考一同编写程序,有利于提高效率,相互学习。所以要学会4.6节提到的合作的不同阶段和技巧,一开始探索项目时,中途遇上不可解决问题时,后期简单的复查时,可以独立思考,期间思路清晰,沟通良好时,一起结对编写,加强合作。在合作中在客观全面的对待自己的结对伙伴,懂得相互鼓励,相互学习。

时间: 2024-10-19 22:41:36

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

0405构建之法第四章--读后感

<构建之法>这本书的第4章讲的是关于两人合作的内容,对于书里所说的两人的关系就和驾驶员.领航员类似,通过结对合作,令我意识到了编写程序不仅仅要自己能明白,也要便与他人查看和理解自己的程序. 代码规范性,我们编写代码时要注重代码风格规范和代码设计规范,无论是类名,对象名,缩进还是行宽什么的,在结对子编程时都要有所规定,不然到后面出现的类或是对象多了,就很容易混乱,分不清楚谁是谁.要学会封装,编写函数,将功能模块具体化,减少主方法里面的代码,避免大规模的出错. 代码的复审,在平时编程程序时,我也会

构建之法第四章读后感

代码规范是必要的,因为写的代码不是给机器看,而是给人看的.“代码规范”可以分为两个部分:代码风格规范和代码设计规范.代码风格的原则是:简明,易读,无二义性.代码设计规范:程序书写,程序设计,模块之间的关系,设计模式等 通过代码复审是软件工程最基本的复审手段,就是同伴复审.这样做可以找出代码的错误,逻辑的错误,算法的错误,潜在的错误和回归性的错误,修复存在的bug 两人合作要经过萌芽阶段,磨合阶段,规范阶段,创造阶段,解体阶段.两人在一起合作,自然会出现不同的意见,每个人都有自己的想法,在两个人平

构建之法第四章学习心得

今天我学习了构建之法第四章,主要讲述了两人合作的理论和知识点.合作,无论在任何领域,都是不可缺失的,往往能产生不可替代的效果.同样在软件设计中也是如此,经过我的学习,我了解到软件设计中两人合作主要包括包括代码规范.极限编程.结对编两人合作的不同阶段以及影响他人的技巧. 其中最让我印象深刻的是代码规范.包括:代码风格规范和代码设计规范,代码风格规范主要是文字上的规定,看似表面文章,实际上非常重要:代码设计规范牵涉到程序设计.模块之间的关系.设计模式.等方方面面的通行原则: 同时,我了解了代码风格规

《构建之法》第一章读后感

身为本科计算机专业二年级的学生,在老师的推荐下阅读了<构建之法>,这几天读了这本书的一部分,发表一下自己的感受,这本书让我对自己的专业有了更加深刻的了解. 在第一章中讲述了学生和老师的关系,老师在课堂上也有所提及,要我们学好软件工程,并应该努力的去编程,老师起到的作用就是督促我们,给我们学习的压力,这样才能在软件工程的道路上越走越好,越走越稳.而大多数人在编程的路上总是被懒惰所打败,不愿意去做认为是枯燥的,或者认为自己做不到,老师布置的作业也总是糊弄完事,在读了一部分这本书之后,或许会有另一种

构建之法第十一章读后感

本周进行了构建之法的第十一章软件设计与实现的学习: 第十一章主要讲了典型的开发流程,常见的分析和设计方法:ERD,DFD,UML,开发阶段的一些管理方法:每日构建,小强地狱,构建大师: 分析和设计方法包括以文字为主的文档,以图形为主构造的模型,用数学语言的描述,用类自然语言+代码构造的描述,原代码加注释也能描述: 图形模型和分析方法:1表达实体与实体之间的关系如思维导图,实体关系图,Use Case Diagram.2.表达数据的流动.3.表达控制流.4.统一的表达方式. 其他的设计方法包括形式

构建之法&lt;第四章&gt;之感悟

第四章:两人合作内容出处:4.6 两人合作的不同阶段和技巧 本章主要是讲关于合作方面的,文章以刚刚认识的两个人为例!也就是说,他们之前的关系是陌生人,然而在现实当中两人合作也可以有其它的关系,比如说合作的两人彼此是情侣关 系,那应该怎样合作呢?如果男的与女的合作前,男的对女的千依百顺,再合作时,当女的意见是错误的并且女的非常强势,而男的意见是正确的,这种情况之下应该怎么办呢?又 如,如果合作的两位伙伴,在合作之前是师生关系,这样又怎么办呢 另外我也和别人合作过,不过我们到了磨合阶段后就永远停留在

《构建之法》6-7章读后感、问题及对Scrum的理解

第6章读后感: 看完第六章后了解什么是敏捷流程.“敏捷流程”在软件工程的语境中是一系列价值观和方法论的集合. 我觉得敏捷是比较人性化而且让人比较轻松的的一种方法吧,它会比较注重交流,而不是硬性的规定和要求,比如用户与开发者之间的交流,团队内部成员的交流等等,分工合作等会比较公平,而且会比较注重效率,会经常更新自己做的软件,会有长期的一个规划,有计划的去完成任务,团队进步会很快. 第7章读后感: 本章主要说了MSF的原则,MSF团队模型和开发模式,MSF和CMMI.MSF的基本原则是推动信息共享与

《构建之法》1-5章读后感

概论 第一章:打开第一章时,我想到的是:什么是软件和软件工程是什么,在阅读中让我感到很困惑,但经过仔细阅读之后我大概地了解,最后我还不太明白的是怎样才能做更好的软件? 个人技术和流程 第二章:在这章中让我想到了怎么提高个人水平和技能?一个人怎样独立开发程序和发现问题?培养个人写程序的习惯和个人开发流程中要注意到哪些问题,特别是在程序的测试中下大量时间. 软件工程师的成长 第三章:阅读到这章,让我学到了软件工程师的成长的历程,软件工程师在各阶段的能力,同时让我感到很困惑的是怎样才能让自已成为一个好

谈谈我对构建之法第四章与第十七章的理解

第四章:两人合作  问题一:     引用:"对于至关重要的代码,我们要请不止一个人来做代码复审"  理解:我对于这句话有些疑问甚至有些反驳.首先我觉得每一段代码都是应该被重视的,也许对于一个刚入行的程序员,他对代码的态度就决定了他以后得发展前景,只有真正把代码当回事的人才能一步一步写出好的代码,完成好的工作,所以我觉得是不是应该不管是什么样的代码,都应该用相同的态度去对待,都应该找多个人去进行代码复审呢? 问题二:     引用:"对于至关重要的代码,我们要请不止一个人来做