看多人合作编辑代码

本星期,继上次的单人代码编辑,进而了解多人编辑同一个项目的代码过程。

其中,最为优先的是个人编辑代码的风格。因为是多人合作,个人编辑的代码要不仅自己可以看清楚,同时也要让合作者也能理解你编辑的代码含义。其原则是:简明,易读,无二义性。。其中包含着对缩进,行宽的限制,括号,断行,分行,命名,下划线,大小写,注释等的使用。

个人编辑好后,首先要通过代码复审。这又包括自我复审,同伴复审,团队复审等。其目的所在则是:查找代码错误,逻辑错误,算法错误以及潜在错误,发现可改进的地方,再加上相互间交流教育。主要复审方面则是在:代码概要部分,设计规范部分,代码规范部分,具体代码,效能,可读性和可测试性。而且双人编辑代码时更是使用结对编辑,这正如开车时拥有驾驶员和副驾驶员一致的道理以及两者间不断加深的磨合,关系的更近。

而最后则是团队编辑项目,在先前的双人基础上,多人的编辑则是大同小异。团队编辑则是更为注重软件团队的模式,例如主治医师模式,明星模式,社区模式等等模式以及开发模式,例如写了再改模式,瀑布模式,统一模式等等。

最后目前的阅读暂时止于表面,稍加了解,之后的章节才是重点啊······

时间: 2024-08-04 14:16:19

看多人合作编辑代码的相关文章

两人合作之代码规范

代码规范 现代软件经过几十年的发展,一个软件由一个人单枪匹马完成,已经很少见了,软件都是在相互合作中完成的.合作的最小单位是两个人,两个工程师在一起,做的最多的事情就是"看代码",每个人都能看"比人的代码",并且发表意见.但是每个人对于什么是"好"的代码规范未必认同,这时我们有必要给出一个基准线-----什么是好的代码规范和设计规范. 1,写干净整洁的代码 1.1 代码格式化,包括多级代码缩进.大括号(比如C系代码),为了提高代码的美观型和易读性

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

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

构建之法---什么是代码规范?如何与人合作编码?

什么是代码规范?如何与人合作编码? 两个工程师在一起,做得最多的事就是相互看对方的代码,因此我们知道代码最终还是要给人来看,而不是机器,因此要注意代码的规范,即代码风格的规范和代码设计的规范:1.代码风格的原则就是简明易读无二义性,还应注意缩进.行宽.括号,最好是括号单独占一行.2.下划线用来分割变量名字中的作用域标注和变量的语义,所有类型和类都应该采用pascal命名法-单词首字母大写,而变量采用camel命名法-第一个单词全小写,其余单词首字母大写 3.注释是为了解释程序做什么,为什么这样做

多人合作使用git,推送代码、和并分支

多人合作使用git,推送代码.和并分支 原文地址:https://www.cnblogs.com/zxlb/p/12318271.html

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

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

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

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

《构建之法》第四章 二人合作 读后感

两人合作 一直说编程是团队工作,终于到了结对阶段.合作的最小单位是两个人“,在合作团队里面,两个人做起事情来还是要比一个人轻松的,无论是编程上还是气氛上.同时,在结对编程的过程中,独立思考的同时要多进行沟通,有问题提出来,共同解决遇到的难题,互相信任互相鼓励互相学习.两个工程师相互看代码并给出自己的意见,所以代码的规范性是极其重要的,我们的代码不仅要让机器读懂也要人也能读懂,代码风格要规范,命名,缩进等更不用说,因为到了后面,代码中出现的类和对象就会变多,很容易造成混乱,要学会封装,将功能模块具

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

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

git多人合作模式的应用

接触git只有不到一年的时间,可以说比大多数人起步都晚.那会还沉浸在自己的舒适圈里面,进公司就用着perforce,一用就快7年,觉得自己会用一个SCM就行了,捧着不放,也不想去接触别的SCM. 直到去年公司一个新的项目开启,时程很赶,然后我也被拉进项目组.编程语言用的是PHP,framework是Laravel,SCM是git.刚听到的时候,我--一.NET程序员,现在让我来搞php,还是从来没接触过的,心想没搞错吧,可是是大老板安排的,抵触也没用,然后就被逼接触到了php,接触到了git.