关于简单

PS

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

正文👈

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

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

咱们老是假设复杂的问题须要复杂的解决方案。咱们试图经过发明工具和技术来解决问题；但在这个过程当中，咱们创造了另外一层复杂性，反过来又致使了一系列的问题。

将简单做为一个特性

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

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

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

自主思考，质疑复杂性

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

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

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

若是咱们正在谈论DX （开发者体验）- 我会在任什么时候候坚决果断的选择简单。

PPS

1. 《接触》Contact挺好看的。没有看过的推荐补一下课。
2. 翻译的时候一直在想simplicity翻译成简单仍是简洁好。彷佛这里出现了语言的一个小误差 - 中文不存在一个和simplicity彻底匹配的词。或者说，简单在不一样的场景能够有不一样的理解。最后仍是翻译成简单了。
3. 翻译的流程是先用Google Translate过一遍。而后再手动改。有点偷懒😜。但其实GT的结果仍是很烂的🤬。