软件开发中的团队协作

软件开发中的团队协作

软件开发多是多人协作开发，因此软件开发中的团队协作至关重要。

相互尊重

不管一个人是管理者还是基层工作者，一定要做到彼此相互尊重。大家都是合作者，只是分工不同，没有必要有鸡鸭鹅溜须拍马，阿谀奉承那一套浪费时间。人如果没有得到公正的对待，彼此是不可能站在同一战线，朝同一个目标共同努力。

版本控制

版本控制是一个伟大的实现，让文件实现可追溯，多人协同更改。有效避免了文件的异常损坏、丢失等。

可以根据不同的队友进行code review，对其编程水平有一个大概的评估。

进行bug定位，对比出现bug的版本变更，可以缩小bug代码的定位范围。

GitHub之类的托管平台，让版本控制变得更加容易、普遍。不再需要搭建版本控制服务器，只需注册就能使用，太划算了。一个人可以从开始学习编程，就把自己写的代码进行版本控制，以备需要的时候复用。

编码规范

编码规范可以让团队中的成员形成统一的编码风格。统一的编码风格，有利于软件的开发、维护、工作内容切换，还能有效减少bug出现的概率。

限制代码的大小

避免写出耦合度较大的类，意大利面条式的长方法。在团队中推广设计模式，减少耦合，细化代码。相似的场景，使用统一的解决方案。

if语句一定带{}

if(condition)
{
    return result
}

优于

if(condition)
    return result

有时代码变更会在没有{}的执行语句前/后增加部分执行语句，却没有增加{}，导致部分应该在条件为真的执行语句，却不受条件语句的限定。

尽可能用TryParse

var success = int.TryParse("1", out number);
if (success)
{
    //使用number
}

优于

var number = int.Parse("1");

TryParse失败的时候，可以采用给予默认值继续执行。同时可以通过日志记录或者bug收集工具发送给开发者，及时的解决软件的潜在bug，提高软件的健壮性；Parse失败的时候，就会直接抛异常“System.FormatException: '输入字符串的格式不正确。'”，如果调用者没有适当处理，软件就挂掉了。

有TryFoo方法的接口尽可能用，避免一些不必要的异常。其他的比如：

var success = dictionary.TryGetValue(key, out value);
if (success)
{
    //使用value
}

优于

var value = dictionary[key];

var result = list.FirstOrDefault();
if (result == null)
{
    return;
}

//使用result

优于

var result = list.First();

禁止沉默“吃”掉异常

如果不对异常处理，要保障异常上抛。像下面这样沉默“吃”掉异常，其中异常引起软件业务逻辑异常不容易定位解决。尤其是在生产环境中，更难定位bug。

try
{

}
catch (Exception)
{
    // ignored
}
finally
{

}

Warning当成Error

在没有把Warning当成Error的代码中，多数存在大量的Warning。Warning要及时的处理掉，避免一些不必要的bug或者性能损耗。整洁的代码有利于成员遵从软件童子军规（让代码比你更改前更干净），避免破窗效应。

  1. 可能为空值的变量
  2. 未使用的变量
  3. 未使用的方法
  4. 未使用的类
  5. 变量命名不规范
  6. 方法命名不规范
  7. 多余的命名空间
  8. 变量同时存在同步和非同步代码块中（不全被lock包裹）
  9. 多余的类型声明
  10. 可能存在多次枚举
  11. 一些废弃的旧语法
  12. 不必要的范型变量
  13. 不必要的变量初始化
  14. 不必要的继承
  15. 冗余的case
  16. 不必要的类型转译
  17. 不必要的ToString()

持续交付

持续交付是保证软件能够通过编译，通过单元测试，保持正常运行。

每日构建(Daily build)保证每天都能生成可用的软件包。时时构建是只要周期性检测到代码库有变更就进行构建。当构建失败时，及时通知版本管理者和代码提交者，解决构建失败的问题，保证其他开发者更新代码之后，能正常的编译运行，持续开发。

构建失败最常见的情况是漏传文件，其次是文件冲突。有效的解决方式是提交代码之前，先更新代码，有冲突时，先在本地解决后再提交，可以避免文件冲突。提交代码后，下载一份副本（常保留一份代码更新后测试，减少下载代码的浪费）测试本地能否正常构建，保证自己上传后软件能正常构建，如发现漏传文件，及时补传文件。

拒绝推诿

软件开发中的任务，很多时候是有交叉的，可做可不做的时候，尽量主动承担。耍一些小聪明把任务推给队友，自己跑去喝下午茶，悠哉悠哉。次数多了，队友也这么干的话，最终就是相互推诿。

打赏