關於簡單

PS

本文是對 MXB的一篇文章的翻譯。這個在「峯採#2」的時候預告過。

正文👈

在1997年的電影《接觸》中，朱迪福斯特發現了一個包含太空船建造計劃的外星信號。當試圖按照這個設計組裝飛船的時候，工程師們驚訝地發現那只是一個空的金屬艙。

他們說：「這種垃圾是不安全的」（不是原話哈），所以他們將一個複雜的壁掛式座椅安裝在裏面。當船發射時，座椅開始劇烈的振動並被猛烈地撕裂了。女主在她死前的幾秒鐘成功地解開了安全帶，並終於意識到：那個設計其實一直都很完美。女主在平穩的反重力下享受了剩下的旅程併成功抵達外星。

咱們老是假設複雜的問題須要複雜的解決方案。咱們試圖經過發明工具和技術來解決問題；但在這個過程當中，咱們創造了另外一層複雜性，反過來又致使了一系列的問題。

將簡單做爲一個特性

顯然並不是每一個問題都有一個簡單的解決方案。大多數複雜的工具都存在是出於爲真實的須要。但我認爲積極地質疑對複雜性的需求是頗有價值的。有時，構建東西的更聰明的方法是作減法，而不是作加法。

靜態網頁如今再次興起，正是由於它們很簡單。它們不會嘗試使用聰明的抽象來管理服務器端代碼 - 它們沒有任何東西。它們不會嘗試使用高級防火牆來防止安全漏洞，由於靜態網頁徹底擺脫了數據庫。

世界上一些最重要的東西都是故意設計的「簡單」。在任何系統中，錯誤的可能性都會隨着其複雜性而直接增長 - 這就是爲何大多數選舉還是經過將紙片放在一個盒子裏來實現。

自主思考，質疑複雜性

開發人員癡迷於「最佳實踐」這個概念。
這裏的潛臺詞是：存在一種正確的方案，而全部其它解決方案要麼不完美，要麼僅僅是「反模式」(anti pattern)而已。可是每次出現新技術時，最佳實踐的定義都會發生變化，使以前的方案變成毫無價值的垃圾（譯者：原文如此）（即便它仍然能夠完成目的）。

不能否認，咱們在項目中作技術選型的時候有一個因素是自負。爲了向其餘人展現咱們多麼聰明，咱們想出了更難，更炫酷的方法來完成任務。固然，最終它們都解決了具體問題 - 但這並不意味着它們始終是最佳解決方案，不管情景如何。

使用最新最好的技術很酷；但咱們始終應該問一個問題：咱們的選擇是否真的對用戶有益，仍是隻是爲咱們本身選的。畢竟，「開發者體驗」只是達到目的的手段。

若是咱們正在談論DX （開發者體驗）- 我會在任什麼時候候堅決果斷的選擇簡單。

PPS

1. 《接觸》Contact挺好看的。沒有看過的推薦補一下課。
2. 翻譯的時候一直在想simplicity翻譯成簡單仍是簡潔好。彷佛這裏出現了語言的一個小誤差 - 中文不存在一個和simplicity徹底匹配的詞。或者說，簡單在不一樣的場景能夠有不一樣的理解。最後仍是翻譯成簡單了。
3. 翻譯的流程是先用Google Translate過一遍。而後再手動改。有點偷懶😜。但其實GT的結果仍是很爛的🤬。