如果一个公司采用微服务来构建软件系统，那么每个干系人都需要参与决策。
微服务是一次重大的范式转换。通常，大型组织倾向于使用相当传统的方式来构建软件系统。每个重大发布需要经历数月的研发周期，之后需要一个完备的质量保证阶段以及数小时的部署阶段。
当一个公司选择使用面向微服务的架构时，方法论就会发生完全的改变：每个小团队负责各自的小功能点，包括它们的构建、测试和部署。每个团队各司其职，并且能够处理好各自负责的单一事项（一个微服务，或更确切地说是数个微服务），每个团队成员将熟练掌握构建软件系统的相关技术与领域知识。
这通常被称为跨职能团队。这是一个由少数人组成的工作单元，他们都具备了构建高质量软件组件的能力。
有一点值得注意的是，团队成员应当掌握必要的领域知识来理解业务需求。
在我的职业生涯中，大多数导致公司失败的主要问题不外乎以下这点（就我个人观点而言）。首先，有一种观点认为开发者是“堆砖器”，即可以在没有提前沟通的情况下却依然能神奇地理解业务流。而且，还有观点认为，如果一个开发者一周可以完成X 量级的工作，那么10 个开发者一周就可以交付10X 量级的产量。这些观点都是错误的。
为了保持高效以及考虑到康威定律在改变业务流程方面对系统的影响，构建微服务的跨职能团队中的成员必须熟练掌握（不仅仅是了解）相关领域知识。
每当谈及微服务的组织架构适配时，自治才是关键因素。为了保证构建微服务的敏捷性，每个团队都必须保持自治，这也意味着要确保技术的自主选择权，如下所示：
-
使用的语言。
-
代码规范。
-
解决问题的模式。
-
各类工具的选择，比如软件的构建、测试、调试及部署工具。
这是非常重要的部分，因为这是我们需要定义公司如何构建软件，并且可能会引入工程问题的部分。
举个例子，我们来看看代码规范问题，如下所示：
-
我们需要在所有团队内都保持统一的代码规范吗？
-
我们应该让每个团队都有各自的代码规范吗？
一般来说，我偏好于“80%准则”：80%的完美度已经足以涵盖100%的使用场景。这意味着放宽代码规范（也适用于其他领域），以及允许一定程度的不完美或者个性化，都有助于减少团队间的摩擦，也能让工程师能够尽快关注到那些极少数的重要准则，比如日志策略以及异常处理。
如果你的代码规范过于复杂，那么在某个团队想要向其他团队的微服务提交代码时就会遇到很多阻力（切记，一个团队拥有自己的服务，但是其他团队的成员也可以对这个服务做出贡献）。
想及时获得更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。
