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

第四章:两人合作 

问题一:

    引用:“对于至关重要的代码,我们要请不止一个人来做代码复审”

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

问题二:

    引用:“对于至关重要的代码,我们要请不止一个人来做代码复审”

    理解:对于这句话我还有一点疑问,书上说代码复审的方式有很多种,可以是他人,也可以是程序员自己,那么如果程序员第一次敲代码就陷入了误区,那么他在代码复审环节是不是也并不会发现自己的问题所在,所以是不代码复审是不是应该进行多轮,第一轮可以是程序员自己,这也算是他个人提高改善的过程,那么是不是应该再找人进行第二轮以至于第三轮的复审,以达到真正完善代码的目的呢?

第十七章:人、绩效和职业道德

问题一:

    引用:

    理解:书本第十七章和第四章都说到了团队合作的几个阶段,第四章更是运用了这个跳舞的例子向我们阐述了结对编程的整个过程,首先我对于这个独特又鲜明的例子还是很认可的,但看完第十七章之后我就突然在想,虽然不是每次结对过程都是两个不熟的人一起完成任务,但绝大多数情况下都是刚刚认识,我觉得是不是两个彼此熟悉的小伙伴一起进行任务会更好,毕竟很多时候面对不熟的人我们为了避免冲突,一些真实想法不会说出来,这样对任务的进展是不是会有阻碍?或者说能不能早在结对之前先给双方一些时间认识磨合,让这个过程先于编程任务的启动,在我的理解中,编程领域存在很大的竞争,这样做的话是不是能在时间与效率上超越其他小组?

这些只是我结合一些资料得出的个人结论,希望老师能给出一些更加全面的解答,谢谢老师。

原文地址:https://www.cnblogs.com/mzj666/p/8672614.html

时间: 2024-10-05 04:48:16

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

构建之法第四章学习心得

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

读《构建之法》第四章 、第十七章

第四章    两人合作 通过对于<构建之法>第四章的阅读使我对代码规范 . 代码复审 . 以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:简明 . 易读 . 无二义性,代码书写的形式,变量命名的方法,注释程序如何工作都有详细的介绍,令我受益颇多.代码设计规范不光是程序书写的格式问题,而且牵涉到咸亨需设计 . 模块之间的联系 . 设计模式等方方面面,函数的设计,语句的使用,错误的处理,这些都是我们在进行程序设计的时候需要注意的地方.

阅读《构建之法》第四章、第十七章收获

阅读<构建之法>第四章.第十七章 阅读这一章的时候,我意识到了很多以前写程序没有注意到的地方,以前写程序就只知道能运行就好,根本不管自己写的程序占多少内存,运行的时间,是否有优化的空间,写代码的时候也不注意规范,有时候设计的函数根本用不上,造成代码冗余.同时也认识到结对编程的重要性,没读这本书之前就觉得结对编程就是两个人一人负责一个模块,然后合在一起,调试调试.但实则不然,真正的结对编程应该像书中那样,一个是驾驶人,一个是领航人,两个人有规律的进行编程.期间,一人编程一人复审,极大地提高了效率

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

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

构建之法小结四

本周阅读了构建之法的第四章,本章讲了两人合作的前提是代码要规范 (包括代码风格规范及代码设计规范)及代码复审,然后才能结对开发. 以前,写代码时,很多时候是上手就写,一个大括号包含所有内容,虽 然大一时学过函数.类等知识,但写代码时并不使用这些知识. 很显然这样,不利于别人及自己后续阅读代码,因为代码最终是要给人看 的,要想一个团队合作开发,必须有一些大家一致遵守的规则,这样团队 才能良好的进行工作. 在以后的编程实践中,我会注意按照本章的代码规范来编写程序,多加练 习.

谈谈我对构建之法这三章的理解

前言 在第一次作业中我便提过,刚进入大学时,我对未来充满了憧憬,我的人生有着很好的规划,也像我所规划的那样,我的大一过着学习,技术,学生工作有条不紊运行的状态,可是后来为了学生工作放弃了工作室,后来又因为一些原因失去了学生工作,我的人生仿佛失去了重心,浑浑噩噩度过了大二上学期,到了这个学期,上了软件工程导论这门课,我才意识到自己与别人的差距有多大,我下定决心从这学期开始恶补,一定要把差距拉小,直至没有差距.调整好了心态,我翻开了构建之法. 章节一.概论 1."软件=程序+软件工程"这是

读构建之法第四、十七章有感(作业四)

第四章: 问题: 看到这里的时候,才注意到代码中的"下划线"这个东西,在之前的敲代码过程中并没有怎么遇到下划线,在经过百度后得到了一些答案: 这只是Python中下划线的一部分应用,在不同的语言中,下划线的用处也不太相同,而在原文中作者对下划线的解释很简单,对于"下划线用来分隔变量名字中的作用域标注和变量的语义"这句话也不太理解,我认为作者可以适当地放一些代码片段来说明下划线的用法,如果作者提及下划线的原因仅仅是因为命名的话,我觉得完全可以放在下划线的上一小节&qu

读《构建之法》第四章、第十七章

第四章<两人合作> 1.原文:"注释(包括所有源代码)应该只用ASCLL字符,不要使用中文和其他字符,否则会极大影响程序的可植性" 疑问:引擎根本不对空行和注释进行解析,直接忽略掉,它们不参与计算代码行数也不参与程序的执行,对程序执行效率也没有影响,中文和其他字符为什么会影响程序可执行?中文注释不是更容易看到和理解吗? 解决中的发现:python中为什么加上中文注释就会报错? 答:由于Python源代码也是一个文本文件,所以,当你的源代码中包含中文的时候,在保存源代码时,就

Week4-作业1:《构建之法》第四章、第十七章 阅读笔记与思考

第四章 两人合作   这一章是讲述了两人结对编程的一些东西,包括一些代码的规范,还有结对编程的优点.怎么做.以及一些注意事项. 1."错误处理 当程序的主要功能实现后,一些程序员会乐观地估计只需要另外20%的时间,给代码加一些错误处理就大功告成了,但是这20%的工作往往需要全部项目80%的时间." 疑问:"错误处理"是什么概念?它有哪些类型及方法? 思考:我查阅了一下资料,上面解释道"在程序设计过程中,由于某些错误的存在,致使程序无法正常运行,处理这些错误