解决技术复杂性的三种方法，分享给你！
蓝色关注，回复“1”获取知名公司程序员和产品经理职级
这是我的第「106」篇原创文章
见字如面，我是军哥。
我的读者80%以上都是互联网行业从业人群，大家对软件系统的复杂性是有目共睹的，然而软件的复杂性就没有办法解决了吗？
比如，我们遇到复杂性问题，高手一般可以将问题拆分成几个小问题，问题迎刃而解，而我们怎么也想不到办法，怎么办？
比如，你负责的系统依赖第三方系统，基本第三方系统一挂，你的系统就歇菜，怎么办？
比如，一个新业务功能需要串联多个部门多条产品线，经常遇到上线延迟，或者 bug 频发，怎么办？
今天的文章将从「分而治之，低依赖架构、康威定律」三点逐一展开。
1.分而治之
“分而治之“，这个处理难题的哲学，在计算机行业是普遍存在，比如计算机网络的7层模型，软件系统的多层架构。但这都是计算机行业处理事的角度和侧面。
Edsger Dijkstra（他是计算机先驱之一，他开发了程序设计的框架结构）相信，控制软件复杂性的最好办法就是创建层次化的架构，每一层将下一层作为一个虚拟机。我们可以称之为“按结构划分”。
Barry Boehrm（软件工程估算模型COCOMO模型之父、软件过程螺旋式模型之父）推荐我们“按过程划分”，在每个过程之后都有验证步骤。但是，这种方法在处理软件与生俱来的复杂性时没有效果，Tom Gilb推荐我们“按价值划分”，这种方法经受住了时间的考验。
在人的角度，会不会也有运用呢？答案是肯定的。
软件公司一个敏捷团队通过职责划分为，运营、产品经理、程序员，测试工程师、运维工程师，这些不同专业领域的人在一起协作完成既定的业务目标。
总之，“分而治之”运用是极其广泛的。
2.低依赖架构
我相信做过开发的同学在设计系统时，都会有职责分离，充分解耦的指导思想。然而大家都懂的道理，依然还会犯错。
我见过一个场景，是一家电商公司，它的订单和物流单是一张表，然后订单要加需求就往里面加字段，物流单有需求也加字段，就这样加着加着，一年过去了，一张订单主表有了100多个字段。
但是谁也说不清所有字段的真实含义和哪些字段已经废弃，当订单的产品和物流履约的产品经理都来提需求的时候，开发是极其郁闷且无奈的，然而这种高依赖的架构，就是我们常见的「技术债」（另外关于架构我看过目前为止最好的一份资料，如下图，公众号后台回复“499”获取）。
这些债出来混迟早要还的，而且还很昂贵。
并且这种软件架构也会导致组织架构纠缠不清，我们继续看下面终极解决方案——康威法则。
3.康威定律
“设计系统的组织架构会受到一种限制，即产生的设计会复制这些组织机构的沟通结构“，Mel Conway在1968年写道。他认为，设计者第一次想到的架构几乎不可能是最好的设计，所以公司应该同时准备好改变他们产品架构和组织架构。
这个解释有点难以理解，我们来看下面的例子：
第一个场景：有些公司产品团队，开发团队、测试团队、运维团队分别汇报给对应的老大，但是做事的时候是需要依赖多个团队，这里需要大量的沟通和协调成本，导致整个组织效率非常低下。
第二个场景：公司有了多条产品线，这个时候很多初创型公司或者大公司的创新部门，为了提升效率，整个 team 都汇报给产品负责人，或者除了产品，其他人都汇报给技术负责人，这就是为了产品更快交付做出组织架构设计。
第三个场景：也就是大家见到很多公司的情况，有一个叫做共享或者中台部门，他们进一步把一些通用性或者平台型能力沉淀，来适应市场竞争的需要。
天下之事，分久必合合久必分，最终的公司架构演变如下图所示：
写在最后
以上，是今天讨论主题的全部。
软件架构在执行层面非常微观，也非常之复杂，但是从宏观上来说，是有解决之道的。
软件架构在一定程度上与组织架构关联，当我们发现耦合多了，需要合并组织架构很多疑难问题立刻化为乌有，当我们发现大家都在干一样基础能力建设的时候，此时应抽象成横向组织来多平台或中台。
总之，组织架构必将分久必合，合久必分，找到为什么合或分的理由并在相应的时间点做过选择，这或许是值得思考的。
关于今天的主题，你有什么样的收获或建议？请留言区留下你的「精彩」评论吧。
公众号对话框回复 w，获取微信与我建立连接和互动。
-------
以往热文推荐：
更多精彩，关注我公众号，一起学习、成长
▲ 长按关注军哥手记，一起学习、成长