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

在编写程序过程中,程序代码不仅仅是给机器看,同时也会给与之合作的完成软件的同伴看,但是如果程序代码不符合代码规范,就很难让除自己之外的人看懂。

两人合作时的不同阶段和技巧:

1.萌芽阶段

两人刚开始合作,交流不少,试图避免冲突和容易引起挑战的观点,两人有不同的期望值,但是双方彼此并不了解。

2.磨合阶段

合开合作,但是会有不同程度的摩擦。

3.规范阶段

双方代码逐渐相似,一些不成文的规则逐步建立起来了。

基本操作:

在分析好需求,确定了最终设计文档后,需要设计具体的代码。

在设计代码前,需要确定代码设计规范。两人合作必须统一代码格式,否则就会给读懂彼此的代码带来困扰。缩进、行宽、括号、断行、分行、命名等都有统一的规范。

确定好规范后,就可以编写源代码。在代码的编写中,要注意几个方面:

函数:函数只专注于把一个功能做好,最好有单一的出口。

错误处理:错误处理中,所有的参数都要验证其正确性,验证正确性可以用断言的方式。

类:使用类来封装面对对象的概念和多态;避免传递类型类型实体,应该使用指针传递;有显示的构造和析构函数的类不要建 立全体的实体;仅在必要时使用类。

在源代码编写完成并且成功的编译完成后,我们需要单元测试和效能分析。我们可以使用vsts来进行测试。单元测试有很多要求,如单元测试应该在最基本的功能上验证程序的正确性,必须由熟悉代码的人来写,单元测试后机器状态要保持不变,单元测试要快等等。效能分析有两种方法,抽样和代码注入,一般采用先抽样找瓶颈后对特点的模块代码注入进行详细分析的方法。

这之后就是代码的复审了。两人合作中,可以先自我复审,再互相复审或一人开发一人复审,看代码是否在代码规范框架里解决了问题。而在团队复审中则是由整个团队复审开发者。复审主要是看概要部分、设计规范部分、代码规范部分、具体代码部分、效能、可读性和可测试性是否符合规范、正确、可行。复审者必须逐一提供反馈意见,开发者必须让所有的问题都得到满意的解释或者解答,对于复审结果双方必须保持一致。

时间: 2024-10-27 10:51:24

两人合作源代码管理的基本操作的相关文章

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

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

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

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

源代码管理的基本操作

近期,我和我们团队的Echo同学进行了两人结队源代码操作练习.我们通过运用Java语言进行练习,两人分别对同一主题编写代码,再进行代码复审,最后做出总结. 首先,我们编写了一段代码.经过同伴互相复审后,我们发现我们的代码风格规范不太一样.可能由于习惯的不同,各自命名变量的方式就不同.在没有写注释的情况下,看别人的代码实在是看不下去.我认为写代码还是一个人做比较好,多人合作不合适! 在学习了<构建之法>第4章——“两人合作”后,我才知道不管多么厉害的开发者都会或多或少地犯一些错误,有欠考虑的地方

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

本周学习的是<构建之法>的第四章,这章的主题是两人合作,看到这个题目我的第一反应是现在两人合作的项目还很多吗?因为我一直认为一个项目一般是几个人或是十几个人这样的团队来合作完成的,这个思想也不知道是看到了什么有的.值得一提的是,书中的第五章就是讲团队合作的. 合作的最小单位是两个人,合作过程中必然存在着个人看法,比如一个人看另一个人的代码时就不一定同意其看法了,每个人心中对于好代码的定义也不尽相同,这时候就很有必要给出一个基准线--什么是好的代码规范和设计规范. 看到课本上代码清单4-1,的确

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

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

构建之法 第四章 两人合作

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

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

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

第4章两人合作

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

两人合作

现代软件产业经过几十年的发展,一个软件有一个人单枪匹马完成,以及很少见了,软件都是在相互合作中完成的.合作的最小单位是两个人,两个工程师在一起,要相互看懂对方的代码并不是一件容易的事,因为每个人对"好"的代码的理解是不一样的,所以一个基准线--什么是好的代码规范和设计规范就很必要了."代码规范"可以分成两个部分:1.代码风格规范.2.代码设计规范. 代码风格规范的原则是:简明,易读,无二义性.例如对一个书写格式方面的规定:缩进最好为4个空格:对行宽的限制:括号:断行