关于简单

PS

本文是对 MXB的一篇文章的翻译。这个在“峰采#2”的时候预告过。

正文?

在1997年的电影《接触》中，朱迪福斯特发现了一个包含太空船建造计划的外星信号。当试图按照这个设计组装飞船的时候，工程师们惊讶地发现那只是一个空的金属舱。

他们说：“这种垃圾是不安全的”（不是原话哈），因此他们将一个复杂的壁挂式座椅安装在里面。当船发射时，座椅开始剧烈的振动并被猛烈地撕裂了。女主在她死前的几秒钟成功地解开了安全带，并终于意识到：那个设计其实一直都很完美。女主在平稳的反重力下享受了剩下的旅程并成功抵达外星。

我们总是假设复杂的问题需要复杂的解决方案。我们试图通过发明工具和技术来解决问题；但在这个过程中，我们创造了另一层复杂性，反过来又导致了一系列的问题。

将简单作为一个特性

显然并非每个问题都有一个简单的解决方案。大多数复杂的工具都存在是出于为真实的需要。但我认为积极地质疑对复杂性的需求是很有价值的。有时，构建东西的更聪明的方法是做减法，而不是做加法。

静态网页现在再次兴起，正是因为它们很简单。它们不会尝试使用聪明的抽象来管理服务器端代码 - 它们没有任何东西。它们不会尝试使用高级防火墙来防止安全漏洞，因为静态网页完全摆脱了数据库。

世界上一些最重要的东西都是故意设计的“简单”。在任何系统中，错误的可能性都会随着其复杂性而直接增加 - 这就是为什么大多数选举仍是通过将纸片放在一个盒子里来实现。

自主思考，质疑复杂性

开发人员痴迷于“最佳实践”这个概念。
这里的潜台词是：存在一种正确的方案，而所有其它解决方案要么不完美，要么仅仅是“反模式”(anti pattern)而已。但是每次出现新技术时，最佳实践的定义都会发生变化，使之前的方案变成毫无价值的垃圾（译者：原文如此）（即使它仍然可以完成目的）。

不可否认，我们在项目中做技术选型的时候有一个因素是自负。为了向其他人展示我们多么聪明，我们想出了更难，更炫酷的方法来完成任务。当然，最终它们都解决了具体问题 - 但这并不意味着它们始终是最佳解决方案，无论情景如何。

使用最新最好的技术很酷；但我们始终应该问一个问题：我们的选择是否真的对用户有益，还是只是为我们自己选的。毕竟，“开发者体验”只是达到目的的手段。

如果我们正在谈论DX （开发者体验）- 我会在任何时候毫不犹豫的选择简单。

PPS

1. 《接触》Contact挺好看的。没有看过的推荐补一下课。
2. 翻译的时候一直在想simplicity翻译成简单还是简洁好。似乎这里出现了语言的一个小偏差 - 中文不存在一个和simplicity完全匹配的词。或者说，简单在不同的场景可以有不同的理解。最后还是翻译成简单了。
3. 翻译的流程是先用Google Translate过一遍。然后再手动改。有点偷懒?。但其实GT的结果还是很烂的?。