本文作者Tim Bray 是一位加拿大軟件工程師， 也是 Open Text 公司和 Antarctica Systems 的聯(lián)合創(chuàng)始人，也是 XML 規(guī)范的主要作者之一（有“XML之父”之稱）。在2004年至2010年期間，Bray 擔任 Sun 公司 Web 技術主管。此后加入 Google 擔任開發(fā)者大使（Developer Advocate），專注 Android 和 Identity。他在這篇文章中分享他對部分軟件技術發(fā)展的一些看法。

[[108540]]

Tim Bray

我們正處在構建軟件的關鍵期。工具完善，服務端的開發(fā)者們很高興，但說到客戶端軟件時，我們真不知去向何方。

前段歡樂時光。構建起的服務端代碼技藝精湛，感謝你們。技術的擴展與提煉將繼續(xù)持續(xù)下去。

一切都地能夠與HTTP通信，而做到這點是很簡單的。

一切都由MVC及類似的抽象層構建，并且有許多框架幫我們清晰穩(wěn)健地完成這項工作。很多人還在使用PHP或者Spring構建重要的應用不得不說是件遺憾的事情，雖然說這些新框架也沒有強迫你使用它們。

我們仍在為選擇動態(tài)類型和靜態(tài)類型苦惱中。***，妥協(xié)的理由卻很好理解：兩種語言之間都有好與壞。我兩種都會使用，并且某些時候，使用的理由是顯而易見的。請參見Bánffy-Bray 準則。

并發(fā)

函數(shù)式編程漸漸在主流語言界享有一席之地。而原因在于關注性能就一定會涉及并發(fā)的問題。而一般情況下，人無法處理大量（或者根本不能處理）并發(fā)的，極易改變的共享事務。

許多人喜愛Erlang，雖然它能很優(yōu)雅地處理并發(fā)，甚至提供備用方案，但是它并不能大規(guī)模地用在生產中，因為它的數(shù)據(jù)類型和類概念與其他語言不同。

Clojure的并發(fā)基礎是函數(shù)式的，高效且優(yōu)雅。而Lisp式的語法則是缺陷（從經驗上來說，如果你不能像我一樣理解Lisp的妙不可言時），而Scala雖然比Java簡單，并且有像模像樣的Actor模型，仍然十分繁雜。

NodeJS本身不是函數(shù)式的，如果處理的一切都是事件，并且可以單線程的話，誰會在乎呢？但是我仍然在對Node的JS部分十分不滿，待會兒再說明。

Go給我的印象深刻，雖然它采用了C、Java、Ruby、Clojure等語言的做法并不能使我開心一笑。我感覺它的類型系統(tǒng)提供了許多針對對象 的實用工具，我強烈感到Goroutines和類型管道是非常出色的設計，開發(fā)者可以夠順利地寫出函數(shù)式代碼。這種做法容易，直接又可讀性好，我考慮下一 個重大項目的服務端代碼使用Go語言編寫。

如果上面的這些都不符合要求，我們還考慮使用這些由高手打造的Rust、Elixir、Dart等語言。

存儲

現(xiàn)在各種持久化方案十分成熟。我己經很長時間不再在性能關鍵的運行時系統(tǒng)中使用關系型存儲了；同時它仍有用武之地并有許多開源的選擇。

這些關系型數(shù)據(jù)庫之后出現(xiàn)的方案也足夠完善。從輕量級的內存緩存到可以操作巨型數(shù)據(jù)的軟件，都有對應的軟件可供挑選。你可以看看Cassandra，如果你最近聽過Adrian Cockcroft的演講，知道Netfilx如何使用它的時候，你就會感到吃驚。

高手們都把磁盤當成新式磁帶一樣，找到合理地使用它的方式。

而另一方面……

客戶端的混亂

情況十分糟糕。你需要造三遍輪子：Web、iOS、Android。我們缺乏人才，而這樣的開發(fā)環(huán)境十分浪費，一直折磨著我們。

移動端太糟

此處略去Android和iOS的具體差異，在工程上來說，這些差異不是十分顯著，但是，仍然有以下糟糕之處：

