团队合作的一些考虑

团队协作基本守则

需要解决的问题：

1. 共同协作完成同一个工程的代码；
2. 讨论项目整体
3. 每个人的进度更新/汇报；
4. 解决个人无法解决的问题；
5. 发现其它人负责代码段的bug；

在GitHub上协作，很容易解决上述几个问题：

1. 通过Git，公共仓库可被同时编辑；用pull-request可以方便地整理不同人的代码输出。关于开发模式，下文详述。
2. 严谨的讨论通过issue/wiki/mailing list，即时性的讨论则用微信等即时工具
3. 跟踪进度采用“每日三句话”方法。原则上可用wiki/issue进行，为便于查找使用wiki。同时建议在微信更新
4. 出现问题时，立刻同时建立issue。至少不晚于每日三句话时。做到问题不晚于第二天通知相关人员。
5. 发现互相依赖的代码段的问题时，建立issue，assign相关人解决。

团队开发模式

与任性的个人开发相比，工程团队同时对一个项目的不同内容开发时，会出现相互依赖的问题。如何解决？
从时间, 空间分解工程

• 从黑箱模型出发，把软件分解成 input-process-output 过程。
  • 运用常识（开发模式），把任务分解为几个部分。
  • 完美分解是标准正交基-MECE-高内聚低耦合（同一个内涵整出这么多概念哈哈）
  • 实际工程中重点是好用，又快又好搞定任务才是关键，不可太执着于分解而本末倒置。
• 分解后，通过明确模块间的界面(interface)(即前一个模块的输出/后一个模块的输入)，准确界定每个模块的功能（即分解后的 i-p-o 流程）
  • 个人编程时，由于很少出现同时操作几个模块的情况（通常是一个一个做），不用那么严谨（但从工程角度说，明确的产品结构图是有好处的；只是一些过度的中间层可以避免）
  • 一个常用的思路似乎是（我目前只想到这个办法）加入一个中间层，把上一层的输出封装起来，开放给下一层作为输入
  • 唔，这就是 Object-oriented programming的本源了吗？
  • 再看我设想的iDoulist项目，采用了input-std. input-process-std. output-output，加入std i/o中间层，从而精确定义了每个模块的i/o（当然，可以建立一个/两个类来作为中间层，这样也许更OOP一点？但就我个人而言，并不是很在乎是否是OOP，也许和我的C语言习惯有关）
• 每个人按照自己模块的功能进行工程实现

在 GitHub 协作

GitHub提供了大量适合多人异步协作的工具，小队在我的安利之下应逐渐熟悉相关工具：

1. Git

   • 使用 branch 功能进行日常代码写作
   • 相关命令如 git branch... git basics
   • 常建立 dev/bug 等分支
   • 一般情况下要用 pull-request 更新 master，不可直接 pull 到 master
   • ref: liaoxuefeng's git tutorial

2. Issue

   • 基本功能是提出一个需要讨论的话题；可能是bug/功能升级/要讨论的内容等等
   • issue的open/close状态对应是否解决
   • 结合assign功能可以分配给相关人执行
   • 可以在issue下随时进行讨论（任何人都可参与，不仅是项目成员）
   • issue可添加标签，并用milestone功能整合管理
   • 详细内容：Mastering issues

3. Wiki

   • 一些通用介绍性文档（与项目代码不直接相关）适合放在wiki中
   • 如：项目如何使用的详细介绍，对不同系统的适应，等等