本文作者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。他在這篇文章中分享他對(duì)部分軟件技術(shù)發(fā)展的一些看法。

[[108540]]

Tim Bray

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

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

一切都地能夠與HTTP通信，而做到這點(diǎn)是很簡(jiǎn)單的。

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

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

并發(fā)

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

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

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

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

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

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

存儲(chǔ)

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

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

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

而另一方面……

客戶端的混亂

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

移動(dòng)端太糟

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

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

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

但是……

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

• JavaScript不可理喻之處：

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

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

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

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

（同時(shí)，請(qǐng)閱讀：Tero Piirainen的 Frameworkless JavaScript）

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

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

那，為什么沒有那么多人這么做呢？提示：請(qǐng)看上面列出的幾條觀點(diǎn)。

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

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

收益減少

我是個(gè)老古董，仍然記得***波Web應(yīng)用興起的時(shí)候，橫掃那些用Visual Basic、 Motif、Java、Win32編寫的一整代軟件，正是因?yàn)槿藗兿矚g用瀏覽器處理所有的事務(wù)。

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

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

接下來？

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

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

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

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