乐趣区

关于简单

PS
本文是对 MXB 的一篇文章的翻译。这个在“峰采 #2”的时候预告过。
正文????
在 1997 年的电影《接触》中,朱迪福斯特发现了一个包含太空船建造计划的外星信号。当试图按照这个设计组装飞船的时候,工程师们惊讶地发现那只是一个空的金属舱。
他们说:“这种垃圾是不安全的”(不是原话哈),因此他们将一个复杂的壁挂式座椅安装在里面。当船发射时,座椅开始剧烈的振动并被猛烈地撕裂了。女主在她死前的几秒钟成功地解开了安全带,并终于意识到:那个设计其实一直都很完美。女主在平稳的反重力下享受了剩下的旅程并成功抵达外星。
我们总是假设复杂的问题需要复杂的解决方案。我们试图通过发明工具和技术来解决问题;但在这个过程中,我们创造了另一层复杂性,反过来又导致了一系列的问题。
将简单作为一个特性
显然并非每个问题都有一个简单的解决方案。大多数复杂的工具都存在是出于为真实的需要。但我认为积极地质疑对复杂性的需求是很有价值的。有时,构建东西的更聪明的方法是做减法,而不是做加法。
静态网页现在再次兴起,正是因为它们很简单。它们不会尝试使用聪明的抽象来管理服务器端代码 – 它们没有任何东西。它们不会尝试使用高级防火墙来防止安全漏洞,因为静态网页完全摆脱了数据库。
世界上一些最重要的东西都是故意设计的“简单”。在任何系统中,错误的可能性都会随着其复杂性而直接增加 – 这就是为什么大多数选举仍是通过将纸片放在一个盒子里来实现。
自主思考,质疑复杂性
开发人员痴迷于“最佳实践”这个概念。这里的潜台词是:存在一种正确的方案,而所有其它解决方案要么不完美,要么仅仅是“反模式”(anti pattern) 而已。但是每次出现新技术时,最佳实践的定义都会发生变化,使之前的方案变成毫无价值的垃圾(译者:原文如此)(即使它仍然可以完成目的)。
不可否认,我们在项目中做技术选型的时候有一个因素是自负。为了向其他人展示我们多么聪明,我们想出了更难,更炫酷的方法来完成任务。当然,最终它们都解决了具体问题 – 但这并不意味着它们始终是最佳解决方案,无论情景如何。
使用最新最好的技术很酷;但我们始终应该问一个问题:我们的选择是否真的对用户有益,还是只是为我们自己选的。毕竟,“开发者体验”只是达到目的的手段。
如果我们正在谈论 DX(开发者体验)- 我会在任何时候毫不犹豫的选择简单。
PPS

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

退出移动版