团队开发的经验之谈（原创）

接触过许多开发公司，发现在一些小公司还在处于“本能”的开发阶段，完全没有相应的团队开发章程,在交流的过程中，感觉他们并非不想有所改变，只是不知道如何实施一些措施来带队完成有序的团队开发任务，就有点想写一些普及的团队开发的经验，都不是什么特殊的东西，但也可以作为一些实惠的参考。

作为一个团队的领导人，首先需要意识的一点是团队开发是和个人开发不同的，大家关注的重点不同，对团队开发来说，代码的易读性和交流性是最重要的，他们往往能决定一个项目的成败，为什么这么说呢？容易读懂的项目，能更快更好的让新人获得项目的关键信息，能让代码自我描述自己的功能特性，能让以后的维护即使换人也轻而易举，代码的性能和简洁等加成，是重要但不是必要的东西。如果在二者二选一的话，可维护，通俗易懂，便于交流的代码在团队中要放在首位。

那么确定了这个基调，剩下的我们就开始看看团队开发该如何进行吧

加入你是一个小团队的领导者，现在正面对一个混乱的团队管理，客户需求无法顺利完成，代码结构一团糟，来了新人却无法快速上手，做个东西影响了其他人的程序，bug链让你陷入了危机之中。那么下面的经验或许对你有用

1.最重要的第一条，确定编码规范，确定编码规范，确定编码规范，重要的事情要说三遍。

    尽管是最重要的一条，但还是许多人无视，看了许多的松散管理的团队，竟然没有相应的代码规范，我就了个去了，那还能好好的玩耍不。第一条请把几个骨干召集到一起，到网上down个google的代码规范，以此为蓝本，修改吧。虽然google的代码规范很好了，但对于团队开发来说，并不见得是最适用的，使用别人的开发规范可以降低培训的成本，但是很多人都没有正式的好好看过，所以培训还要来一波。而且，有些规范并不见得完全合适，那就需要几个经验老到的精英码农，共同拟定对大家都认可的编码规范，形成文字，统一遵守。

那么这个规范该怎么玩呢，在许多文档里都有很多描述了，比如在java里，大写的通常为类，小写的为对象。但这样的规范并不见得完全对你的团队适用。如果从别的语言上过度过来的团队成员，有的时候，并不是那么直观。

   代码命名是个技术活，抛弃老旧的匈牙利命名法吧，那个确实在面向对象的命名中难以维继，目前一般都喜欢用驼峰命名的方式来标记变量，这种方法非常nice，因为你能很好的断句，很快的搞懂变量的意图。然后不要怕变量名字太长，有IDE的支持，你定义一句话也花不了多少工夫，但一般来说，以1-4个单词为宜，过长的变量，读起来有点障碍。   不要以拼音给变量命名。见过有以拼音第一个字符的简拼和整字全拼作为变量命名的，结果看他的代码就像猜谜游戏，搞得恶心半天，特别是过段时间再看，还要再猜一遍，我想死的心都有了。不要用过于生僻的单词和含义丰富的单词，变量的命名一定要简单，简单再简单。让人一眼就看出这变量是干嘛的。衡量一个变量或函数命名的好坏不是它的长短，而是是否反映了你的意图，这个非常重要。

   为了统一命名，我们过去是这样做的。

   如果自己定义的类，类的名称前三个字为Cls起头，如果实例化类了，Cls就变为obj，其他部分一样，如果是GUI编程，每个GUI元素，都以其三字简称来命名，例如CommandButton，命名为CmdSendFile等，普通变量名前三个字母以类型起头例如IntGetBookCount，这样命名在很多书里并不推荐，但我觉得很好，为什么呢，因为我可以很轻易的在任何一个代码段内，不用上溯就能知道变量的类型和用处，而且还有个很好的副作用，当你想通过IDE找到自己定义的类时，输入Cls很快能从成堆的类里把自己需要的类定位出来，最好的是，无需要我给任何人培训了，新来的只要拿到我的代码，很快就能知道这代码是什么意思，有什么意图，因为命名已经清楚的表达在那里了，这就是我所说的一切以代码的易读为第一位的表现之一。

   写代码，很多时候是和写文章是一样的，语文老师告诉给我们，要写个能让人明白的文章，需要注意三要素，时间，地点，人物。这个也适用于变量的命名。对变量来说它的作用也有三个，作用域，类型和使用意图。说明了这三点，在任何一个代码片段里，我们都可以很轻易的搞懂这个变量的使用方法。所以对局部变量，我们一般不加前缀，对类里的私有变量，加个前缀，可以是_,也可以是m，反正说明它的作用域是类级别的就可以了，对函数的参数变量，首字前缀加个P，表示是参数，对全局变量加G，对常量加C，然后就是类型，例如CIntPlayMaxCount，就是一个整型的用来存储最大播放次数的常量，一目了然。

   在代码中对任何变量或函数的的命名都要遵循一定的结构，函数可以不用跟类型，因为他们返回时赋值的变量，已经说明了它们的属性。但有结构的命名可以让命名不至于失去控制，限制了某些新人的过度发挥，把大家统一到一个理解框架里来，更便于沟通。

2.控制代码显示长度

   控制代码长度有两个意思，一个代码长度别超出屏幕的显示区，如果超出，用续行功能到下一行。见过有一行代码超出好几屏的，你这么折磨我你的良心不会隐隐作痛吗？另一个意思，函数的内容长度不要超过一屛显示，最大不能超过三屏，因为翻页是个很痛苦的事情，如果能在一屛内把所有意图都能讲明白，搞个超长的case，if，for语句，你觉得多番几屛能让你记住前面的是啥玩意嘛？所以力争把任何函数控制在一屛显示内，大概40-50行，如果超出，定义个新的函数吧，把过长的代码段放到新函数里。

3.少写注释，但不能不写

   应该没有程序员想写注释吧，对程序员来说，代码就是文档，很多注释的表现力远不如代码直观，但前提是，你的代码要足够清晰，所以命名一定要准确，清楚的表明意图。这样的代码，命名已经有足够的信息来代替注释了。当然函数或模块的头注释还是要写，让人不用看代码就知道是干嘛的，另外不是还有个javadoc之类的东东能干很多事。函数内的注释，功能性的注释都用命名来代替吧，如果你觉得有些地方需要注释来说清楚，说明你的命名不够清楚

4.不要串用变量

   总见到新人前面定义一个变量，后面为了省事把这个变量反复用，这是非常不好的习惯，任何变量定义都最好只有一个用途，这样不会造成阅读上的困扰。你不用花心思去猜这个变量前面和后面的作用有什么区别，复用变量还容易造成赋值遗传的毛病，所以，为一个作用，就定义一个变量，不要复用任何变量。

5.不要炫复杂的程序结构

    有些很强的编程“大师“，非常喜欢为了炫耀能力，表现与众不同而写一些结构精巧让人费解的代码，这种代码在团队开发里是最大的毒瘤，性能再好的代码也比不上可读性差，如果真的性能要牺牲可读性，不如换点更好的方式，例如用更低级的语言做第三方的API，把需要性能的部分和程序的主构架隔离出来，维持代码的表现力。

6.找个合适的版本控制

   虽然很多都用了，但还有好些公司居然不用，费解。个人也好，团队也好，版本控制是标配。

7.假如你用了设计模式，一定在命名中标记出来

   设计模式是程序员之间的沟通语言之一，标记出来有助于快速理解程序的结构

 

   

 

    

 

转载于:https://www.cnblogs.com/sincostag/p/8703127.html