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

第四章 两人合作  

这一章是讲述了两人结对编程的一些东西,包括一些代码的规范,还有结对编程的优点、怎么做、以及一些注意事项。

1、“错误处理 当程序的主要功能实现后,一些程序员会乐观地估计只需要另外20%的时间,给代码加一些错误处理就大功告成了,但是这20%的工作往往需要全部项目80%的时间。”

疑问:“错误处理”是什么概念?它有哪些类型及方法?

思考:我查阅了一下资料,上面解释道“在程序设计过程中,由于某些错误的存在,致使程序无法正常运行,处理这些错误以使程序正确运行就称为错误处理。”根据错误类型有如下分类:

2、“要注意,每个人每天的高效工作时段不超过3-4个小时。结对编程中驾驶员与领航员的角色要经常互换,避免长时间紧张工作而导致观察力和判断力下降。一对程序员完成预定任务之后,就可以休息  ”

疑问:读到这里有一些疑惑,现实生活中每天只工作三四个小时能够完成任务吗,还有结对编程究竟是什么形式?是两人一台电脑,一个人先开始编程,另一个人在旁指正,然后一定时间换人?

思考:我看到后面一点才了解到原来结对编程不是两个人一起分配了任务,各做各的然后汇总在一起,而是在一起,一个编写一个审查,开始觉得这样并不会提高效率,可能还会因为一起聊天影响对方,但看完之后才了解到这样可以省去复审的阶段,让一个人或一个团队最后复审一遍找到错误再加以改正还不如结对,在编程过程中不断地复审,这样出现的错误更少,效率更高。

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

看完这一章我感觉收获了很多,感觉很多东西清晰了,了解了一些领导的内心想法,一个程序员应该到达什么目标。还有做程序员真的需要自我调节能力,要给自己动力,并且无论干什么,在一个团队里都需要理解与尊重,多多换位思考,减少不必要的争执。这一章还有一些我没有见过的名词,比如:MBTI、SMART等,查阅了后觉得非常科学。最后还有一些疑惑:

1、“其实领导和经理还是有区别的”“请你看看你身边的那些‘管人的领导’,他们擅长的是把人当做东西来管理,还是领导大家达成团队的目标?”

疑问:看到这段话我着实有一点震撼,一直没有想过原来领导和经理是不一样的,也没有想过领导有两种不同的解释,那么有什么区别?哪个解释更符合领导应有的态度?

思考:看完这部分后我觉得领导大家达成团队的目标更符合。人是一种复杂的生物,他不同于东西,东西是没有生命的,没有想法的,是“死”的,而人有自己的思想,自己的思维方式,每个人的轨迹都是不同的,这些不同的人生造就了一个个独一无二的生命,价值观,世界观,当你把这种复杂的物种当成是东西来管理是达不到你想要的结果的。现在的社会讲究个性化,要用不同的方式对待不同的个体,领导需要抓住每个人的优缺点,给予不同的责任,让大家有共同的信念来完成目标。

原文地址:https://www.cnblogs.com/benmatt/p/8683256.html

时间: 2024-08-27 22:20:38

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

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

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

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

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

构建之法小结四

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