《构建之法》--两人合作

本周学习的是《构建之法》的第四章,这章的主题是两人合作,看到这个题目我的第一反应是现在两人合作的项目还很多吗?因为我一直认为一个项目一般是几个人或是十几个人这样的团队来合作完成的,这个思想也不知道是看到了什么有的。值得一提的是,书中的第五章就是讲团队合作的。

合作的最小单位是两个人,合作过程中必然存在着个人看法,比如一个人看另一个人的代码时就不一定同意其看法了,每个人心中对于好代码的定义也不尽相同,这时候就很有必要给出一个基准线--什么是好的代码规范和设计规范。

看到课本上代码清单4-1,的确第一反应就是不想看!代码的表面其实和人的外表一样的,当然,这里并不是指人的外貌的好看与否,而是干净明落与否。看到这样杂乱无章的代码就跟看到一个邋遢的人是差不多的,看一眼都觉得碍眼的人又怎么会有继续了解的想法的,同理,看到这样多看一眼都觉得浪费时间的代码也不会有继续看下去的想法,这样,无论你的代码有多好,多符合客户的要求,也会在第一眼的时候就被否定掉一大半了。同样的,这样的例子在我们生活中其实都可以看得到的,比如面试的时候,看简历的时候都是很注重第一印象的,第一印象不好的人首先就会被否定掉一大半。好了,言归正传,继续学习吧。

代码规范分为代码风格规范和代码设计规范。

先说说代码风格规范吧。书中的观点是简明,易读,无二义性。书中从缩进,行宽,括号,断行与空白的{}行,分行,命名,下划线,大小写,注释这几个方面着手介绍代码风格规范。其实不少在我们学习的过程中都是遇到的,就看自己有没有注意这些规范的运用罢了。在断行中作者一开始举的例子是为了层层递进最好的,其实我也就认同最后那种,毕竟那种也是比较直观好看吧。对于命名的说法,其实我也是比较苦恼的,因为自身英文不是很好,所以想用英文来命名还得百度,中文的自然不好,所以就显得比较麻烦了,唉,看来以后还是要好好学英语的,何况现在还有专业英语呢,

接下来说说代码设计规范吧。代码设计规范比代码风格规范的理解层面要高一些的。代码设计规范不仅是程序书写的格式文体,而且牵涉到程序设计,模块之间的关系,设计模式等方方面面。函数是我们写程序基本都会用到的,书中的观点就是:只做一件事,并且要做好。Goto是为了使函数有单一的出口。错误处理我觉得是每个写程序的人都会遇到的,不存在没有出现错误的代码。错误处理看似需要很少的时间来解决,最后其实往往需要全部项目80%的时间。断言是用来验证代码的正确性。然后书中关于类的讨论,大部分在学习C++或是JAVA的时候都有学习过了。我比较生疏或者说接触不多的是new和delete。如果可能,实现自己的new和delete,这样可以方便的加上自己跟踪和管理机制。自己的new和delete可以包装系统提供的new和delete;检查new的返回值,new不一定都成功;释放指针时不用检查NULL。然后对于异常处理,我的运用还是不够的还需要多加学习,当试用异常时,要注意在什么地方清理数据,异常不是万能的。

代码复审。代码复审并不是把自己写好的代码给别人看就行了。代码复审的正确定义:看代码是否在“代码规范”的框架内正确解决了问题。代码复审的形式包括自我复审,同伴复审,团队复审。其中最基本的复审手段,就是同伴复审。代码复审简单点来说就是找出编译器检查不出来的bug,比如逻辑上的,算法上的等等。还有一点就是互相教育开发人员,传授经验。代码复审的最终目的是为了让代码能够更好地实现,更好地满足客户的需求,复审并不是为了针对开发者来找bug的。关于代码复审的核查表内容我并不想多说,在以后编程的时候多注意就好。

结对编程。慢慢看着,我的想法是如果说结对编程后,程序各方面的质量取决于一对程序员中各方面水平较高的那一位,那么,为什么不再多点人呢?这样不是质量会更高吗?很快,接下来,书中就指出了团队复审的缺点,的确,太多人了也不好管理,团队交流必然没有两个人交流方便,而且也有些浪费。书中还讲了不少关于结对编程的一些关键点,在以后的编程中,这是很值得借鉴的,当然,前提是两个人都不过于在意技术水平,工作方式之类的变得透明,我觉得真正有实力的人是不会在意这种事的,因为这样也在一定程度上帮助成长。既然是合作,那么往往就会经历过一个个阶段最终才会掌握到两人合作的精髓。书中把两人合作分为萌芽阶段,磨合阶段,规范阶段,创造阶段,解体阶段。现实中并不一定都会经历这几个阶段,看实际情况吧。还有就是如何正确地给予反馈,这个是很重要的,同时还讲究一定的说话技术。评论人有三种层次。最外层:行为和后果。中间层:习惯和动机。最内层:本质和固有属性。评论要看你针对那个层次反馈。评论别人的代码的时候也是要注意自己侧重那个层次的,这样才能达到最好的效果,被评论人才能更好地找出自己需要改正的地方并解决。

为什么要讲这么多关于两人合作的反馈问题呢?真如书中所说,如果两个人之间的合作都处理不好,又如何谈团队合作呢。下一章就是团队合作的了,下次让我们看看两人合作和团队合作究竟有什么关联吧。

本次的学习就到这里,两人合作的学习内容还有不少是需要学习的,希望自己以后在编程的过程中做项目的过程中能体会到书中所说的两人合作的要点,想想还是比较期待这种两人合作的结对编程方式的体验的。

时间: 2024-10-28 15:44:19

《构建之法》--两人合作的相关文章

