如何优雅地进行团队协作开发

前言

最近浏览到了 天猪、偏右 两位师兄的文章，讲的是Github中提交issue的过程中发现的问题以及相关思考，字字珠玑。让笔者回忆起了自己当时实习的经历，跟着带自己的师兄学习了很多，其中就包括如何高效地进行团队沟通。我将这两篇博客中的知识点进行提取，同时引用了部分例子，写下此文，分享一下如何优雅地进行团队协作。

干货时刻

本文主要讲解如何高效地进行团队协作，降低团队间的沟通成本

把问题说清楚

在跑别人的代码或者使用开源的三方库报错时，如果自己无法解决这个bug，就需要向项目维护者沟通自己出现的问题，让他修复。

1. 指明遇到了什么bug

   您好，在我的项目中引入了 xx.css，编译时报错了，错误信息如下：
   Module build failed: SyntaxError: Unexpected token
   

2. 定位bug的范围

   我是这么引用的：
   import 'xxx.css';
   balalalala .....
   

及时反馈

负责维护项目的同学如果看到了私信，但是你并没有提供充足的bug信息，那么他可能会进一步让你提供一个最小复现单元，所以你要及时关注消息，不要让维护的同学等太久。

我的项目里出现了一个弹层bug
发现是 xx 组件和 yy 组件同时使用时出现的
这里有个简单的重现例子-附件：component-xxx-yyy-bug.zip (12KB)

格式化 bug 代码

展示bug代码的时候，不要把代码格式弄乱了。两三行代码就能描述清楚的事儿，你整了八九行，比如这样：

class Demo extends React.Component {state = {collapsed: false,};
toggle = () => {this.setState({


      collapsed: !this.state.collapsed,

});
  }render() {return <Menu>...</Menu>;
  }}

自己看都费劲，更不要说维护的同学了。所以，不如花两分钟打开你的IDE，把代码格式化一下再粘出来

class Demo extends React.Component {
  state = {
    collapsed: false,
  };
  toggle = () => {
    this.setState({
      collapsed: !this.state.collapsed,
    });
  }
  render() {
    return <Menu>...</Menu>;
  }
}

控制好版本变量

控制变量的思想大家应该都知道，就是控制其它条件都相同，让某一要素发生变化进而对比结果。那么在团队协作中，如果你向项目维护的同学提了bug，他经过排查发现这个bug已经被修复了，于是你回过神儿发现你用的不是最新版本的代码，犯了一个低级错误。这就是信息不对称导致的无效沟通，那么为了避免出现这样的情况，我们在提出bug的时候，要指明自己的版本信息：

您好，我的代码在 chrome 35 出错了，我用的代码版本是 v 1.0.5。
维护者：好的，我也重现了，我看看怎么修复。

向另一团队的项目提交issue的正确姿势

毕竟是帖子沟通，所以还是要走八股文之issue四段论：

1. 你做了什么？
2. 你期待什么？
3. 实际的情况是？
4. 最小复现单元

下面以浮层bug为例：

xxx 组件浮层没有关闭
- 使用版本：1.0.0
- 浏览器：Chrome 56.0987
- 操作系统：Windows 10

## 你做了什么？
我引入了组件 xxx，代码如下，我点击组件后打开浮层，做了如下操作。

## 你期待什么？
浮层应该关闭。

## 实际的情况是？
浮层短暂关闭后又再次弹出。
（附带上一个小视频或是[GIF截图]）

## 可重现的在线演示
https://demo.com/demo.html

避免出现X-Y问题

X-Y问题是什么？

• 有人想解决问题X，但他觉得Y可能是解决X的办法。
• 但是他不知道Y方案应该怎么做，于是他去问团队成员Y应该怎么搞。
• 在经过大量的讨论后，团队成员发现要解决的是X问题，但是Y压根不是解决X的合适方法，导致在一个错误的方向上耗费成本。

所以，在解决X时，首先搞清楚解决问题的方向，不懂就问，之后再问怎么解决。

反馈需求的优雅姿势

Egg团队在协作中通过RFC形式来讨论和实现一个新特性，该模式叫：基于Github的硬盘式异步协作模式，基本流程如下：

1. 通过issue发起RFC提案
2. 讨论定稿
3. 提交Pull Request
4. Code Review
5. Publish

其中issue模板如下：

## 背景
- 描述你希望解决的问题的现状
- 附上相关的 issue 地址

## 思路
描述大概的解决思路，可以包含 API 设计和伪代码等

## 跟进
后续编辑，附上对应的 Pull Request 地址，可以用 `- [ ] some task` 的方式。

同时规定：标题：[RFC] your request title，标签：type: proposals

综上所述，该工作模式的优点在于方便技术沉淀，即使是当时没有参与讨论的开发者，事后也能通过issue了解某个功能设计的前因后果。