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

程序员写的代码最终是人在看,所以代码规范很重要,原则是:简明,易读,无二义性。

不光是程序书写的格式问题,还牵涉到程序设计、模块之间的关系、设计模式等方方面面。

代码复审的正确定义看代码是否在代码规范的框架内正确的解决了问题

代码复审的目的在于:

1.找出代码的错误,比如:

1)编码错误,比如一些碰巧骗过了编译器的错误

2) 不符合团队代码规范的地方

2. 发现逻辑错误,程序可以编译通过,但是代码的逻辑是错的

3. 发现算法错误,比如使用的算法不够优化,边界条件没有处理好等

4. 发现潜在的错误和回归性错误—当前的修改导致以前修复的缺陷又重新出现

5. 发现可能需要改进的地方

6. 教育(互相教育)开发人员,传授经验,让更多的成员熟悉项目各部分的代码,同时熟悉和应用领域相关的实际知识

结对编程让两个人所写的代码不断地处于“复审”的过程,程序员们能够不断地审核,提高设计和编码质量,可以及时发现并解决问题,避免把问题拖到后面的阶段去。

开发中的复审主要包括:设计复审、代码复审、测试计划复审和文档复审。

这些复审可以在伙伴之间进行,也可以在团队内部进行。

两个人合作的不同阶段

1. 萌芽阶段(Forming) 两人刚刚互相认识,这时大家都有礼貌,一般交流不少,双方彼此并不了解。

2. 磨合阶段(Storming)

3. 规范阶段(Norming)

4. 创造阶段(Performing)

5. 解体阶段(Deforming)

如何正确的给予反馈

1.最外层:行为和后果

行为可以改正,后果可以弥补,还有挽回局面的机会

2.中间层:习惯和动机

被攻击的一方就比较难表白并且澄清动机

3.最内层:本质和固有属性

当攻击深入到核心,被攻击一方已经无法回应

如果软件工程师连一对一的合作都做不好,不能有效地影响同伴,让合作双方都从中受益,提高水平的话,更别提团队合作了,影响了团队合作,从而影响了整个公司的利益。

所以首先要做好两个人的合作

两人的合作—如何影响对方

两人在一起合作,自然会出现不同意见,每个人都有自己的想法,在两个人平等合作的情况下,不存在领导与被领导的关系,如何能说服对方?这个时候不是比谁的嗓门大,首先双方要意识到,问题早点出现要比晚点出现好很多,我们有机会早日解决问题。除了技术方面的考虑之外,一个成熟的工程师要琢磨对方的话语和观察对方的肢体语言,了解它们所表示的潜台词,试着从对方的角度看待问题。

时间: 2024-10-13 15:43:34

读构建之法 第四章:两人合作的相关文章

构建之法 第四章 两人合作

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

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

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

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

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

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

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

《构建之法》第四章“两人合作”读后感

团队合作在一个企业的作用是至关重要的:第一,通过团队合作,可以营造一种工作氛围,使每个队员都有一种归属感,有助于提高团队成员的积极性和效率:第二,通过团队合作,有利于激发团队成员的学习动力,有助于提高团队的整体能力:第三,团队合作可以实现“人多好办事”,团队合作可以完成个人无法独立完成的大项目:第四,团队合作有利于产生新颖的创意:第五,通过团队合作可以约束规范和控制成员的行为:第六,团队合作更有利于提高决策效率.所以说一个好的团队的总体力量,超过每一个个体力量的总和. 在软件开发的过程中,团队开

构建之法第四章学习心得

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

构建之法 第四章 读后感

在第四章中说“合作的最小单位是两个人“,两个工程师相互看代码并给出自己的意见,所以代码的规范性是极其重要的,我们的代码不仅要让机器读懂也要人也能读懂,在第四章的学习中,我也尝试着和别人结对来编写一个程序,效果相当的不错,规范的代码让我们都能够方便读懂对方的程序,同时也能提高彼此的能力,取长补短,形成互补. 4.1大节提到的代码规范,我们编写代码时要注重代码风格规范和代码设计规范,无论是类名,对象名,缩进还是行宽什么的,在结对子编程时都要有所规定,不然到后面出现的类或是对象多了,就很容易混乱,分不

0405构建之法第四章--读后感

<构建之法>这本书的第4章讲的是关于两人合作的内容,对于书里所说的两人的关系就和驾驶员.领航员类似,通过结对合作,令我意识到了编写程序不仅仅要自己能明白,也要便与他人查看和理解自己的程序. 代码规范性,我们编写代码时要注重代码风格规范和代码设计规范,无论是类名,对象名,缩进还是行宽什么的,在结对子编程时都要有所规定,不然到后面出现的类或是对象多了,就很容易混乱,分不清楚谁是谁.要学会封装,编写函数,将功能模块具体化,减少主方法里面的代码,避免大规模的出错. 代码的复审,在平时编程程序时,我也会

构建之法&lt;第四章&gt;之感悟

第四章:两人合作内容出处:4.6 两人合作的不同阶段和技巧 本章主要是讲关于合作方面的,文章以刚刚认识的两个人为例!也就是说,他们之前的关系是陌生人,然而在现实当中两人合作也可以有其它的关系,比如说合作的两人彼此是情侣关 系,那应该怎样合作呢?如果男的与女的合作前,男的对女的千依百顺,再合作时,当女的意见是错误的并且女的非常强势,而男的意见是正确的,这种情况之下应该怎么办呢?又 如,如果合作的两位伙伴,在合作之前是师生关系,这样又怎么办呢 另外我也和别人合作过,不过我们到了磨合阶段后就永远停留在