電子發(fā)燒友App
IoT 時(shí)代可以說(shuō)是互聯(lián)網(wǎng)的下一代，將更多的物和設(shè)備連接起來(lái)。IoT 時(shí)代硬件，已經(jīng)不再是做一款獨(dú)立的硬件，IoT 研發(fā)已經(jīng)進(jìn)入困境，為此Ruff 進(jìn)行了一次破局 IoT 研發(fā)困境的嘗試。
提及 IoT（物聯(lián)網(wǎng)，Internet of Things），幾乎整個(gè) IT 行業(yè)的共識(shí)是未來(lái)一定會(huì)是一個(gè) IoT 時(shí)代，繼互聯(lián)網(wǎng)時(shí)代將更多的人連接到一起之后，IoT 時(shí)代將會(huì)把更多的物（Thing）連接起來(lái)。但是，一說(shuō)到 IoT 的研發(fā)，人們的第一反應(yīng)通常是，物就是硬件，做硬件就要懂嵌入式，所以，IoT 開(kāi)發(fā)就是嵌入式開(kāi)發(fā)。于是，我們看到在 IoT 的指引下，各大硬件廠商和嵌入式操作系統(tǒng)廠商搖旗吶喊，紛紛暢想著 IoT 的未來(lái)，而現(xiàn)在的 IoT 行業(yè)狀態(tài)卻是，只問(wèn)腳步聲，未見(jiàn)人下來(lái)。為什么會(huì)這樣？我們不妨簡(jiǎn)要分析一下。
1 IoT 研發(fā)困境
? 產(chǎn)品經(jīng)理與硬件工程師難以協(xié)同
在 IoT 時(shí)代，做一個(gè)硬件，已經(jīng)不再是做一款獨(dú)立的硬件，本質(zhì)上，它就是一個(gè)產(chǎn)品，與這個(gè)時(shí)代的其它產(chǎn)品沒(méi)有區(qū)別。無(wú)論是硬件廠商，還是操作系統(tǒng)廠商，他們擁有的都是研發(fā)實(shí)力，但在產(chǎn)品上卻不是強(qiáng)項(xiàng)。而哪里擁有最多的產(chǎn)品經(jīng)理呢？現(xiàn)在的答案是互聯(lián)網(wǎng)公司。但為什么互聯(lián)網(wǎng)的產(chǎn)品經(jīng)理不來(lái)做物聯(lián)網(wǎng)呢？
不是沒(méi)有，而是很難。
曾經(jīng)有一個(gè)互聯(lián)網(wǎng)產(chǎn)品經(jīng)理看到了 IoT 的未來(lái)，決心投身這個(gè)未來(lái)，做一款改變世界的硬件產(chǎn)品。根據(jù)互聯(lián)網(wǎng)思維的做事方式，他說(shuō)，我先要做一個(gè)東西先試錯(cuò)，因?yàn)槲乙膊淮_定對(duì)這個(gè)產(chǎn)品是否是對(duì)的。他把這個(gè)想法給了硬件工程師，硬件工程師說(shuō)，我要做六個(gè)月。當(dāng)時(shí)這個(gè)互聯(lián)網(wǎng)產(chǎn)品經(jīng)理就崩潰了，說(shuō)我從來(lái)都有想法大概兩周試出來(lái)，你告訴我要六個(gè)月。雙方很努力的協(xié)調(diào)之后，硬件工程師按照他把初步的想法做出一個(gè)東西。臨近實(shí)現(xiàn)結(jié)束，產(chǎn)品經(jīng)理出來(lái)說(shuō)，我有一個(gè)新的想法，這回輪到硬件工程師崩潰了。
? 瀑布式研發(fā)
雙方之所以會(huì)有如此大的差異，本質(zhì)上，是因?yàn)殡p方在用不同的工作模式在工作。硬件研發(fā)屬于瀑布式開(kāi)發(fā)，而互聯(lián)網(wǎng)產(chǎn)品研發(fā)則采用的是敏捷軟件開(kāi)發(fā)，雙方對(duì)于開(kāi)發(fā)節(jié)奏的理解截然不同。瀑布式要求一次性做好所有的事情，而敏捷開(kāi)發(fā)則要不斷地試錯(cuò)。在20年前，軟件行業(yè)的主流開(kāi)發(fā)方式也是瀑布式的，但對(duì)于這個(gè)需要快速響應(yīng)變化的年代，瀑布式研發(fā)顯得越加不合時(shí)宜了。
? 重復(fù)造輪子
在硬件行業(yè)里，有一個(gè)典型的現(xiàn)象，在一個(gè)項(xiàng)目做好的東西很難用到另外一個(gè)項(xiàng)目上，比如，TCP/IP 協(xié)議棧，即便你已經(jīng)爛熟于胸，拿到一款新的硬件，往往要重來(lái)一次。對(duì)于這種現(xiàn)象，在軟件行業(yè)里，有一個(gè)常用的說(shuō)法：重復(fù)造輪子。這在某種程度上是一種浪費(fèi)，放在行業(yè)的角度，這種浪費(fèi)現(xiàn)象更加嚴(yán)重，你在一個(gè)硬件上做的一個(gè)工作，在其它公司，會(huì)有另外的工程師做著同樣的事情，然而你不知道，沒(méi)法用。在行業(yè)中，如此大規(guī)模的浪費(fèi)導(dǎo)致整個(gè)行業(yè)進(jìn)展緩慢。
? 系統(tǒng)與應(yīng)用一體
IoT 時(shí)代需要的必然產(chǎn)品本質(zhì)上就是一個(gè)應(yīng)用，但在硬件行業(yè)里，大多數(shù)人并不能將應(yīng)用與系統(tǒng)分開(kāi)，做一款硬件產(chǎn)品，往往需要從硬件到系統(tǒng)，再到上層的應(yīng)用一起做。這樣的做法帶來(lái)的后果往往是，系統(tǒng)與應(yīng)用常?；煜谝黄?，做過(guò)開(kāi)發(fā)的人都知道，這也通常意味著代碼混雜在一起，維護(hù)的難度系數(shù)便直線上升。此外，這還有一個(gè)隱含的要求，做硬件的人要懂得從系統(tǒng)到應(yīng)用的各種知識(shí)。
今時(shí)今日，前端工程師已經(jīng) IT 行業(yè)里一個(gè)主流的職位。但你不妨同前端工程師交流一下，看有多少前端工程師知道，屏幕上顯示的點(diǎn)到底是怎么顯示出來(lái)的，總的來(lái)說(shuō)，比例不會(huì)高，除非他自己非常有熱情的去研究這些東西。而在嵌入式領(lǐng)域，要做一個(gè)應(yīng)用必須知道各種細(xì)節(jié)，包括底層的寄存器。從某種程度上說(shuō)，這是對(duì)人的要求非常非常高。
這種高要求導(dǎo)致嵌入式行業(yè)人才培養(yǎng)也極其困難，即便是一個(gè)計(jì)算機(jī)專業(yè)的學(xué)生，真正理解操作系統(tǒng)，理解硬件底層是怎么運(yùn)作都是一件有很高難度的事情。我們看到一個(gè)很無(wú)情的現(xiàn)實(shí)是，雖然我們以為嵌入式領(lǐng)域人才已經(jīng)很多了，但是與做軟件的人比起來(lái)做嵌入式的人，數(shù)量還是太少。
2 軟硬鴻溝
換個(gè)角度，作為一個(gè)軟件的人，如果他真的有熱情，要去做硬件，他又會(huì)面臨什么樣的問(wèn)題。
他會(huì)看到一大堆的新名詞：GPIO、I2C、C、時(shí)序、驅(qū)動(dòng)等等，如果你是做硬件的，這些名詞或許很熟悉。但我曾經(jīng)在一些軟件技術(shù)大會(huì)上做過(guò)一些調(diào)研，嘗試用這些名詞去問(wèn)過(guò)不同的人，你知不知道這個(gè)詞什么意思。這些軟件工程師普遍的表情就是見(jiàn)了鬼一樣。他們根本不知道我在說(shuō)什么。
軟件工程師會(huì)關(guān)心的是什么呢？他們會(huì)關(guān)心：
? 需求是什么
? 用戶體驗(yàn)是怎樣的
? 設(shè)計(jì)模式用什么
? 系統(tǒng)怎么架構(gòu)的
? 怎樣在高并發(fā)中保持系統(tǒng)的健壯
我們不難發(fā)現(xiàn)，這兩套語(yǔ)言幾乎就是兩個(gè)世界的語(yǔ)言，就像中國(guó)人說(shuō)中文，英國(guó)人說(shuō)英文，你沒(méi)有一個(gè)翻譯你根本不知道對(duì)方在說(shuō)什么。雖然雙方都號(hào)稱自己從事的軟件開(kāi)發(fā)，但談?wù)摰母静皇且换厥隆＿@里面存在一個(gè)巨大的鴻溝。
3 IoT 應(yīng)用研發(fā)，出路何在？
我們回過(guò)頭想想，問(wèn)題到底出在哪？
通過(guò)前面的分析，軟硬雙方，一方是人數(shù)不夠多，另外一方想進(jìn)又進(jìn)不來(lái)，所以造成的現(xiàn)狀就是，各種硬件廠商在編寫各種各樣的硬件，所以整個(gè) IoT 的進(jìn)展速度不會(huì)太快。
亞當(dāng)·斯密在《國(guó)富論》的開(kāi)篇提到：勞動(dòng)生產(chǎn)力上最大的改進(jìn)，以及勞動(dòng)時(shí)所表現(xiàn)的更多的嫻熟程度、技巧和判斷力，似乎都是分工的結(jié)果。
我們不難從前面的討論中看出，硬件廠商一個(gè)人扮演了三個(gè)角色：硬件制造、系統(tǒng)研發(fā)、應(yīng)用開(kāi)發(fā)。如果能夠把三個(gè)角色分開(kāi)，由不同的廠商扮演不同的角色：應(yīng)用的人把應(yīng)用寫好，平臺(tái)的人把平臺(tái)做好，做硬件的人把硬件做好。事實(shí)上，現(xiàn)在行業(yè)里已經(jīng)有人開(kāi)始做這方面的嘗試了，于是，行業(yè)里就出現(xiàn)了各種 IoT 平臺(tái)。
接下來(lái)，我就以 Ruff 這個(gè) IoT 平臺(tái)為例，介紹一下一個(gè) IoT 平臺(tái)背后的設(shè)計(jì)理念。
4 IoT 平臺(tái)衡量標(biāo)準(zhǔn)
在討論 IoT 平臺(tái)之前，我們需要知道有哪些衡量標(biāo)準(zhǔn)來(lái)判斷一個(gè) IoT 平臺(tái)的優(yōu)劣。下面是我提出的三個(gè)衡量標(biāo)準(zhǔn)
? 現(xiàn)代程序設(shè)計(jì)語(yǔ)言
? 面向應(yīng)用的抽象
? 提供生產(chǎn)支持
4.1 現(xiàn)代程序設(shè)計(jì)語(yǔ)言
鑒于摩爾定律的存在，在現(xiàn)代軟件開(kāi)發(fā)中，開(kāi)發(fā)的效率比代碼執(zhí)行的效率要重要。所以，一個(gè)好的 IoT 平臺(tái)，需要有一門現(xiàn)代的程序設(shè)計(jì)語(yǔ)言。
我們不妨先看看 C/C++ 這個(gè)傳統(tǒng)的嵌入式開(kāi)發(fā)語(yǔ)言在現(xiàn)代程序設(shè)計(jì)語(yǔ)言所需特性上的表現(xiàn)，如表1。
表1 C/C++在現(xiàn)代程序設(shè)計(jì)語(yǔ)言所需特性上的表現(xiàn)
再來(lái)看看 Ruff 選擇的 JavaScript 在這些特性上的表現(xiàn)，如表2。
表2 Ruff 選擇的 JavaScript 在這些特性上的表現(xiàn)
通過(guò)對(duì)比，不難發(fā)現(xiàn)，雖然 C/C++ 依然戰(zhàn)斗力十足，但作為“現(xiàn)代程序設(shè)計(jì)語(yǔ)言”，它們顯得不那么“現(xiàn)代”了。或許你會(huì)好奇，Ruff 為什么選擇其它的“現(xiàn)代程序設(shè)計(jì)語(yǔ)言”，主要有下面幾點(diǎn)考量。
4.2 面向應(yīng)用的抽象
什么是面向應(yīng)用的抽象？對(duì)比兩段代碼，我們便不難發(fā)現(xiàn)，這兩段代碼完成是同樣的工作，點(diǎn)亮一盞燈。
先是傳統(tǒng)嵌入式風(fēng)格，簡(jiǎn)單起見(jiàn)，我們用了 Python 代碼做示例：
GPIO.output（11， GPIO.HIGH）
再是 Ruff 的代碼，用的是 JavaScript 語(yǔ)言
$（‘#led’）.turnOn（）;
我們?yōu)槭裁葱枰布橄竽?？因?yàn)槲覀兛吹秸麄€(gè)軟件開(kāi)發(fā)的趨勢(shì)就是抽象度越來(lái)越高，從匯編到 C 語(yǔ)言，再到Java，今天還會(huì)有各種各樣的 DSL （Domain Specific Language，領(lǐng)域特定語(yǔ)言）。早年間，編寫代碼，我們可能會(huì)質(zhì)疑編譯器是否正確，手寫匯編效率會(huì)更高，但今天，我們肯定不會(huì)這么做，開(kāi)發(fā)效率太低，因?yàn)橛辛顺橄?，底層的東西可以不斷優(yōu)化，越做越好。之所以抽象程度能不斷提升，還要拜摩爾定律所賜，硬件能力越來(lái)越強(qiáng)，一些執(zhí)行上的性能損失，我們是可以承受的。
那我們需要怎樣的抽象呢？從發(fā)展趨勢(shì)可以看出，抽象的趨勢(shì)一定是越來(lái)越接近問(wèn)題領(lǐng)域。對(duì)于 IoT 平臺(tái)而言，一定是越來(lái)越接近于應(yīng)用開(kāi)發(fā)。在 IoT 平臺(tái)的嘗試中，我們看到了幾種不同的抽象。
? 無(wú)抽象
傳統(tǒng)的嵌入式開(kāi)發(fā)按照這個(gè)標(biāo)準(zhǔn)，就是無(wú)抽象的，其特點(diǎn)是面向硬件接口編程。
GPIO.output（11， GPIO.HIGH）
? 編程接口抽象
諸如 Ruff、Tessel、Jonny-Five、Cylon.js 等一些 IoT 平臺(tái)開(kāi)始提供面向應(yīng)用的編程接口抽象，讓開(kāi)發(fā)者無(wú)需關(guān)注底層的實(shí)現(xiàn)細(xì)節(jié)。
board.on（“ready”， function（） {
var led = new five.Led（13）;
led.strobe（）;
}）;
但在這里，我們不難發(fā)現(xiàn)，我們依然要對(duì)底層的接口有了解，否則，你便不知道，這段代碼中的13是做什么用的。
? 隔離硬件配置的抽象
Ruff 在提供面向應(yīng)用的編程接口抽象基礎(chǔ)上，更進(jìn)了一步，將硬件配置隔離出去。在 Ruff 代碼中，我們甚至看不出硬件配置是什么樣的。
$.ready（function （error） {
$（‘#led’）.turnOn（）;
}）;
Ruff 之所以要提供隔離硬件配置的抽象，主要是為了提供生產(chǎn)支持。
4.3 提供生產(chǎn)支持
大家對(duì)于新出現(xiàn)的 IoT 平臺(tái)，普遍有一個(gè)誤解，這些平臺(tái)只能用在原型研發(fā)上，因?yàn)樗鼈兛吹降氖?，采?JavaScript 的硬件要求都很高，與現(xiàn)在普遍的硬件開(kāi)發(fā)狀況不符?，F(xiàn)在 JavaScript 已經(jīng)可以運(yùn)行在一些資源有限的系統(tǒng)上，比如 MCU，Ruff 就有自己的 MCU 版本，支持了幾款不同的 MCU。
Ruff 所做的事情更進(jìn)了一步，它將硬件配置與應(yīng)用本身分離開(kāi)來(lái)，這樣的做法帶來(lái)一些好處是
? 應(yīng)用開(kāi)發(fā)者無(wú)需關(guān)注硬件如何配置，可以將更多的將注意力放在應(yīng)用邏輯本身
? 硬件具體的配置方式可以在具體的部署時(shí)決定
一旦硬件配置可以在部署時(shí)決定，便出現(xiàn)了另外一種可能，也就是，同一個(gè)應(yīng)用可以運(yùn)行在不同的硬件上，也就是跨硬件應(yīng)用就出現(xiàn)了，這也就讓前面提及的“重復(fù)造輪子”的情況得到一定程度的緩解。
伴隨跨硬件應(yīng)用的出現(xiàn)，還會(huì)有一個(gè)額外的作用：測(cè)試。以往硬件測(cè)試一定要在硬件上完成，因?yàn)榍懊嫣峒暗姆N種原因，硬件測(cè)試往往要部署一個(gè)包括系統(tǒng)在內(nèi)的應(yīng)用，所以，效率是極低的。而我們知道，應(yīng)用開(kāi)發(fā)中，大量的測(cè)試實(shí)際上是應(yīng)用邏輯的測(cè)試，屬于軟件測(cè)試的部分，理論上是可以在開(kāi)發(fā)機(jī)上完成的。因?yàn)橛辛擞布綦x，Ruff 就提供了在開(kāi)發(fā)機(jī)上做軟件測(cè)試的能力，開(kāi)發(fā)的效率由此得以提升。
下面是一個(gè) Ruff 測(cè)試代碼的例子，可以在開(kāi)發(fā)機(jī)上運(yùn)行：
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）;
5 結(jié)論
我們總結(jié)一下 Ruff 在 IoT 平臺(tái)衡量標(biāo)準(zhǔn)上的一些做法，如表3。
表3 Ruff 在 IoT 平臺(tái)衡量標(biāo)準(zhǔn)上的一些做法
基于這些做法，采用 Ruff 平臺(tái)的應(yīng)用開(kāi)發(fā)，將會(huì)看到在一些模式上出現(xiàn)的轉(zhuǎn)變，如表4。
表4 采用Ruff 平臺(tái)的應(yīng)用開(kāi)發(fā)，在一些模式上的轉(zhuǎn)變
以上就是 Ruff 在破局 IoT 困境上的一些思考和嘗試，歡迎讀者能夠給出自己在這個(gè)方面的見(jiàn)解，讓我們一起推動(dòng) IoT 時(shí)代早日到來(lái)。
工商網(wǎng)監(jiān)
評(píng)論