三读《构建之法》——源代码的设计、实现、控制与两人合作

现在,<构建之法>的一大半已经读完了,在这一大半本书中,这一部分可以说是对我触动最大的,也应该是整本书对我触动最大的. 整个第二章围绕测试展开,用一个很生动的类比告诉了我们测试的重要性:如果有人说,"一个人写写程序玩玩,单元测试似乎不那么重要.",那么你可以回应他:"你可以大胆对你的女朋友说:'我们只是玩一玩.'看看效果如何". namespace DemoUser{ public class User{ public User(String userE

2018--20179215--《构建之法(第三版)》第四章 两人合作

构建之法 第四章 读书笔记 4.1代码规范 代码规范可以分为两部分: 代码风格规范-主要是文字上的规定 代码设计规范-牵涉到程序设计.模块之间的关系.设计模式等方方面面的通用原则 4.2代码风格规范 代码风格的原则是:简明,易读,无二义性. 缩进:4个空格的距离阅读性最好. 行宽:可限制为100个字符. 分行:不要把多条语句放在一行,每个"{"和"}"单独占一行,不要把多个变量放在同一行. 命名:不要提到类型或其他语法方面的描述:避免过多的描述:避免可要可不要的修饰

构建之法学习(第四章 两人合作)

第四章 两人合作 1.代码规范  1)代码风格规范.主要是文字上的规定,看似表面文章,实际上非常重要. *原则:简明,易读,无二义性 *缩进:4个空格 *行宽:行宽必须限制,可以限定为100字符 *括号:在复杂的条件表达式中,用括号清除地表示逻辑优先级 *断行与空白的{}行:推荐格式如下 if ( condition ) {        DoSomething(); } else {       DoSomethingElse(); } *分行:不要把多条语句放在一行上.并且,不要把多个变量定

构建之法 第四章 两人合作

两人合作是团队合作的基础:这里介绍的这个基础型"团队"中通用的一些方法以及最重要的--交流--的细节 1.代码规范 代码风格规范.主要是文字上的规定: 缩进:4个空格,而不是tab: 关于断行与空白的{}行:[作者的建议深得我心--{ .}单独占一行:中间的代码缩进] 下划线:用来分割变量名字中的作用域标注和变量的语义 大小写:通用的做法是,所有的类/函数名都采用所有单词首字母大写(Pascal)的形式:所有的变量首字母小写,随后的单词首字母大写(Camel): 注释:解释程序做什么.

《构建之法》---团队合作

之前学习了两人合作的要点,现在到团队合作了,到底团队合作和两人合作之间存在着怎样的密切关联,就让我们来看看吧. 一个团队,包含的人数至少是多余两个人的,不然就不会叫做团队了,但是团队也并不是只需要几个人就可以了,人数并不是决定是否是一个团队的重要因素.书中举的有关非团队的例子就很有趣且直观.很明显,并不是需要精通于各种技术的"人才"放在一起就行了,还要把这几个人的目标明确下来,这样才有了团队目标.一个团队的成员并不一定要同时工作.团队成员各有各的分工,互相依赖合作,共同完成任务.软件团

两人合作源代码管理的基本操作

在编写程序过程中,程序代码不仅仅是给机器看,同时也会给与之合作的完成软件的同伴看,但是如果程序代码不符合代码规范,就很难让除自己之外的人看懂. 两人合作时的不同阶段和技巧: 1.萌芽阶段 两人刚开始合作,交流不少,试图避免冲突和容易引起挑战的观点,两人有不同的期望值,但是双方彼此并不了解. 2.磨合阶段 合开合作,但是会有不同程度的摩擦. 3.规范阶段 双方代码逐渐相似,一些不成文的规则逐步建立起来了. 基本操作: 在分析好需求,确定了最终设计文档后,需要设计具体的代码. 在设计代码前,需要确定

读完第四章《两人合作》的内容后的总结

两人合作是团队合作的基础:这里介绍的这个基础型"团队"中通用的一些方法以及最重要的--交流--的细节 1.代码规范 代码风格规范.主要是文字上的规定: 缩进:4个空格,而不是tab: 关于断行与空白的{}行 下划线:用来分割变量名字中的作用域标注和变量的语义 大小写:通用的做法是,所有的类/函数名都采用所有单词首字母大写(Pascal)的形式:所有的变量首字母小写,随后的单词首字母大写(Camel): 注释:解释程序做什么.为什么这样做以及要特别注意的地方.注释只用ASCII码字符,不

第4章两人合作

1.结对项目的案例和论文 因为教材上给的案例是全英文的,而我的英语水平是异常异常的烂,看见英语就头疼,就没有了看见下去的欲望,我在网上找到了邹欣老师的观点,以下是他的观点. 总结1:那是project到了比较关键的创造阶段,整整一天,我们俩椅子靠椅子的坐在电脑前,一边讨论一般coding,那次才真正的体会到结对真的能够带来效率.一整天的coding是容易走神的事,还好有pair在旁边指导,总是不断在我敲某某变量之前提前告诉我成员变量的名字,数据修改时帮忙检查是否有漏掉的,变量和函数定义的时候一起

《构建之法》---软件工程师的成长&amp;两人合作

本周学习了<构建之法>第三.四章的内容. PSP对软件开发的工作质量的衡量简单指标为:项目/任务有多大.花多少时间.质量如何.是否按时交付共4个因素.而要成为一名合格的软件工程师,要对上述4个因素尽量在用户需求上做到尽善尽美. 软件工程师的职业发展有: 职业发展---考级之路 计算机等级考试 (http://sk.neea.edu.cn/jsjdj/index.jsp) 全国计算机技术与软件专业技术资格考试 (http://www.rkb.gov.cn/  ) 职业成长---Steve McC