Ruff破局IoT 困境的思考 - 全文

IoT 時代可以說是互聯(lián)網(wǎng)的下一代，將更多的物和設(shè)備連接起來。IoT 時代硬件，已經(jīng)不再是做一款獨立的硬件，IoT 研發(fā)已經(jīng)進入困境，為此Ruff 進行了一次破局 IoT 研發(fā)困境的嘗試。

提及 IoT（物聯(lián)網(wǎng)，Internet of Things），幾乎整個 IT 行業(yè)的共識是未來一定會是一個 IoT 時代，繼互聯(lián)網(wǎng)時代將更多的人連接到一起之后，IoT 時代將會把更多的物（Thing）連接起來。但是，一說到 IoT 的研發(fā)，人們的第一反應(yīng)通常是，物就是硬件，做硬件就要懂嵌入式，所以，IoT 開發(fā)就是嵌入式開發(fā)。于是，我們看到在 IoT 的指引下，各大硬件廠商和嵌入式操作系統(tǒng)廠商搖旗吶喊，紛紛暢想著 IoT 的未來，而現(xiàn)在的 IoT 行業(yè)狀態(tài)卻是，只問腳步聲，未見人下來。為什么會這樣？我們不妨簡要分析一下。

1 IoT 研發(fā)困境

? 產(chǎn)品經(jīng)理與硬件工程師難以協(xié)同

在 IoT 時代，做一個硬件，已經(jīng)不再是做一款獨立的硬件，本質(zhì)上，它就是一個產(chǎn)品，與這個時代的其它產(chǎn)品沒有區(qū)別。無論是硬件廠商，還是操作系統(tǒng)廠商，他們擁有的都是研發(fā)實力，但在產(chǎn)品上卻不是強項。而哪里擁有最多的產(chǎn)品經(jīng)理呢？現(xiàn)在的答案是互聯(lián)網(wǎng)公司。但為什么互聯(lián)網(wǎng)的產(chǎn)品經(jīng)理不來做物聯(lián)網(wǎng)呢？

不是沒有，而是很難。

曾經(jīng)有一個互聯(lián)網(wǎng)產(chǎn)品經(jīng)理看到了 IoT 的未來，決心投身這個未來，做一款改變世界的硬件產(chǎn)品。根據(jù)互聯(lián)網(wǎng)思維的做事方式，他說，我先要做一個東西先試錯，因為我也不確定對這個產(chǎn)品是否是對的。他把這個想法給了硬件工程師，硬件工程師說，我要做六個月。當時這個互聯(lián)網(wǎng)產(chǎn)品經(jīng)理就崩潰了，說我從來都有想法大概兩周試出來，你告訴我要六個月。雙方很努力的協(xié)調(diào)之后，硬件工程師按照他把初步的想法做出一個東西。臨近實現(xiàn)結(jié)束，產(chǎn)品經(jīng)理出來說，我有一個新的想法，這回輪到硬件工程師崩潰了。

? 瀑布式研發(fā)

雙方之所以會有如此大的差異，本質(zhì)上，是因為雙方在用不同的工作模式在工作。硬件研發(fā)屬于瀑布式開發(fā)，而互聯(lián)網(wǎng)產(chǎn)品研發(fā)則采用的是敏捷軟件開發(fā)，雙方對于開發(fā)節(jié)奏的理解截然不同。瀑布式要求一次性做好所有的事情，而敏捷開發(fā)則要不斷地試錯。在20年前，軟件行業(yè)的主流開發(fā)方式也是瀑布式的，但對于這個需要快速響應(yīng)變化的年代，瀑布式研發(fā)顯得越加不合時宜了。

? 重復造輪子

在硬件行業(yè)里，有一個典型的現(xiàn)象，在一個項目做好的東西很難用到另外一個項目上，比如，TCP/IP 協(xié)議棧，即便你已經(jīng)爛熟于胸，拿到一款新的硬件，往往要重來一次。對于這種現(xiàn)象，在軟件行業(yè)里，有一個常用的說法：重復造輪子。這在某種程度上是一種浪費，放在行業(yè)的角度，這種浪費現(xiàn)象更加嚴重，你在一個硬件上做的一個工作，在其它公司，會有另外的工程師做著同樣的事情，然而你不知道，沒法用。在行業(yè)中，如此大規(guī)模的浪費導致整個行業(yè)進展緩慢。

? 系統(tǒng)與應(yīng)用一體

IoT 時代需要的必然產(chǎn)品本質(zhì)上就是一個應(yīng)用，但在硬件行業(yè)里，大多數(shù)人并不能將應(yīng)用與系統(tǒng)分開，做一款硬件產(chǎn)品，往往需要從硬件到系統(tǒng)，再到上層的應(yīng)用一起做。這樣的做法帶來的后果往往是，系統(tǒng)與應(yīng)用常常混淆在一起，做過開發(fā)的人都知道，這也通常意味著代碼混雜在一起，維護的難度系數(shù)便直線上升。此外，這還有一個隱含的要求，做硬件的人要懂得從系統(tǒng)到應(yīng)用的各種知識。

