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

第四章

问题:如果另一个合作者不合作的话,我是应该选择脱离这个团队还是去催他工作?

本章讲了许多关于结对编程的内容,文中写了结对编程的分工问题,结对过程中会出现的问题以及结对合作的不同阶段。

正常来说结对编程是事半功倍的,对于一个项目来说,要用到的专业知识很多,如果一个人来做的话,要一边赶着完成项目一边学习自己不熟悉的知识,但如果找一个人去合作的话,在某种程度上来说是可以达到1+1>2的情况,因为不同的人所熟悉的知识不同,如果让一个项目分给两个人来做的话,就不需要大量的去学习新的知识了。

但是,如果另一个同伴不合作的话,需要一直去催促他去完成自己的工作,虽然有可能一直去催促的也不会拖太多工作进度,但这种情况给我的精神以及心情上带来的压力可能比自己完成项目都大,那这个时候我是应该选择脱离这个团队还是继续去催他?

第十七章

在前几天,我们的班级群里就有过一次关于软件工程师的职业道德的讨论,所以我就比较关注这章对这一部分的讲解,书中说软件工程师有八个原则,所以我以这八个原则衡量了群里提到的抢票软件的问题,关于那个问题,很多人都是围绕原则一讨论的,因为个原则是比较难统一的。

我并没有在群里说我自己的想法,所以我想在这里说说我的看法。对于抢票软件,很多人都觉得对那些去排队买票的人不公平,但我觉得这根本不存在公平与不公平的说法,对于卧铺票来说,网上是无法选择上下铺的,只有去排队才能选择。并且这个软件并不是收费软件,所有人都可以免费下载,人们可以自己去选择网上购票还是排队购票。网上购票的加速包也有很多争议,有人认为这增加了购票的成本,但根据我自己的购票经历来看,那个加速包完全可以通过让好友帮助来获得,完全不需要花钱,对于这总非强制性的行为我并不觉得是不公平的。而且我觉得总不会有人说“找好友帮助太麻烦了,这是不公平的”这样的话。

所以我认为这个软件并没有违反软件工程师的职业道德。

原文地址:https://www.cnblogs.com/wsshr/p/8684641.html

时间: 2024-11-01 12:24:29

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

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

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

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

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

构建之法第四章学习心得

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

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

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

《构建之法》第1.2.3章读后感以及《硅谷传奇》观后感

阅读教材<构建之法>第1.2.3章之后,满满的对话,生动形象.其中第一章写到软件=程序+软件工程,程序=数据结构+算法,这也反馈出我们要学好数据结构以及算法.软件工程这方面的内容.我们要做出"足够好”的软件,并且不要忽视软件的每一个小部分,因为软件的每一部分都有可能成为关键的致命部分,犹如飞机或小车的安全带.我们做出的软件要符合客户的要求,软件分析需求分析至关重要,要花费很长的时间和精力.而且,软件维护是一个漫长的历程.在个人软件开发过程中,单元测试.回归测试以及效能分析虽然花费大量

《构建之法》第六第七章读后感

<构建之法>第六第七章读后感 阅读<构建之法>第6~7章,并参考以下链接,发布读后感.提出问题.并简要说明你对Scrum的理解. 学习附录: Scrum中文网--什么是Scrum?  http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1 Scrum认证体系 http://www.scrumcn.com/agile/scrumtraining/scrum-certification-progr

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

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

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

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

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

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

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

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