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

第四章

  问题1:程序各方面的质量只取决于水平较高的程序员么?

  引用:在结对编程中,因为有随时的复审和交流,程序各方面的质量取决于一对程序员中各方面水平较高的那一位。

  结对编程在我看来是一种合作,对于实力的不均匀,让我想起来了短板问题的故事。

  所以对于书中提到的程序的质量取决于更高水平的程序员,我是有一些疑问的。我认为两个人的结对编程,重要的是合作和互补。只有当实力差不多均衡的时候才能发挥到最优程度。书中之前也提到了在结对编程模式下,一对程序员肩并肩、平等的、互补的进行开发工作。同时,结对合作是非常关键的一个因素,如果两个人像拔河一样的工作,那么怎么可能有成效?所以在我看来,一个程序的各方面质量其实取决于两人的合作精神以及互相帮助提高能力后共同实力的体现。

   问题2:goto方法可以使用么?

    引用:函数最好有单一的出口,为了达到这一目的,可以使用goto。

  在以前的课中,我记得老师说不可以使用goto,于是我查询了资料

   

   因此我也查阅了很多网上的资料,大多数声音都是反对使用goto,主要原因就是goto打乱了结构化设计,我们习惯于顺序执行的代码,而goto会使代码复杂的程度大大增加,但同时带来的好处是会让代码变得更加简洁,在许多系统的源码(例如linux)就大量使用了goto语句,goto语句在复杂的编码中会为代码的编写者节省大量的时间与空间,但会让其他非编写者难以理解,我个人并不反感使用goto,因为如果真正用好goto语句,会为我们的编码带来很大的便利,需要注意的是,goto使用的时机与方式是否正确,如果真的有益于整个程序,那么未必不是最佳选择。

第十七章

   问题:所谓的“影评家”难道对我们的影响都是不好的么?

   引用:影评家不拍电影、也没有演技,但是他们对电影的一切都可以指手画脚,而且不必承担任何责任,最高领导往往还挺容易受影评家的影响!你在辛辛苦苦做项目的时候,是否又一圈影评家再围观?

   从书中的“指手画脚”等词语来说,作者认为的影评家应该是一个只会说但是不会做的一种角色,但是在我看来其实所谓的影评家应该在一些方面来看是起到积极作用的。正如我们看一个电影来说,看电影之前,很多人会去上网百度这个电影的影评,从而推断出这个电影适不适合自己去看。所以导演如果希望影评家能够对自己的评价很好的话,就要努力拍出符合大众审美并且更加吸引人的电影,这样才会又很好的票房。同样的道理也适用于我们的代码世界。在工程师编写程序的时候,最终的目的是为了让用户有更好的体验。在编写的时候,如果有一些“影评家”能够围观你的代码并对你的代码加以点评,完全可以让自己的程序内容提高很多,这样以后的用户体验感也会更强。

原文地址:https://www.cnblogs.com/FrrLolix/p/8682050.html

时间: 2024-07-31 02:47:24

读《构建之法》第四章、第十七章有感的相关文章

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

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

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

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

读构建之法8、9、10章有感

第八章.需求分析 书中介绍了一些获取需求的常用方法.流程.及分析框架,看了后才发现原来需求分析还有着者这么多的学问. 以前听人说,需求分析在实际项目开发中所占分量很重,甚至往往需要花的精力比敲代码要多.我听到时不以为然 ,认为需求分析不就是看一下软件要什么功能,要做成什么样而已吗.再后来,我真的接手了一个小商业项目的需 求分析任务,才明白需求分析是一件多么让人崩溃的事情,客户对软件编程一无所知,只是含糊地给我一些文档, 而我又不清楚他们的业内流程.业内术语等,不知道如何去获取对需求,只能像只无头

读构建之法 第四章:两人合作

程序员写的代码最终是人在看,所以代码规范很重要,原则是:简明,易读,无二义性. 不光是程序书写的格式问题,还牵涉到程序设计.模块之间的关系.设计模式等方方面面. 代码复审的正确定义看代码是否在代码规范的框架内正确的解决了问题 代码复审的目的在于: 1.找出代码的错误,比如: 1)编码错误,比如一些碰巧骗过了编译器的错误 2) 不符合团队代码规范的地方 2. 发现逻辑错误,程序可以编译通过,但是代码的逻辑是错的 3. 发现算法错误,比如使用的算法不够优化,边界条件没有处理好等 4. 发现潜在的错误

构建之法第四、第五章读后感

第四第五章着重讲了合作的重要性,从两人合作到团队合作,编程开发都不是一件容易的事情,要注意许多要点. 代码书写的规范. 你写的代码不仅仅是给机器看的,给你看的,也是给其他人看的,是给合作的队友看的,在写的过程中要注意规范,要注意缩进.行宽.对齐等格式. 代码设计的规范. 函数中,你就只实现函数的具体功能,如构造函数,简单初始化所有数据成员即可. 代码复审. 找出代码的编辑错误.逻辑错误.算法错误跟潜在错误. 合作需要讲究技巧,要运用合理的方式影响合作的对方,尽量运用逻辑加感情,使对方能快速地接受

构建之法第七,第十七章读书有感

第四章 两人合作 关于合作中算法的使用 在第四章的叙述中,我们看到了代码的编写规范,代码的命名规范,我们还知道要写注释,要有良好的代码设计和错误处理.而这些都是我们在使用语言进行编辑中的问题.我们要阅读结队队友的代码,了解功能实现,明确函数意义.之后还要进行代码复审. 但是我们同时也知道,在代码实现的过程中,我们的分工是有侧重的.而同一个事情的完成是可以使用一些成型或自己的算法进行优化的.而如果我们在使用一个比较"复杂"(是指思想复杂而实现简单,例如dp,kmp,manacher算法等

构建之法第四章学习心得

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

读《构建之法》第4,17章有感

读<构建之法>第4,17章有感 第四章:两人合作 原文:另外,注释(包括所有的源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 我的问题和看法:对于英语水平没有那么高的人来说,不允许中文注释真的太难了.刚开始学习代码的时候,老师就教导我们编程的时候一定要写注释,但是并没有非常严格的要求我们必须要用ASCII字符.我上网查找了一些资料,发现大部分公司对于注释并没有明确的要求.注释是为了方便让别人理解你的代码的,所以简洁易懂应该才是最重要的,在水平达到的情

读《构建之法:现代软件工程》第一章有感

在阅读了<构建之法:现代软件工程>第一章绪论后,我软件工程有了一定的了解,同时以一名机械学生为立场也有所感悟. 以前我只是简单的认为软件就是一个应用,你只需要去点击.exe文件就可以使用这个软件.而在阅读了邹欣老师的<构建之法:现代软件工程>后,我懂得软件=程序+软件工程,我们现在不应再停留于软件的用户体验.交互界面,更应该看到软件背后支撑它的程序代码等.软件工程是一个学科交叉的过程,它与许多学科都相关:计算机科学.计算机工程.管理学.数学.项目管理学.质量管理.软件人体工学.系统

读《构建之法》第4、17章有感

    诗云:半亩方塘一鉴开,天光云影共徘徊.问渠哪得清如许?为有源头活水来. 这是宋代理学大家朱熹对阅读一本好书的感受.这几天我看了邹欣老师写的<构建之法>第4.17章之后,产生了一点点类似的感受.下面我来点评一下. 关于"第4章 两人合作"的点评: 问题一: 原文(见第68页):另外,注释(包括所有源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 个人见解:可移植性是指代码在不同平台能否执行.注释会被执行吗?不会.那么,注释就与