今時今日，前端工程師已經(jīng) IT 行業(yè)里一個主流的職位。但你不妨同前端工程師交流一下，看有多少前端工程師知道，屏幕上顯示的點到底是怎么顯示出來的，總的來說，比例不會高，除非他自己非常有熱情的去研究這些東西。而在嵌入式領(lǐng)域，要做一個應(yīng)用必須知道各種細節(jié)，包括底層的寄存器。從某種程度上說，這是對人的要求非常非常高。

這種高要求導致嵌入式行業(yè)人才培養(yǎng)也極其困難，即便是一個計算機專業(yè)的學生，真正理解操作系統(tǒng)，理解硬件底層是怎么運作都是一件有很高難度的事情。我們看到一個很無情的現(xiàn)實是，雖然我們以為嵌入式領(lǐng)域人才已經(jīng)很多了，但是與做軟件的人比起來做嵌入式的人，數(shù)量還是太少。

2 軟硬鴻溝

換個角度，作為一個軟件的人，如果他真的有熱情，要去做硬件，他又會面臨什么樣的問題。

他會看到一大堆的新名詞：GPIO、I2C、C、時序、驅(qū)動等等，如果你是做硬件的，這些名詞或許很熟悉。但我曾經(jīng)在一些軟件技術(shù)大會上做過一些調(diào)研，嘗試用這些名詞去問過不同的人，你知不知道這個詞什么意思。這些軟件工程師普遍的表情就是見了鬼一樣。他們根本不知道我在說什么。

軟件工程師會關(guān)心的是什么呢？他們會關(guān)心：

? 需求是什么

? 用戶體驗是怎樣的

? 設(shè)計模式用什么

? 系統(tǒng)怎么架構(gòu)的

? 怎樣在高并發(fā)中保持系統(tǒng)的健壯

我們不難發(fā)現(xiàn)，這兩套語言幾乎就是兩個世界的語言，就像中國人說中文，英國人說英文，你沒有一個翻譯你根本不知道對方在說什么。雖然雙方都號稱自己從事的軟件開發(fā)，但談?wù)摰母静皇且换厥隆＿@里面存在一個巨大的鴻溝。

3 IoT 應(yīng)用研發(fā)，出路何在？

我們回過頭想想，問題到底出在哪？

通過前面的分析，軟硬雙方，一方是人數(shù)不夠多，另外一方想進又進不來，所以造成的現(xiàn)狀就是，各種硬件廠商在編寫各種各樣的硬件，所以整個 IoT 的進展速度不會太快。

亞當·斯密在《國富論》的開篇提到：勞動生產(chǎn)力上最大的改進，以及勞動時所表現(xiàn)的更多的嫻熟程度、技巧和判斷力，似乎都是分工的結(jié)果。

我們不難從前面的討論中看出，硬件廠商一個人扮演了三個角色：硬件制造、系統(tǒng)研發(fā)、應(yīng)用開發(fā)。如果能夠把三個角色分開，由不同的廠商扮演不同的角色：應(yīng)用的人把應(yīng)用寫好，平臺的人把平臺做好，做硬件的人把硬件做好。事實上，現(xiàn)在行業(yè)里已經(jīng)有人開始做這方面的嘗試了，于是，行業(yè)里就出現(xiàn)了各種 IoT 平臺。

接下來，我就以 Ruff 這個 IoT 平臺為例，介紹一下一個 IoT 平臺背后的設(shè)計理念。

4 IoT 平臺衡量標準

在討論 IoT 平臺之前，我們需要知道有哪些衡量標準來判斷一個 IoT 平臺的優(yōu)劣。下面是我提出的三個衡量標準

? 現(xiàn)代程序設(shè)計語言

? 面向應(yīng)用的抽象

? 提供生產(chǎn)支持

4.1 現(xiàn)代程序設(shè)計語言

鑒于摩爾定律的存在，在現(xiàn)代軟件開發(fā)中，開發(fā)的效率比代碼執(zhí)行的效率要重要。所以，一個好的 IoT 平臺，需要有一門現(xiàn)代的程序設(shè)計語言。

我們不妨先看看 C/C++ 這個傳統(tǒng)的嵌入式開發(fā)語言在現(xiàn)代程序設(shè)計語言所需特性上的表現(xiàn)，如表1。

表1 C/C++在現(xiàn)代程序設(shè)計語言所需特性上的表現(xiàn)

Ruff破局IoT 困境的思考

再來看看 Ruff 選擇的 JavaScript 在這些特性上的表現(xiàn)，如表2。

表2 Ruff 選擇的 JavaScript 在這些特性上的表現(xiàn)

Ruff破局IoT 困境的思考

通過對比，不難發(fā)現(xiàn)，雖然 C/C++ 依然戰(zhàn)斗力十足，但作為“現(xiàn)代程序設(shè)計語言”，它們顯得不那么“現(xiàn)代”了?；蛟S你會好奇，Ruff 為什么選擇其它的“現(xiàn)代程序設(shè)計語言”，主要有下面幾點考量。

