目录

    1. 认知一致

    在大的组织中,我们可以将小团队理解为一个微服务。

    早在 1967 年,康威提出了微服务的概念。康威认为任何组织在设计一套系统时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。

    在开发复杂系统时,我们通常会对系统进行模块拆分。一方面,个体能解决的问题难度有限,另一方面,个体之间具有一定差异。招聘更优质的工程师,意味着更大的成本。通过模块拆分,能够有效降低问题难度、节约成本。

    每个模块都需要一定数量的工程师,工程师聚集在一起,形成一个团队。这样的团队,只专注于负责的模块,而不必考虑其他,以达到问题复杂度的收敛。

    从整体来看,总的架构师决定了如何划分模块,各个子模块的存在决定了需要更小一级的组织,以此递归。从小团队来看,内部可以自治,任意调整、优化,但是对外必须保证稳定。从个人来看,负责的是具体的事务,这些事务聚合在一起,保障上一级组织的正常运行。

    只有理解了组织,认识到组织的职责,我们的决策才具有统一的准绳。这话没有什么异议,当然也没有什么价值。问题的关键是,组织的成员对组织的认识,是不是能够保持一致,是不是能够更贴近上一级组织。

    从技术服务业务的角度看,加强同级成员对组织的认识水平,是有必要的。

    2. 工具链一致

    在团队中,统一开发环境不是一件容易的事,否则,也不会有 Vim 和 Emacs 之争。

    但是,不同的操作系统、不同的编辑器、不同的公共组件都会给交流带来麻烦。新来了实习生、项目交际、重装了系统、更换了电脑…,都需要花费时间重新搭建开发环境。即使每次都沉淀文档,也很难覆盖全部场景,还需要更新维护文档。

    可以使用 Vagrant、Docker、VirtualBox 等虚拟化技术,屏蔽环境差异,构建统一的开发环境。

    最近,我也对开发环境进行了一次调整。之前,一直使用的是 Windows 本地搭建开发环境,也尝试过 Docker,但是都不太方便。Windows 需要配合 MINGW,Docker 需要配合 VirtualBox,但是都不能模拟线上运行环境。

    现在,我采用的是使用虚拟机在 CentOS 上进行开发。同时,将虚拟机保存在网盘中,同步到线上,在各个开发机上进行同步。

    更进一步,团队中,使用的工具链也应该尽量保持一致。