關於簡單
PS
本文是對MXB的一篇文章 的翻譯。這個在“峰採#2”的時候預告過。
正文:point_left:
在1997年的電影《接觸》中，朱迪福斯特發現了一個包含太空船建造計劃的外星訊號。當試圖按照這個設計組裝飛船的時候，工程師們驚訝地發現那只是一個空的金屬艙。
他們說：“這種垃圾是不安全的”（不是原話哈），因此他們將一個複雜的壁掛式座椅安裝在裡面。當船發射時，座椅開始劇烈的振動並被猛烈地撕裂了。女主在她死前的幾秒鐘成功地解開了安全帶，並終於意識到：那個設計其實一直都很完美。女主在平穩的反重力下享受了剩下的旅程併成功抵達外星。
我們總是假設複雜的問題需要複雜的解決方案。我們試圖通過發明工具和技術來解決問題；但在這個過程中，我們創造了另一層複雜性，反過來又導致了一系列的問題。
將簡單作為一個特性
顯然並非每個問題都有一個簡單的解決方案。大多數複雜的工具都存在是出於為真實的需要。但我認為積極地質疑對複雜性的需求 是很有價值的。有時，構建東西的更聰明的方法是做減法，而不是做加法。
靜態網頁現在再次興起，正是因為它們很簡單。它們不會嘗試使用聰明的抽象來管理伺服器端程式碼 - 它們沒有任何東西。它們不會嘗試使用高階防火牆來防止安全漏洞，因為靜態網頁完全擺脫了資料庫。
世界上一些最重要的東西都是故意設計的“簡單”。在任何系統中，錯誤的可能性都會隨著其複雜性而直接增加 - 這就是為什麼大多數選舉仍是通過將紙片放在一個盒子裡來實現。
自主思考，質疑複雜性
開發人員痴迷於“最佳實踐”這個概念。
這裡的潛臺詞是：存在一種正確的方案，而所有其它解決方案要麼不完美，要麼僅僅是“反模式”(anti pattern)而已。但是每次出現新技術時，最佳實踐的定義都會發生變化，使之前的方案變成毫無價值的垃圾（譯者：原文如此）（即使它仍然可以完成目的）。
不可否認，我們在專案中做技術選型的時候有一個因素是自負。為了向其他人展示我們多麼聰明，我們想出了更難，更炫酷的方法來完成任務。當然，最終它們都解決了具體問題 - 但這並不意味著它們始終是最佳解決方案，無論情景如何。
使用最新最好的技術很酷；但我們始終應該問一個問題：我們的選擇是否真的對使用者有益，還是隻是為我們自己選的。畢竟，“開發者體驗”只是達到目的的手段。
如果我們正在談論DX （開發者體驗）- 我會在任何時候毫不猶豫的選擇簡單。
PPS
- 《接觸》Contact挺好看的。沒有看過的推薦補一下課。
- 翻譯的時候一直在想simplicity翻譯成簡單還是簡潔好。似乎這裡出現了語言的一個小偏差 - 中文不存在一個和simplicity完全匹配的詞。或者說，簡單 在不同的場景可以有不同的理解。最後還是翻譯成簡單了。
- 翻譯的流程是先用Google Translate過一遍。然後再手動改。有點偷懶:stuck_out_tongue_winking_eye:。但其實GT的結果還是很爛的。