• 首先，你需要開發(fā)兩種不同的客戶端。
• 更新周期十分緩慢，以基于瀏覽器的App比較，Android上花的幾個小時，放在iOS上就需要幾天時間。更糟糕的是你并不能指望移動用戶接收你的每次更新。發(fā)現(xiàn)了一個導致數(shù)據(jù)丟失，違反用戶協(xié)議隱私條款的bug？足夠讓你吃盡苦頭了。
• 設備非常吃內存、CPU，耗電量猛增。
• 表單的加載越來越慢，出現(xiàn)進度條需要等待。
• 你沒有編程語言的選擇權，如果你厭惡ObjC和Java的話，就需要考慮換工作了。
• 單元測試很操蛋。
• 有利于用戶但不利于開發(fā)者的你而言，移動端對于UX（用戶體驗）的要求很高，沒有捷徑可尋，同時需要靈感涌現(xiàn)和反復嘗試。
• 使用互聯(lián)網的正確方式是點擊瀏覽器上方的搜索欄，輸入你感興趣的內容，點擊搜索，點擊結果鏈接，就可以得到你想要的信息。但是無論你在移動設備上 搜索什么，你都需要安裝相應的應用，同時意味著在手機應用商店還有另外一層搜索，而搜索結果比不上Google或者Bing的質量。
• 你不能賺錢。嚴肅點來說，蘋果總是談論到他們在應用商店外花的成千上萬的錢。我還沒有聽說過誰靠著應用商店正正經經地賺了許多的錢。

當然，HTML5熱潮正當其時，告訴人們，如果人們開發(fā)的是移動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個月前的信息了，放到現(xiàn)在可能完全是錯誤的。你可能會喜歡有更多選擇，但是這樣下去會造成“寒武紀大爆發(fā)”式的增長。我覺得2113年的軟件架構師會喜歡研究這些問題的。

（同時，請閱讀：Tero Piirainen的 Frameworkless JavaScript）

•  CSS也很糟糕。我本想解釋這一點，不過已經有這篇文章：Why Sass?，所以我不必這么做了。同時請查看：Less vs Sass vs Stylus，看看有沒有我提到的“寒武紀大爆發(fā)”問題？
• 現(xiàn)在還沒有可以像應用商店一樣能篩選應用程序大小的地方。

好了好了，我知道每個以Web為中心的大型會議，那些眼睛閃耀光芒的，充滿激情，真心相信瀏覽器的信徒們會向你展示HTML5的酷炫之處。而且他們也可以使用加速度傳感器配合麥克風寫出移動設備上的獨特APP呢。

那，為什么沒有那么多人這么做呢？提示：請看上面列出的幾條觀點。

我在說”移動端太糟“，不是表面工程軟件的糟糕；而事實上，Cocoa Touch和Android app framework都在GUI構建方面做得很好，吸取了很多歷史教訓。關鍵是，你所想要放到UI上的東西，都會有一個簡單的，符合標準并經過測試的方法， 一般會成為Google和Stack Overflow網站上的***條內容。

但是看看投入到Web技術的所有精力吧，它真的能跟上當今移動端的技術進步嗎？也許吧，那或許是在Google和蘋果的精英團隊及世界上***的GUI工程師對它進行一番篩選擴充以后的事情。所以，我有點期待穩(wěn)扎穩(wěn)打，一往無前的時刻了。

收益減少

我是個老古董，仍然記得***波Web應用興起的時候，橫掃那些用Visual Basic、 Motif、Java、Win32編寫的一整代軟件，正是因為人們喜歡用瀏覽器處理所有的事務。

當然，15分鐘后，軟件的VIP用戶們就開始訴說瀏覽器界面過于笨重，反應不夠靈活，而我們得找到B方案，我發(fā)現(xiàn)那些VIP客戶們都接受了私有的B方案。于是現(xiàn)在我們有了B方案，至少它符合標準。

但是，我仍然半信半疑。是的，我喜歡讓應用良好地相應手勢，物件有滑進淡出效果，但是那也只是錦上添花，離***，也就是80/20法則所說的那樣還 很遠——放在服務器上的良好設計的Web應用正常運行，并保持良好的投資回報率。我非常討厭屏幕上四個獨立滾動的，用JS控制滾動，看上去外觀非常拙劣的 區(qū)域。我稍后會寫一些出色的單頁應用，故意來一些縮進讓它看上去有點偏。我尤其討厭讓非技術伙伴，或者親友們遇到上面的糟糕情況，而我得花時間解釋原委。

接下來？

服務端并無驚喜，諸事順利，一切如往日美好。

而客戶端，我什么也不知道。由歷史原因造成紛繁復雜的做法最終會被那些簡單的，滿足80/20法則的做法所替代。如果這正是未來的方向的話，應該不是來自我們這個方向，顯然現(xiàn)在仍然讓我們困惑不已?；蛟S我們還得長期應付這種一個客戶端做三份的情況。

原文鏈接：https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014

譯文鏈接：http://blog.jobbole.com/58671/