第四章与第十七章阅读有感

第四章 两人合作

此章主要讲了两人合作中的主要注意事项,最主要的是代码规范与代码复审

我的困惑也主要来自这两个地方

代码规范方面:

①P61缩进问题,本书提倡用空格而不提倡用tab键。但是我个人在编写代码时,工作室学长有提醒我最好用tab键。他向我展示了空格与tab键两种编写代码方式,其中明显tab键更加美观和清晰。本书解释的不要用tab键的原因是tab键在不同情况下会显示不同的长度。但在团队中大家使用的编译器应该是同一个,tab键的缺陷其实在团队作业中并不明显。那么在这种情况下应该选择大家认为最方便最美观最熟悉的方式不是么?

     ②p61断行和空白的{}行,这个问题的困惑同上,我认为应该选择团队一致认为最方便好看的方式不是么?我们工作室使用的是格式C,我之前在用格式D时还被说了。

③p66关于goto,我们的c语言老师林和平老师在讲这个的时候一直强调,不要用goto。所以本书觉得goto很好,不知道是为什么呢?

代码复审方面:

①虽然代码复审确实对代码规范什么的很有帮助。但当阅读到,找到代码错误比如编码错误,比如一些碰巧骗过了编译器的错误。但如果是骗过编译器的错误,那一定也是非常聪明的错误,那么如果有这么个情况。你已经写了一个完整的项目,在代码复审的时候发现有一个骗过编译器错误,如果改掉这个错误,你将要修改接下来的5000多行,那么,是改还是不改呢?

第十七章 人,效绩,职业道德

这一章主要讲了团队合作的注意事项等等。

①唉,这一章吧,最无语的恰恰是比喻。

猪自己割了自己的肉,提供猪肉,鸡自己不要娃了,提供鸡蛋。结果为了创业,这是在图个啥呢。。。。。。作者在改版这个书的时候,可不可以换一个比喻呀。。。。这个比喻真心无语。。。。。

不过忘掉这些猪,鹦鹉吧。

这章讲得还是挺好的。团队合作需要不同的人做不同的分工。可是不同的分工不代表就是做不做事呀。只是术业有专攻罢了。如果把猪比作码农,那么鹦鹉便是营销人员。我个人认为都很重要不是么?

②代码量等于树叶量

貌似有句话叫做“量变产生质变”,代码量应该也是很重要的吧?

原文地址:https://www.cnblogs.com/Dear-Demon/p/8686781.html

时间: 2024-11-06 12:47:50

第四章与第十七章阅读有感的相关文章

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

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

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

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

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

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

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

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

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

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

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

第四章 问题:如果另一个合作者不合作的话,我是应该选择脱离这个团队还是去催他工作? 本章讲了许多关于结对编程的内容,文中写了结对编程的分工问题,结对过程中会出现的问题以及结对合作的不同阶段. 正常来说结对编程是事半功倍的,对于一个项目来说,要用到的专业知识很多,如果一个人来做的话,要一边赶着完成项目一边学习自己不熟悉的知识,但如果找一个人去合作的话,在某种程度上来说是可以达到1+1>2的情况,因为不同的人所熟悉的知识不同,如果让一个项目分给两个人来做的话,就不需要大量的去学习新的知识了. 但是,

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

第四章 问题1:程序各方面的质量只取决于水平较高的程序员么? 引用:在结对编程中,因为有随时的复审和交流,程序各方面的质量取决于一对程序员中各方面水平较高的那一位. 结对编程在我看来是一种合作,对于实力的不均匀,让我想起来了短板问题的故事. 所以对于书中提到的程序的质量取决于更高水平的程序员,我是有一些疑问的.我认为两个人的结对编程,重要的是合作和互补.只有当实力差不多均衡的时候才能发挥到最优程度.书中之前也提到了在结对编程模式下,一对程序员肩并肩.平等的.互补的进行开发工作.同时,结对合作是非

读构建之法第四章第十七章有感

第四章 1.原文:"函数最好有单一的出口,为了达到这个目的,可以使用goto.只要有助于程序逻辑的清晰体现,什么方法都可以使用.--P69" 问题:关于goto,我记得老师讲过,这个在编程中是尽力避免的,所以我在之前并没有了解过它.本书却建议用,这让我产生了困惑. 我的看法:goto语句它可以不受限制的灵活跳转,这样程序员在使用goto语句的时候就很容易因为跳转而略过了一些关键语句.但是它能从多重循环体中跳出,用不着写很多次的break语句.我查了一些资料,发现自从提倡结构化设计以来,

《构建之法》第四&amp;十七章读书笔记

 <构建之法>第四&十七章读书笔记 一.         前言 再次阅读<构建之法>,愈发被其中生动有趣的举例吸引.作为一本给予软件工程学生的书籍,其不以枯燥的理论知识为核心,而是基于对知识和方法的引导.本次研读的这两章内容主要涉及了代码规范,两人结对与多人合作的团队方面等相关知识,从其中逐渐明白与人相处作业等方面的技巧与艺术.以下是我对这两章节的思考与疑惑. 二.        第四章<两人合作>. 本章主要涉及代码规范,极限编程,结对编程,两人合作不同阶段,