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

[[108540]]

Tim Bray

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

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

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

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

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

并發(fā)

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

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

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

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

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

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

存儲

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

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

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

而另一方面……

客戶端的混亂

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

移動端太糟

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

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

當(dāng)然，HTML5熱潮正當(dāng)其時，告訴人們，如果人們開發(fā)的是移動Web應(yīng)用的時候，所有的不利之處（尤其是***條）就將消解。

但是……

瀏覽器同樣很糟糕 雖然這是個老生常談的話題，但是還是看不出為什么它如此充滿爭議。

• JavaScript不可理喻之處：

> [5, 10, 1].sort(); 
[ 1, 10, 5 ] 

• 以上的例子還有很多。所以就有了CoffeeScript和Dart這類語言。他們都在想辦法解決這些刻意回避的問題。

瀏覽器的API也很糟糕，所以人們都基于jQuery（以及類似的庫）看作在此之上編程的底層庫，因此讓JS變成了Web時代的匯編語言。

于是，在實際構(gòu)造應(yīng)用程序的時候，你就需要挑選更高層次的框架。網(wǎng)上有很多這樣的框架，很容易就能搜索到相關(guān)的信息，像這個：Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012)。但是這個已經(jīng)是18個月前的信息了，放到現(xiàn)在可能完全是錯誤的。你可能會喜歡有更多選擇，但是這樣下去會造成“寒武紀(jì)大爆發(fā)”式的增長。我覺得2113年的軟件架構(gòu)師會喜歡研究這些問題的。

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

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

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

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

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

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

收益減少

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

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

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

接下來？

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

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

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

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