阿菜ing

在任何问题上，必需的复杂事物代表了问题的难度。例如，协调一个国家的空中交通是一个复杂的事情。每架飞机的确切位置（包括高度)，速度，方向和目标，必须进行实时跟踪，以防止半空中和跑道上发生碰撞。该航班的飞机，必须能够在一个不断变化的环境中，设法避免意外事情的发生。

相反，额外复杂事物的发展让我们意识到必须减少必需的复杂性。今天我们使用过时的空中交通管制系统就是一个意外复杂的例子。他被设计解决控制数以千计的飞机的复杂问题，但是这个方案本身介绍起来就十分复杂，事实上今天我们使用的空中交通管制系统使用起来是非常复杂的，更新它已经被证明是不可能的，在世界许多地区，空中交通的技术上的指导都超过30年了。

许多框架和解决方案供应商都患有增加意外复杂性的毛病，框架解决具体的问题是有益的，但是框架本身往往添加的复杂性往往超过了他们减少的复杂性。

开发商经常为了达到相同的结果要去解决一些棘手复杂问题，解惑是有趣的，开发商就是解决问题的，谁不喜欢匆忙解决一些难以置信的复杂问题？但是在大型软件，排除意外的复杂性，同时保持了解决必须的复杂性是至关重要的挑战。

你是怎么做的？ 喜欢框架是来源于工作编码的需要，而不是仅仅从象牙塔拿下来。看看在一个解决方案中能够直接处理的业务问题的代码和只是应用和用户之间服务的代码的百分比，仔细用心去观察每个提供解决方案的供应商，他们本质上不是坏的，但是厂商往往增加了意外的复杂性，要确保解决方案适合这个问题。

架构师有责任去解决固有的复杂性而不去增加额外的复杂性。

选自：Simplify essential complexity; diminish accidental complexity