[读]2. Simplify essential complexity; diminish accidental complexity

http://architect.97things.oreilly.com/wiki/index.php/Simplify_essential_complexity;_diminish_accidental_complexity

 

 

Essential complexity represents the difficulty inherent in any problem. For example, coordinating a nation’s air traffic is an inherently complex problem. Every plane’s exact position (including altitude), speed, direction and destination must be tracked in real time to prevent mid air and runway collisions. The flight schedules of aircraft must be managed to avoid airport congestion in a continuously changing environment – a sever change in weather throws the entire schedule out of whack.

 

Conversely, accidental complexity grows from the things we feel we must build to mitigate essential complexity. The antiquated air traffic control system used today is an example of accidental complexity. It was designed to address the essential complexity of controlling the traffic of thousands of airplanes, but the solution itself introduces it’s own complexity. In fact, the air traffic control system used today is so complex that updating it has proven to be difficult if not impossible. In much of the world air traffic is guided by technology that is more than 30 years old.

 

Many frameworks and vendor "solutions" are the symptoms of the accidental complexity disease. Frameworks that solve specific problems are useful. Over-engineered frameworks add more complexity than they relieve.

 

Developers are drawn to complexity like moths to flame, frequently with the same result. Puzzle solving is fun, and developers are problem solvers. Who doesn't like the rush of solving some incredibly complex problem? In large-scale software, though, removing accidental complexity while retaining the solution to the essential complexity is challenging.

 

How do you do this? Prefer frameworks derived from working code rather than ones cast down from ivory towers. Look at the percentage of code you have in a solution that directly addresses the business problem vs. code that merely services the boundary between the application and the users. Cast a wary eye on vendor driven solutions. They may not be inherently bad, but vendors often push accidental complexity. Make sure that the solution fits the problem.

It’s the duty of the architect to solve the problems inherent in essential complexity without introducing accidental complexity. By Neal Ford This work is licensed under a Creative Commons Attribution 3   (wc 342)  

 

简化本质的复杂性，降低次要的复杂性

 

从这个标题就知道，对于一个系统，关键问题是区分本质性（essential）的还是非本质性的。

 

这的确是关键，一个使用的是30年前的技术开发的系统肯定看上去不是很顺眼，记得我有个师兄，毕业后去做COBOL系统了，被我们瞟笑了N久，但用什么技术并不是关键，关键在于系统背后本质性的问题是否得到解决。

 

目前正参与一个改造项目，眼看着就要误入歧途了。这是一个老式的数据交换服务，一个用户在其终端上录入信息然后发生，这份信息会经过2、3个系统，经过各种转换校验，最终进入目的公司的系统，此改造项目就是传输过程中的一个环节。由于改造是开发团队主导的，结果就是从前到后全部翻新了下，引入了规则引擎、动态界面、全文搜索等技术，但“本质性的问题”却没有人关心。真正本质性的复杂度是什么？录入的用户希望输入的数据能及时、正确的被目标系统接收，从而完成一项业务，但其中会涉及各种消息格式、传输协议、校验逻辑，涉及多个系统的权限配置和流程设置，一旦某个环节有问题，数据无法送达目的地，此项业务就无法完成。而此用户根本不懂这些技术，万一数据在某个环节被卡，真是叫天不应叫地不灵。

 

so，时刻关注架构是否聚焦于业务固有的本质的复杂性，但首先架构师必须从客户提交的各类纷繁的需求、营销部门要求提供的各类花里胡哨的功能、开发团队希望引入的各种技术中准确的抓住这所谓的本质复杂性。