Tim Bray：2014年軟件之路
英文原文：Software in 2014
本文作者 Tim Bray 是一位加拿大軟件工程師，也是 Open Text 公司和 Antarctica Systems 的聯合創始人，也是 XML 規范的主要作者之一（有“XML 之父”之稱）。在 2004 年至 2010 年期間，Bray 擔任 Sun 公司 Web 技術主管。此后加入 Google 擔任開發者大使（Developer Advocate），專注 Android 和 Identity。他在這篇文章中分享他對部分軟件技術發展的一些看法。
Tim Bray
我們正處在構建軟件的關鍵期。工具完善，服務端的開發者們很高興，但說到客戶端軟件時，我們真不知去向何方。
前段歡樂時光。構建起的服務端代碼技藝精湛，感謝你們。技術的擴展與提煉將繼續持續下去。
一切都地能夠與 HTTP 通信，而做到這點是很簡單的。
一切都由 MVC 及類似的抽象層構建，并且有許多框架幫我們清晰穩健地完成這項工作。很多人還在使用 PHP 或者 Spring 構建重要的應用不得不說是件遺憾的事情，雖然說這些新框架也沒有強迫你使用它們。
我們仍在為選擇動態類型和靜態類型苦惱中。最后，妥協的理由卻很好理解：兩種語言之間都有好與壞。我兩種都會使用，并且某些時候，使用的理由是顯而易見的。請參見Bánffy-Bray 準則。
并發
函數式編程漸漸在主流語言界享有一席之地。而原因在于關注性能就一定會涉及并發的問題。而一般情況下，人無法處理大量（或者根本不能處理）并發的，極易改變的共享事務。
許多人喜愛 Erlang，雖然它能很優雅地處理并發，甚至提供備用方案，但是它并不能大規模地用在生產中，因為它的數據類型和類概念與其他語言不同。
Clojure 的并發基礎是函數式的，高效且優雅。而 Lisp 式的語法則是缺陷（從經驗上來說，如果你不能像我一樣理解 Lisp 的妙不可言時），而 Scala 雖然比 Java 簡單，并且有像模像樣的 Actor 模型，仍然十分繁雜。
NodeJS 本身不是函數式的，如果處理的一切都是事件，并且可以單線程的話，誰會在乎呢？但是我仍然在對 Node 的 JS 部分十分不滿，待會兒再說明。
Go 給我的印象深刻，雖然它采用了C、Java、Ruby、Clojure 等語言的做法并不能使我開心一笑。我感覺它的類型系統提供了許多針對對象的實用工具，我強烈感到 Goroutines 和類型管道是非常出色的設計，開發者可以夠順利地寫出函數式代碼。這種做法容易，直接又可讀性好，我考慮下一個重大項目的服務端代碼使用 Go 語言編寫。
如果上面的這些都不符合要求，我們還考慮使用這些由高手打造的 Rust、Elixir、Dart 等語言。
存儲
現在各種持久化方案十分成熟。我己經很長時間不再在性能關鍵的運行時系統中使用關系型存儲了；同時它仍有用武之地并有許多開源的選擇。
這些關系型數據庫之后出現的方案也足夠完善。從輕量級的內存緩存到可以操作巨型數據的軟件，都有對應的軟件可供挑選。你可以看看 Cassandra，如果你最近聽過 Adrian Cockcroft 的演講，知道 Netfilx 如何使用它的時候，你就會感到吃驚。
高手們都把磁盤當成新式磁帶一樣，找到合理地使用它的方式。
而另一方面……
客戶端的混亂
情況十分糟糕。你需要造三遍輪子：Web、iOS、Android。我們缺乏人才，而這樣的開發環境十分浪費，一直折磨著我們。
移動端太糟
此處略去 Android 和 iOS 的具體差異，在工程上來說，這些差異不是十分顯著，但是，仍然有以下糟糕之處：
- 首先，你需要開發兩種不同的客戶端。
- 更新周期十分緩慢，以基于瀏覽器的 App 比較，Android 上花的幾個小時，放在 iOS 上就需要幾天時間。更糟糕的是你并不能指望移動用戶接收你的每次更新。發現了一個導致數據丟失，違反用戶協議隱私條款的 bug？足夠讓你吃盡苦頭了。
- 設備非常吃內存、CPU，耗電量猛增。
- 表單的加載越來越慢，出現進度條需要等待。
- 你沒有編程語言的選擇權，如果你厭惡 ObjC 和 Java 的話，就需要考慮換工作了。
- 單元測試很操蛋。
- 有利于用戶但不利于開發者的你而言，移動端對于 UX（用戶體驗）的要求很高，沒有捷徑可尋，同時需要靈感涌現和反復嘗試。
- 使用互聯網的正確方式是點擊瀏覽器上方的搜索欄，輸入你感興趣的內容，點擊搜索，點擊結果鏈接，就可以得到你想要的信息。但是無論你在移動設備上 搜索什么，你都需要安裝相應的應用，同時意味著在手機應用商店還有另外一層搜索，而搜索結果比不上 Google 或者 Bing 的質量。
- 你不能賺錢。嚴肅點來說，蘋果總是談論到他們在應用商店外花的成千上萬的錢。我還沒有聽說過誰靠著應用商店正正經經地賺了許多的錢。
當然，HTML5 熱潮正當其時，告訴人們，如果人們開發的是移動 Web 應用的時候，所有的不利之處（尤其是第一條）就將消解。
但是……
瀏覽器同樣很糟糕 雖然這是個老生常談的話題，但是還是看不出為什么它如此充滿爭議。
JavaScript 不可理喻之處：
> [5, 10, 1].sort (); [ 1, 10, 5 ]
- 以上的例子還有很多。所以就有了 CoffeeScript 和 Dart 這類語言。他們都在想辦法解決這些刻意回避的問題。
瀏覽器的 API 也很糟糕，所以人們都基于 jQuery（以及類似的庫）看作在此之上編程的底層庫，因此讓 JS 變成了 Web 時代的匯編語言。
于是，在實際構造應用程序的時候，你就需要挑選更高層次的框架。網上有很多這樣的框架，很容易就能搜索到相關的信息，像這個：Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012)。但是這個已經是 18 個月前的信息了，放到現在可能完全是錯誤的。你可能會喜歡有更多選擇，但是這樣下去會造成“寒武紀大爆發”式的增長。我覺得 2113 年的軟件架構師會喜歡研究這些問題的。
（同時，請閱讀：Tero Piirainen 的 Frameworkless JavaScript）
- CSS 也很糟糕。我本想解釋這一點，不過已經有這篇文章：Why Sass?，所以我不必這么做了。同時請查看：Less vs Sass vs Stylus，看看有沒有我提到的“寒武紀大爆發”問題？
- 現在還沒有可以像應用商店一樣能篩選應用程序大小的地方。
好了好了，我知道每個以 Web 為中心的大型會議，那些眼睛閃耀光芒的，充滿激情，真心相信瀏覽器的信徒們會向你展示 HTML5 的酷炫之處。而且他們也可以使用加速度傳感器配合麥克風寫出移動設備上的獨特 APP 呢。
那，為什么沒有那么多人這么做呢？提示：請看上面列出的幾條觀點。
我在說”移動端太糟“，不是表面工程軟件的糟糕；而事實上，Cocoa Touch 和 Android app framework 都在 GUI 構建方面做得很好，吸取了很多歷史教訓。關鍵是，你所想要放到 UI 上的東西，都會有一個簡單的，符合標準并經過測試的方法，一般會成為 Google 和 Stack Overflow 網站上的第一條內容。
但是看看投入到 Web 技術的所有精力吧，它真的能跟上當今移動端的技術進步嗎？也許吧，那或許是在 Google 和蘋果的精英團隊及世界上頂尖的 GUI 工程師對它進行一番篩選擴充以后的事情。所以，我有點期待穩扎穩打，一往無前的時刻了。
收益減少
我是個老古董，仍然記得第一波 Web 應用興起的時候，橫掃那些用 Visual Basic、 Motif、Java、Win32 編寫的一整代軟件，正是因為人們喜歡用瀏覽器處理所有的事務。
當然，15 分鐘后，軟件的 VIP 用戶們就開始訴說瀏覽器界面過于笨重，反應不夠靈活，而我們得找到B方案，我發現那些 VIP 客戶們都接受了私有的B方案。于是現在我們有了B方案，至少它符合標準。
但是，我仍然半信半疑。是的，我喜歡讓應用良好地相應手勢，物件有滑進淡出效果，但是那也只是錦上添花，離完美，也就是 80/20 法則所說的那樣還很遠——放在服務器上的良好設計的 Web 應用正常運行，并保持良好的投資回報率。我非常討厭屏幕上四個獨立滾動的，用 JS 控制滾動，看上去外觀非常拙劣的區域。我稍后會寫一些出色的單頁應用，故意來一些縮進讓它看上去有點偏。我尤其討厭讓非技術伙伴，或者親友們遇到上面的糟 糕情況，而我得花時間解釋原委。
接下來？
服務端并無驚喜，諸事順利，一切如往日美好。
而客戶端，我什么也不知道。由歷史原因造成紛繁復雜的做法最終會被那些簡單的，滿足 80/20 法則的做法所替代。如果這正是未來的方向的話，應該不是來自我們這個方向，顯然現在仍然讓我們困惑不已。或許我們還得長期應付這種一個客戶端做三份的情況。
譯文鏈接： http://blog.jobbole.com/58671/
</div>