Ruff破局IoT 困境的思考

4.2 面向應(yīng)用的抽象

什么是面向應(yīng)用的抽象？對比兩段代碼，我們便不難發(fā)現(xiàn)，這兩段代碼完成是同樣的工作，點亮一盞燈。

先是傳統(tǒng)嵌入式風格，簡單起見，我們用了 Python 代碼做示例：

GPIO.output（11， GPIO.HIGH）

再是 Ruff 的代碼，用的是 JavaScript 語言

$（‘#led’）.turnOn（）;

我們?yōu)槭裁葱枰布橄竽?？因為我們看到整個軟件開發(fā)的趨勢就是抽象度越來越高，從匯編到 C 語言，再到Java，今天還會有各種各樣的 DSL （Domain Specific Language，領(lǐng)域特定語言）。早年間，編寫代碼，我們可能會質(zhì)疑編譯器是否正確，手寫匯編效率會更高，但今天，我們肯定不會這么做，開發(fā)效率太低，因為有了抽象，底層的東西可以不斷優(yōu)化，越做越好。之所以抽象程度能不斷提升，還要拜摩爾定律所賜，硬件能力越來越強，一些執(zhí)行上的性能損失，我們是可以承受的。

那我們需要怎樣的抽象呢？從發(fā)展趨勢可以看出，抽象的趨勢一定是越來越接近問題領(lǐng)域。對于 IoT 平臺而言，一定是越來越接近于應(yīng)用開發(fā)。在 IoT 平臺的嘗試中，我們看到了幾種不同的抽象。

? 無抽象

傳統(tǒng)的嵌入式開發(fā)按照這個標準，就是無抽象的，其特點是面向硬件接口編程。

GPIO.output（11， GPIO.HIGH）

? 編程接口抽象

諸如 Ruff、Tessel、Jonny-Five、Cylon.js 等一些 IoT 平臺開始提供面向應(yīng)用的編程接口抽象，讓開發(fā)者無需關(guān)注底層的實現(xiàn)細節(jié)。

board.on（“ready”， function（） {

var led = new five.Led（13）;

led.strobe（）;

}）;

但在這里，我們不難發(fā)現(xiàn)，我們依然要對底層的接口有了解，否則，你便不知道，這段代碼中的13是做什么用的。

? 隔離硬件配置的抽象

Ruff 在提供面向應(yīng)用的編程接口抽象基礎(chǔ)上，更進了一步，將硬件配置隔離出去。在 Ruff 代碼中，我們甚至看不出硬件配置是什么樣的。

$.ready（function （error） {

$（‘#led’）.turnOn（）;

}）;

Ruff 之所以要提供隔離硬件配置的抽象，主要是為了提供生產(chǎn)支持。

4.3 提供生產(chǎn)支持

大家對于新出現(xiàn)的 IoT 平臺，普遍有一個誤解，這些平臺只能用在原型研發(fā)上，因為它們看到的是，采用 JavaScript 的硬件要求都很高，與現(xiàn)在普遍的硬件開發(fā)狀況不符?，F(xiàn)在 JavaScript 已經(jīng)可以運行在一些資源有限的系統(tǒng)上，比如 MCU，Ruff 就有自己的 MCU 版本，支持了幾款不同的 MCU。

Ruff 所做的事情更進了一步，它將硬件配置與應(yīng)用本身分離開來，這樣的做法帶來一些好處是

? 應(yīng)用開發(fā)者無需關(guān)注硬件如何配置，可以將更多的將注意力放在應(yīng)用邏輯本身

? 硬件具體的配置方式可以在具體的部署時決定

一旦硬件配置可以在部署時決定，便出現(xiàn)了另外一種可能，也就是，同一個應(yīng)用可以運行在不同的硬件上，也就是跨硬件應(yīng)用就出現(xiàn)了，這也就讓前面提及的“重復造輪子”的情況得到一定程度的緩解。

伴隨跨硬件應(yīng)用的出現(xiàn)，還會有一個額外的作用：測試。以往硬件測試一定要在硬件上完成，因為前面提及的種種原因，硬件測試往往要部署一個包括系統(tǒng)在內(nèi)的應(yīng)用，所以，效率是極低的。而我們知道，應(yīng)用開發(fā)中，大量的測試實際上是應(yīng)用邏輯的測試，屬于軟件測試的部分，理論上是可以在開發(fā)機上完成的。因為有了硬件隔離，Ruff 就提供了在開發(fā)機上做軟件測試的能力，開發(fā)的效率由此得以提升。

下面是一個 Ruff 測試代碼的例子，可以在開發(fā)機上運行：

var runner = require（‘ruff-app-runner’）;

var verify = require（‘ruff-mock’）.verify;

exports［‘test should call turn on while application is ready’］ = function（） {

runner.run（appPath， function（） {

verify（$（‘#led’））.turnOn（）;

}）;

};

require（‘test’）.run（exports）;