公司内部代码协作

2012-05-02 10:58

[project]

公司内部，团队间不可避免的有代码互相访问的事情发生。

普通方式

提供者提供头文件和库供调用者实施访问，这是比较常见的方式。当然库有可能是静态库，动态库。

静态库要求双方编译环境，运行环境一致，否则就得提供多种环境的库文件。动态库要求稍微弱一些而已。

很多人会把别人的头文件进行封装，美其名曰为了屏蔽变化，虽说封装开销微乎其微，但是我尤其讨厌这么做。 这种事情甚至会出现在一个团队内的两个人间，一般这两人可能是独立设计。这是缺乏信任、沟通的结果。

如果只提供二进制，看不到代码，又不是经济方面的原因，那么这种公司可以离开了。

如果出现数次使用邮件、聊天软件传文件等方式交流代码，也无力改变，这种公司也可以考虑离开。

远程调用

提供者可以只提供 IDL 文件。 取决于远程调用的使用、部署方式等。工程间的依赖、接口的变更这都是需要解决的问题。

也可以进一步提供封装过服务发现、调用方式、错误处理等后的库。问题就和__普通方式__一致了。

直接使用

要求大家的代码在一颗代码树下，代码间能互相调用，工程间能引用。

假想公司内有个独立的防止 Spam 的小组，业务部门 Blog 需要使用他们的代码。

#ifndef SPAM_CHECK_H__

namespace spam {

bool Check(const char* text);

}

该工程产生 libcheck.a

#include "spam/check.h"

void Post(...) {
  if (spam::Check(text))
    return false;

  // ...
}

调用方的工程文件需要声明

  'dependencies' : ['spam.gyp:check'],

gyp 为工程文件，最终生成 Makefile

Blog 编译时自动加入 -lcheck，一般静态链接发布。能如此做是有很多先决条件的：

  • 公司内一颗代码树，至少都拥有可读权限

  • 每个团队间的代码不能互相影响，需要每个团队都得采用分支开发，保证主线是稳定，可发布版本

  • 信息是开放的，每个团队的代码的变更其他团队应该能知道

  • 公司内部有统一的良好的沟通工具，如 IRC, 邮件列表等

还有其他规范，如

  • 统一的代码风格

  • 目录规则、namespace 规则、冲突解决等。

如果是远程调用，大致可以拆解为：服务发现、调用包装、错误处理等子项，每个子项也可以同理解决。

很多公司把代码的权限管理得相当不错，虽然我也能遵守，但是通常呢？ >

有能力的人不太在乎那些个代码，没有能力的呢？通常可能都玩不转那些个代码
连Google都是内部开放代码，有什么理由制造层层障碍。这种公司也不值得留下。

限制创造力的规则。