以后会定期更新一些关于软件架构方面的知识总结，可能目前的工作年限并不能让我成为一名合格的架构师，但先积累着吧。
最近在看一本架构师杂志时，发现上面提及了《康威定律》，百度了一下，这里做个笔记。杂志中是提及微服务架构时才涉及康威定律的讨论，我是从事桌面开发的，微服务架构可能不一定能在工作中用到，
但是先学习学习吧，以后的事谁知道呢。虽然桌面开发没有微服务架构，但模块化、插件式开发，还是跟微服务架构有相同之处的。
康威定律
这是康威在1967年在论文里提出来的，后来被软件开发神书《人月神话》引用并总结成四条定律。
设计系统的组织，其产生的设计和架构等价于组织间的沟通结构
Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
将单块架构解耦成微服务，每个团队开发、测试、发布自己负责的微服务，互不干扰，系统效率得到提升
时间再多一件事情也不可能做的完美，但总有时间做完一件事情
There is never enough time to do something right, but there is always enough time to do it over。
敏捷开发中，主张持续交付，快速迭代，及时反馈，立刻验证，持续优化。看了许多github上优秀的项目，基本上都是经过了长期的版本更新才有今天的star数。所以一次想把一件事做好，确实不太现实。还是关注眼前吧
线型系统和线型组织架构间有潜在的异质同态特性
There is a homomorphism from the linear graph of a system to the linear graph of its design organization.
异质同态指的是系统和组织虽然是两个东西，但是有相同的结构。直白的说就是想要什么的系统就搭建什么样的团队，有什么样的团队就搭建什么样的系统。需要前后端分离的系统就搭建前后端分离的团队，反之，拥有前后端分离的团队，可以设计前后端分离的系统。当然，如果能统筹管理，拥有重组团队或设计系统架构的权利，那就再好不过了。通常情况下让两者形成1：1的映射关系，更加高效。
大的系统组织总是比小系统更倾向于分解
The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。
系统越复杂，越需要增加人手，人手越多，沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案。分不同的层级，分不同的小团队，让团队内部完成自治理，然后统一对外沟通。
这里我个人的感觉，跟项目开发也是一个道理。项目就好比是组织，项目越复杂，就越需要分模块，分层，让模块、层内部完成自己的功能，然后再统一对外抛出接口。