康威定理

让我分享一下我尝试在大中型公司中引入它的经验。有些你会看到的东西听起来很明显，但是这是我的经验，我想和你分享。这些年来我学到的第一件事是：从小处着手！ 从小事做起这是什么意思？这意味

我想写下为什么从一个全新的项目开始使用微服务通常是一个坏主意。时机已到，这正是我将在本文中讨论的内容。微服务变得越来越自然，我们几乎感觉自己一直生活在微服务的世界里。最近，当我与其他开发人员交谈并询问他们将如何启动绿地项目时，几乎可以肯定，答案是，嗯，一个微服务用于此，另一个

亮点：微服务并不能确保良好的模块化：如果您使用微服务足够多，您可能会构建或借用一些不错的工具来简化服务之间的通信。但是，如果你不小心，你最终会得到一个紧密耦合的微服务式单体，每个函数都有大量的 HTTP 调用和要处理的版本控制。 在 Web 软件架

由 Matthew Skelton 和 Manuel Pais撰写的《团队拓扑——组织业务和技术团队以实现快速流动》一书将帮助您设计团队组织结构，从而帮助您变得更加敏捷。这本书分为三个部分： 第一部分侧重于作为交付手段的团队。 第二部分解释了适用于流程的团队拓

组件团队：每个团队负责一个系统组件。例如，有一个团队负责前台，一个团队负责后台，还有一个团队负责数据库。这三个团队独立运作，这经常导致团队之间的相互依赖。这些团队不是为最终用户提供价值，而是花了很多时间来讨论依赖关系和测试各组件的行为。从买方的角度来看，这些要素完全不重要。组

本文《Agile as Trauma》指出敏捷的本质是反动的（reactionary：保守、落后、反动）。敏捷就像任何概念一样，必须适应和学习，将产品管理和领域驱动设计的方法与敏捷相结合是我们今天所处的位置，但这种组合还没有被命名。原文点击标题：

我真的希望我们可以作为一个团队做更多的工程，创建、设计、研究和构建出色的软件。但相反，任何在2-4 天内无法完成的事情都会被取消优先级并放入积压工作中。其他讨厌点：会议超负荷。我觉得我是产品团队的仆人。作为一名工程师，我无法进行创新。

多年来，我们注意到开发具有高性能和高效率的软件是多么困难，以及团队因素在这个等式中是多么重要。有时我们没有意识到，我们并不总是需要最好的语言、技术或任何先进或疯狂的概念来达到最佳效果。相反，我们需要的是在心中保持最佳的组织结构，以便使事情变得简单。

有人曾经告诉我，任何类型的团队或组织所经历的最艰难的转变是从大约 30 人增长到 60 人。当时，我记得我在想，“嗯，这很随意。当然，每个组织都是不同的。” 在某些方面，每个组织都是不同的。然而，我见过各种各样的团队都经历过这样的成长期，一遍又一遍地面临同样的挑战。随着每年都有大量新

软件设计与康威定理是两种不同的东西，软件设计是针对软件的，康威定律认为团队组织管理方式决定了软件的设计，因为这两者本身就属于一个大系统。但是虽然你的团队划分按照康威定律，最终软件设计还是不行，原因是康威定律并不适用于刚性的硬设计，

AdHoc需要在快速发展的工程团队中推出新的领导层，需要重新构想如何沟通，以及信息将如何在这个新的领导层中流动。 松耦合和高对齐成长中的公司通常只是在高级领导下划分子组的层次结构，这会导致多个不同的组织孤岛，负担过重的高级领导者试图协

 连续架构六大原则 连续架构不是一种架构方法。这真的是一种心态，几乎是一种工作方式，一种思维方式。第一个是你应该架构你的产品。很多人会考虑我需要实施的项目，但您应该考虑我正在实施的软件产品是什么，以及它的旅程是什么。<

如果我可以推荐一本专业书籍给任何从事 IT 工作的人阅读，那就是Mathew Skelton 和 Manuel Pais 的《团队拓扑》。顾名思义，主题是关于组织业务

阶段性工作、回顾、完善和类似的工作所花费的时间是疯狂的。如果我假设每天有15分钟的停顿，两个小时左右的完善和回顾（我曾在一个地方有四个小时的完善），那简直就是把一天的冲刺时间浪费在了会议上。 如果团队中的人只是在电子邮件中告诉经理/主管 "我被这个

1、有效的软件是与业务挑战相一致的软件我们所说的一致，是指软件从领域中借用正确的术语，正确阐述业务的关键概念，并尽可能少地避免技术问题带来的意外的复杂性。 2、康威定律不是一个可以选择不接受

改善交付时间应该是每个组织的目标。阻碍交付流程加速的一个主要减速器是组织中的不同团队传统上一直在孤岛中工作。为了解决这个问题，在大多数情况下会出现一个简单的解决方案：增加不同团队之间的沟通。但是，这个解决方案就足够了吗？当公司成长时，“增量沟通解决方案”如何扩展？我们将在本文中解释其