1. 认知一致

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

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

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

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

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

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

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

2. 工具链一致

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

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

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

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

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

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