伴随简单而生的复杂

大多数敏捷实践都非常重视简单。XP强调做最简单的事情，只要够用就行。然而，要想做到简单却并不容易，有多种原因会让事情变得更加复杂。敏捷社区的众多成员们讨论了“简单”这个概念，并试图解释为什么想让事情保持简单如此困难。

敏捷强调简单，却总是带来复杂。在一个有趣的帖子中，作者试图揭示该现象背后的原因。他引用了管理科学的最新议题：

很多软件设计者有意创建具有不必要复杂性的产品，以拓展自己的职业发展空间，而不是为了更好地为公司和客户服务。

……

能力强的设计者为了证明自己的才能，会选择不易实现的设计；而能力稍差的设计者因为不想让别人知道自己没有才能，会选择高难度的设计。这是Siemsen教授的结论。

对于将事情复杂化的倾向，George Ambler提到一个类似的原因：

由于想把事情做得 更多、更快，我们花费了太多时间，将我们的生活复杂化了。想把某事做得正确，时间似乎老是不够用，可却总有时间把它再做一遍！考虑到管理技术的复杂性，我们总是喜欢将复杂的解决方案视为更好的。

社区其他成员认为：大家有时为了图省事，才会考虑简单，这反而会带来复杂性。Damon W. Carr在他的blog中，质疑敏捷运动是不是把简单强调得过头了。他问道：

敏捷爱好者们好像患上了严重的“简单强迫症”，极力避免各种开发流程和形式，无论其必要与否。不经意间，团队已将优秀面向对象设计的常识抛在脑后，只是做“够用就好”的事情。在这条路上，敏捷运动是不是走的太远了？

Damon觉得：由于敏捷过分强调可以工作的软件，很多开发人员选择忽略可维护性、可扩展性、代码重用、内部健壮性、组件使用等这些重要的方面。

有些人认为，对于简单与复杂的判断是很主观的。一个人认为简单的事情，另一个人可能会觉得很复杂。Andrew Johnston 说道 ：

简单性和复杂性都是相对而言的，一个人觉得简单的东西，换个角度来看可能就意味着复杂。好比一只鸭子在水面上优雅地滑行，而它的脚蹼却在水下做着复杂而卖力的摆动。

那到底什么是“简单”？又该如何理解“简单”呢？

Brad Appleton在他的博客上提到，他对“简单”做了很多研究，最后得到了如下结论：

我觉得，要说“简单”可能是“简明易懂”的，嗯，这没什么问题；但是要真正理解“简单”却是非常困难的！

Brad认为：系统开发中的简单，意味着要有整体的观念，同时还要能够知道重点何在，而且要知道重点部分对系统其他部分的影响。他强调：真正的简单，是要将整体的复杂性管理起来并尽量将其降到最低的。Brad提到，虽然业界已经在简单上投入了大量精力，然而围绕着它还是有很多神话。他列举出了一些有助于理解简单的言论：

“简单”并不等同于“易于实施/和理解”——要想搞懂更为简单的解决方案，团队可能需要学习新的知识，同时要接纳新的想法。

“简单”并不等同于“足够好”——简单的解决方案也许还不够用。它也许可以暂时满足目前的要求，但是需要进一步改善。

“简单”并不等同于“单纯”——单纯可能只是错误的表象。一个解决方案可能看起来很简单，但是仅仅看起来简单还不够，它必须可以发挥应有的作用。

实现某个要求的简单方式，从全局来看不一定简单——试图简化系统的某个部分，有可能使得系统其他部分更加复杂。要从全局的观点来观察系统。

综上所述，看来在“简单”的周围，有相当多的“复杂”环伺。关键在于要力图澄清围绕着简单的神话，而且要避免“复杂的解决方案更优秀”这样的认知。

查看英文原文： The Complexity Around Simplicity

在infoq英文站的新闻后，读者Jim Leonardo这样评论：

“简单”并不是“第一时间浮现在脑海中的、可以工作的解决方案”。

实际上，要产生简单的解决方案要比复杂方案花费更多的功夫。必须要把所有的佐料放到锅里，再精心烹制，才能做出简单的菜肴。所以经常要用多个迭代才能产生达到这个境界。正如文中指出的，要搞清楚想让 什么变得简单。是要让编码变简单？还是使用简单？或是扩展简单、维护起来简单？

使用简单最不容易在众人之间达成一致，特别是涉及到UI的时候。扩展简单与维护简单通常连在一起。这些都需要更多的编码工作，但并不是说自动会让编码变得更复杂。

另一名读者Frederic Monjo建议读者去阅读John Maeda的“The laws of Simplicity”这本书，其中谈到了如何做到简单的产品设计，但同时提出了一些关于简单的原则和概念。虽然这些原则不是直接用于软件开发的，但可能会激发读者对简单的思考。例如，本文中也提到了一个原则：简单与复杂相生相伴。它们都是相对而言的，必须要同时考虑这二者，并让它们各归其位。