第 15 章　軟件工程與應(yīng)用調(diào)試

前面幾章中講過的Hello貓咪、打地鼠以及其他應(yīng)用都是些非常小的軟件項(xiàng)目，并不需要用引入軟件工程的概念。工程的概念借用自其他行業(yè)，意為設(shè)計(jì)并建造，教程中的應(yīng)用就像是用預(yù)制件拼裝起來的房屋模型，而軟件工程才是設(shè)計(jì)并建造真正用來居住的房子。這個(gè)例子雖然稍顯夸張，但一般來講，某些極其復(fù)雜的建造過程，的確需要大量的前期構(gòu)思、規(guī)劃以及技術(shù)分析，這些過程都可以歸結(jié)為工程。

但凡接手過一個(gè)相對復(fù)雜的項(xiàng)目，你就會(huì)理解，只要在功能上稍稍增加一點(diǎn)復(fù)雜度，軟件工程的復(fù)雜程度就會(huì)急劇增加，兩者之間絕對不是線性的關(guān)系。對于我們大多數(shù)人來說，在真正開始面對這樣殘酷的現(xiàn)實(shí)之前，我們很少能夠意識(shí)到將要面臨的困頓。從這個(gè)意義上講，你要準(zhǔn)備學(xué)習(xí)更多的軟件工程的原則及調(diào)試技巧。如果你已經(jīng)認(rèn)可這一點(diǎn)，或者，你是為數(shù)不多的、希望通過掌握一些技術(shù)來克服成長障礙的人，那么本章就是為你準(zhǔn)備的。

軟件工程原則

以下是本章所涵蓋的一些基本原則：

• 未來的軟件使用者應(yīng)該盡早，并盡可能多地參與到軟件的設(shè)計(jì)及開發(fā)過程中來；

• 建立一個(gè)初始的、簡單的原型，并逐步完善；

• 編碼與測試同步進(jìn)行，不要一次測試太多的代碼（App inventor中的塊）；

• 開始編碼前進(jìn)行邏輯設(shè)計(jì)：對功能做縱向切割，對技術(shù)或?qū)嵤┑膹?fù)雜度做分層切割，并各個(gè)擊破；

• 對代碼塊進(jìn)行注釋，以便其他人（和你自己）能理解這些程序；

• 學(xué)會(huì)用紙筆來跟蹤記錄塊的執(zhí)行過程，以便于理解它們的工作機(jī)制。

如果能夠遵循上述原則，你就可以節(jié)省時(shí)間，避免挫折，從而制作出優(yōu)秀的軟件。但你很有可能做不到每次都依原則行事！有些原則看似違背常理。一種自然的傾向是，首先有了一個(gè)想法，并假設(shè)你了解用戶的需求，然后開始把若干個(gè)塊拼在一起，直到完成了想象中的任務(wù)?，F(xiàn)在，讓我們回到軟件工程的第一個(gè)原則，在正式開始動(dòng)手之前，看看如何了解用戶的需求。

設(shè)計(jì)要面對真實(shí)的人、現(xiàn)實(shí)的問題

電影《夢幻成真》（Field of Dreams）中的男主角Ray聽到了一個(gè)聲音向他低語：“如果你建好了，他們就會(huì)來?！盧ay聽從了這個(gè)聲音，在愛荷華州的農(nóng)場中間建了一個(gè)棒球場，果然，在1919年，芝加哥白襪隊(duì)（White Sox）和成千上萬個(gè)球迷出現(xiàn)在這里。

不過你現(xiàn)在必須明白，那個(gè)低語的建議絕對不可以用于軟件開發(fā)。事實(shí)上，必須正相反。在軟件開發(fā)的歷史中，充斥著各類“沒問題”的偉大方案（如：“讓我們寫個(gè)軟件，告訴人們開車到月球需要多長時(shí)間！”）。一個(gè)優(yōu)秀的（同時(shí)也是極有可能獲利的）軟件的真正目的是解決現(xiàn)實(shí)中的問題。想知道問題出在哪里，就要找到有問題的人，并與他們交談，這就是通常被稱作“以用戶為中心”的設(shè)計(jì)方法，這個(gè)方法同樣也可以幫助你做出更好的應(yīng)用。

如果遇到程序員，你可以問他們，在他們所寫的軟件中，有多少被真正交付到了最終用戶的手中。結(jié)果會(huì)讓你感到驚訝：即使是對那些偉大的程序員來說，這個(gè)比例也還是太小了！許多軟件項(xiàng)目駛?cè)肓藛栴}的泥沼而終無見天之日。

以用戶為中心的設(shè)計(jì)理念意味著盡早并盡可能多地替未來的使用者著想，并與他們交流，這種思考與交流甚至應(yīng)該在尚未確定目標(biāo)之前就開始。大多數(shù)成功的軟件都是針對某個(gè)具體的人，試圖解決他的特定問題，也只有這樣，最終才能發(fā)展成一個(gè)偉大的產(chǎn)品。

快速地創(chuàng)建軟件原型，并展示給未來的使用者看

如果讓最終用戶閱讀軟件功能的說明文檔，他們多半不會(huì)給出任何有效的回應(yīng)，他們不會(huì)對文檔做出反饋。真正有效的方法是，讓他們體驗(yàn)未來軟件的交互模式，即軟件的原型。原型是一個(gè)不完整的、未經(jīng)重構(gòu)的軟件版本，創(chuàng)建原型的目的在于充分體現(xiàn)軟件所具有的核心價(jià)值，而不必注重細(xì)節(jié)、完整性或漂亮的用戶界面。拿出原型讓未來的使用者看，然后安靜地傾聽他們的反饋。

迭代式開發(fā)

在首次明確了軟件的具體規(guī)格之后，采用迭代式開發(fā)。你可能很自然地傾向于將所有組件和塊一股腦地添加到應(yīng)用中，然后下載到手機(jī)上看看它是否好用。舉例來說，“答題”應(yīng)用，在缺乏指導(dǎo)的情況下，多數(shù)初學(xué)者會(huì)一次性添加所有的塊：帶有一長串問題及答案的塊、瀏覽問題的塊、檢查用戶答案的塊，以及與每個(gè)邏輯細(xì)節(jié)有關(guān)的塊，所有的塊未經(jīng)測試就全部羅列在應(yīng)用中，這種開發(fā)方式在軟件工程中被稱為“大爆炸”方式。

幾乎所有的初學(xué)者都會(huì)采用這種方式。在舊金山大學(xué)（USF）的課堂上，當(dāng)學(xué)生忙于創(chuàng)建應(yīng)用時(shí)，我經(jīng)常會(huì)問他一個(gè)問題：“進(jìn)展如何？”

“我想我做完了，”他說。

“好極了，能讓我看看嗎？”

“哦，還不行，我沒帶手機(jī)來?！?/p>

“那么你還從來沒有運(yùn)行過這個(gè)程序，對嗎？”我問。

“嗯...”

我透過他的肩膀看到了30個(gè)左右色彩繽紛的塊，但他居然連一個(gè)功能都沒有測試過。

程序員們很容易著迷，他們沉湎于創(chuàng)建UI(用戶界面)并在塊編輯器中創(chuàng)建所需的行為。那些塊天衣無縫地結(jié)合在一起，優(yōu)雅地排布在屏幕上，這些讓他們感到傾心，卻忘記了創(chuàng)建一個(gè)讓其他人也能使用的、完整的、通過測試的應(yīng)用。這聽起來像是洗發(fā)水的廣告，但對于我的學(xué)生和那些有志成為程序員的人，這是我能給出的最好的建議：代碼要隨寫隨測，周而復(fù)始。

每次只寫少量代碼，并隨時(shí)測試，這個(gè)過程本身會(huì)變成一種習(xí)慣，如此這般，在不久的將來，你會(huì)收獲令人驚異且滿意的成果（而且?guī)缀醵沤^了大而難纏的程序漏洞——bug）。

先設(shè)計(jì)，后編碼

編程要分兩步走：①理解應(yīng)用的邏輯，②將這些邏輯翻譯成某種形式的編程語言。在開始翻譯之前，要在邏輯上花一些功夫：首先要明確應(yīng)用中將會(huì)發(fā)生哪些事情，無論是用戶引發(fā)的，還是應(yīng)用內(nèi)部的；其次在正式開始將邏輯翻譯成代碼塊之前，要明確每個(gè)事件處理程序中的邏輯。

有許多專門討論各種程序設(shè)計(jì)方法的書籍。有些人喜歡用流程圖或結(jié)構(gòu)圖來做設(shè)計(jì)，有些則更愿意將設(shè)計(jì)或草圖寫在紙上，更有人認(rèn)為所有的“設(shè)計(jì)”最終應(yīng)該體現(xiàn)為代碼的注釋，而不是一個(gè)與代碼分離的文檔。對于初學(xué)者來說，關(guān)鍵是要理解所有的程序在本質(zhì)上都是一套邏輯，而這種邏輯與具體的編程語言無關(guān)。當(dāng)然，思考應(yīng)用的邏輯和翻譯為編程語言這兩件事有時(shí)難免會(huì)同步進(jìn)行，無論這種編程語言是否直觀。因此，在整個(gè)邏輯思考階段，應(yīng)該遠(yuǎn)離電腦，想清楚應(yīng)用最終要實(shí)現(xiàn)哪些功能，并以某種方式隨時(shí)記錄下你的想法，然后讓設(shè)計(jì)文檔與應(yīng)用保持關(guān)聯(lián)，以便其他人也可以從中獲益。下面我們就來實(shí)踐這一過程。

對代碼進(jìn)行注釋

你已經(jīng)學(xué)過了本書中的教程部分，應(yīng)該見過塊所附帶的黃色方框（見圖15-1），這就是“注釋”。在App Inventor中，任何的塊都可以添加注釋，方法是在塊上單擊鼠標(biāo)右鍵，并在快捷菜單中選擇Add Comment。注釋絲毫不影響程序的運(yùn)行。

圖 15-1　為測試條件塊添加注釋——用簡潔的語言描述塊的作用

那么為什么要做注釋呢？想想看，如果你的應(yīng)用很成功，它的生命周期會(huì)很長，即便只是擱下一周的時(shí)間，你都有可能忘記當(dāng)時(shí)的想法，想不起來這些塊有什么用處。因此，盡管沒有別人會(huì)看到你的代碼塊，你也應(yīng)給添加這些注釋。

假如你的應(yīng)用很成功，毫無疑問它會(huì)傳到很多人手里，人們想了解它、按自己的需要修改它，或者擴(kuò)展它的功能，等等。在開源的世界里，很多項(xiàng)目會(huì)以現(xiàn)有項(xiàng)目為基礎(chǔ)，做進(jìn)一步的修改和完善，只要你親身體驗(yàn)過那些沒有代碼注釋的項(xiàng)目，你就會(huì)徹底明白為什么注釋是必需的。

為程序添加注釋并不是一種自覺地行為，我也從未見到過初學(xué)者重視它，然而，我也從未見到過一個(gè)經(jīng)驗(yàn)豐富的程序員不重視它。

切割、分層、各個(gè)擊破

當(dāng)問題的規(guī)模大到難以應(yīng)對時(shí)，解決之道在于將問題分解，分解的方法有兩種：第一種方法我們非常熟悉，即，將問題分解為若干個(gè)部分（如A、B、C），然后各個(gè)擊破；第二種則不太常見：將問題按照從簡單到復(fù)雜的順序逐層分解。對應(yīng)到App Inventor的編程方法上，就是先添加少量的塊來實(shí)現(xiàn)簡單的功能，并測試其效果，再逐漸過渡到復(fù)雜的功能，以此類推。

讓我們以第10章的“出題”應(yīng)用為例來具體闡述這兩種方法。在應(yīng)用中，用戶可以點(diǎn)擊“下一題”按鈕對問題進(jìn)行瀏覽，也可以檢查用戶的答案是否正確。從設(shè)計(jì)角度，可以將應(yīng)用分解為兩個(gè)部分：問題瀏覽及答案核對，并針對兩個(gè)部分單獨(dú)編程。

但在每個(gè)部分中，還可以對整個(gè)過程按照從簡單到復(fù)雜的順序進(jìn)行分解。例如，問題瀏覽環(huán)節(jié)，先創(chuàng)建代碼來顯示問題列表中的第一題，并測試其是否有效；然后編寫代碼來瀏覽到下一題，暫時(shí)不考慮到達(dá)最后一題時(shí)可能引起的錯(cuò)誤；當(dāng)測試結(jié)果證明可以從頭至尾瀏覽所有問題時(shí)，再添加塊來處理用戶瀏覽到最后一題的“特殊情況”。

究竟是將問題分解為幾部分，還是按照復(fù)雜性分解為若干層，這不是一個(gè)非此即彼的問題，但卻是一個(gè)值得思考的問題，關(guān)鍵在于哪種方法更適合于你所創(chuàng)建的應(yīng)用。

理解編程語言：用紙和筆跟蹤記錄

應(yīng)用在運(yùn)行過程中，僅有部分可見。最終用戶只能看到它的外觀——用戶界面上顯示的圖形及數(shù)據(jù)，而軟件的內(nèi)部運(yùn)作機(jī)制對外部世界來說是不可見的，就像人類大腦的內(nèi)部機(jī)制一樣（謝天謝地！）。應(yīng)用在運(yùn)行時(shí)，我們既看不到這些指令（塊），也看不到跟蹤當(dāng)前正在執(zhí)行的指令的程序計(jì)數(shù)器，更無法看到軟件的內(nèi)部存儲(chǔ)單元（應(yīng)用中的屬性及變量）。不過說到底，這正是我們想要的：最終用戶只能看到程序需要被顯示的部分，但對于開發(fā)者來說，在開發(fā)及測試過程中，你需要了解所有正在發(fā)生的事情。

作為一個(gè)開發(fā)者，在開發(fā)過程中所看到的代碼，都只是些靜態(tài)視圖，因此必須靠想象力來驅(qū)動(dòng)軟件的運(yùn)行：事件發(fā)生了，程序計(jì)數(shù)器移動(dòng)到下一個(gè)塊，并執(zhí)行這個(gè)塊，內(nèi)存單元中的值發(fā)生了變化，等等。

編程過程中需要在兩種不同的場景之間切換：先從靜態(tài)模式——代碼塊開始，并試著想象程序的實(shí)際運(yùn)行效果；一切就緒后，切換到測試模式——以最終用戶的身份測試軟件，看它的運(yùn)行結(jié)果是否與預(yù)期的結(jié)果相一致。如果不是，必須再切換回靜態(tài)模式，調(diào)整程序，然后再試。如此循環(huán)反復(fù)，最終獲得一個(gè)滿意的結(jié)果。

初學(xué)者對于計(jì)算機(jī)程序的運(yùn)作方式知之甚少，整個(gè)過程看起來就像魔術(shù)。依照本教程的指導(dǎo)，學(xué)習(xí)應(yīng)該從簡單的應(yīng)用開始（如，點(diǎn)擊按鈕導(dǎo)致貓叫），再逐漸過渡到較為復(fù)雜的應(yīng)用，而且隨著學(xué)習(xí)的不斷深入，或許還可以根據(jù)自己的需要，對教程中的例子做出修改。從初學(xué)者到入門者，對程序的內(nèi)部運(yùn)作機(jī)制有了一些了解，但依然感到對整個(gè)過程無法控制。他們經(jīng)常會(huì)說：“這個(gè)不起作用，”或者“它不應(yīng)該是這樣的?！标P(guān)鍵是要理解程序如何實(shí)現(xiàn)那些你主管想象出來的功能，而且要說：“我的程序正在做這件事”，以及“我的邏輯導(dǎo)致了程序的...”。

了解程序運(yùn)行機(jī)制的方法就是剖析一個(gè)簡單應(yīng)用的執(zhí)行過程，在紙上精確地描繪出每個(gè)塊在執(zhí)行時(shí)，設(shè)備的內(nèi)部發(fā)生了什么。想象用戶觸發(fā)了某個(gè)事件處理程序，然后逐步跟蹤并記錄塊的執(zhí)行效果：應(yīng)用中的變量及屬性如何改變，用戶界面上的組件如何改變。就像文學(xué)課上的“精讀”環(huán)節(jié)，這樣一步一步的跟蹤可以促使你檢查語言中的各個(gè)要素（即App Inventor中的塊）。

對復(fù)雜性的描述幾乎是完全抽象的，重要的是你要放慢思路，理清各個(gè)塊之間的因果關(guān)系。最終你會(huì)明白，這些過程控制的規(guī)則，并不像最初想象的那樣難以理解。

以第8章總統(tǒng)測驗(yàn)為例，如圖15-2所示，思考圖中的這些塊（對原教程做了一點(diǎn)修改）。

圖 15-2　應(yīng)用啟動(dòng)時(shí)，將QuestionLabel的Text屬性設(shè)置為QuestionList列表的第一項(xiàng)

你能理解這些代碼嗎？你能跟蹤這些代碼，并說明每一步都發(fā)生了什么嗎？

首先跟蹤所有相關(guān)的變量及屬性。畫出存儲(chǔ)單元的表格，這個(gè)例子中，表頭分別為currentQuestionIndex和QuestionLabel.Text，如表15-1。

表15-1 記錄text屬性及index值變化的表格

接下來，思考當(dāng)應(yīng)用啟動(dòng)時(shí)，發(fā)生了哪些事——不要以用戶的視角來看，而是從應(yīng)用的內(nèi)部來分析它的初始化過程。如果你學(xué)過這些教程，你可能知道這個(gè)過程，但你可能沒有從機(jī)制方面去思考過。當(dāng)應(yīng)用啟動(dòng)時(shí)：

1. 完成了所有組件的屬性設(shè)定，它們的值等于在組件設(shè)計(jì)器中設(shè)定的初始值；

2. 完成了所有變量的定義及初始化；

3. 執(zhí)行了Screen.Initialize事件處理程序中的所有塊。

對程序進(jìn)行跟蹤有助于理解程序的運(yùn)行機(jī)制，那么在完成了應(yīng)用的初始化之后，表格中應(yīng)該填寫什么內(nèi)容呢？

如表15-2所示，currentQuestionIndex的值為1，因?yàn)閼?yīng)用啟動(dòng)時(shí)完成了變量的定義，并將其初始值設(shè)為1；而QuestionLabel.Text的值為第一題，因?yàn)樵赟creen.Initialize中選擇了QuestionList列表中的第一項(xiàng)，并放入了QuestionLabel中。

表15-2 總統(tǒng)測驗(yàn)應(yīng)用初始化后，QuestionLabel.Text與currentQuestionIndex的值

下面再來跟蹤用戶點(diǎn)擊“下一題”按鈕時(shí)發(fā)生的事情。

圖 15-3　用戶點(diǎn)擊“下一題”按鈕時(shí)執(zhí)行的塊

逐個(gè)檢查每個(gè)塊。首先是變量currentQuestionIndex的遞增，說得更具體一些，變量當(dāng)前值是1，經(jīng)過+1的運(yùn)算后，將結(jié)果2再賦給變量currentQuestionIndex。接下來看if語句，列表QuestionList的長度為3，顯然currentQuestionIndex的值2小于3，因此if語句的結(jié)果是false（假），于是列表中的第2項(xiàng)（第二題）被寫入QuestionLabel.Text中，如表15-3所示。

表15-3 點(diǎn)擊“下一題”按鈕后的變量及屬性值

跟蹤“下一題”按鈕的第二次點(diǎn)擊?，F(xiàn)在currentQuestionIndex已經(jīng)遞增到3，會(huì)發(fā)生什么呢？繼續(xù)閱讀之前，細(xì)心地檢查一下，看你能否跟蹤正確。

在if測試中，currentQuestionIndex的值（3）的確≥列表QuestionList的長度（3），于是currentQuestionIndex的值被設(shè)為1，第一題被寫入label，如表15-4所示。

表15-4 “下一題”按鈕被第二次點(diǎn)擊時(shí)的值

我們的跟蹤揭露了一個(gè)錯(cuò)誤：最后一題永遠(yuǎn)也無法顯示！

通過類似的跟蹤，最終使你成為一名程序員、工程師。你開始從機(jī)制上去理解編程語言，掌握代碼中的語句和詞匯，而不是對一些片段的模糊理解。誠然，編程語言是復(fù)雜的，但機(jī)器對每個(gè)“詞”都有明確而且簡單的解釋，如果理解了塊與變量或?qū)傩宰兓g的對應(yīng)關(guān)系，也就理解了如何編寫或修復(fù)你的應(yīng)用，當(dāng)然也就實(shí)現(xiàn)了對應(yīng)用的完全控制。

現(xiàn)在如果你告訴朋友們，“我正在學(xué)習(xí)如何讓用戶點(diǎn)擊‘下一題’按鈕來看到下一道題，這實(shí)在是太難了！”他們會(huì)以為你瘋了。但這個(gè)過程的確很困難，困難不在于概念的復(fù)雜性，而在于你不得不有意讓自己的腦子慢下來，來搞清楚計(jì)算機(jī)的每一步處理過程，包括那些你的大腦下意識(shí)完成的過程。

應(yīng)用的調(diào)試

逐步跟蹤不僅是理解編程的方法，同樣在調(diào)試有問題的應(yīng)用時(shí)，也是一個(gè)屢試不爽的方法。

像App Inventor這樣的開發(fā)工具（通常被成為交互式開發(fā)環(huán)境，或IDEs-Interactive Development Environments）一般會(huì)提供了一種調(diào)試工具，相當(dāng)于紙筆跟蹤記錄的高科技版本，能夠自動(dòng)完成某些跟蹤過程，這極大地改善了應(yīng)用開發(fā)的進(jìn)程。這些工具提供了一個(gè)描述正在運(yùn)行的應(yīng)用的視圖，程序員可以在其中：

• 在任何一點(diǎn)暫停應(yīng)用來檢查其中的各個(gè)變量及屬性；

• 單獨(dú)執(zhí)行某些指令（塊）來檢查它們的執(zhí)行效果。

監(jiān)視變量

說明：監(jiān)視變量是AI1（App Inventor version1.0）中的功能，目前尚未在AI2中實(shí)現(xiàn)。

單獨(dú)測試塊

除了可以用監(jiān)視功能來檢查應(yīng)用運(yùn)行過程中變量及屬性的變化，還有另一個(gè)工具“Do It”，可以讓你脫離開程序通常的運(yùn)行順序，單獨(dú)測試某些塊的運(yùn)行。右鍵點(diǎn)擊一個(gè)塊，在快捷菜單中選擇“Do It”，這個(gè)塊就會(huì)開始執(zhí)行，如果這個(gè)塊是一個(gè)有返回值的表達(dá)式，App Inventor將在塊的上方的方框內(nèi)（在注釋塊中插入兩行）顯示返回值。如圖15-4及15-5。

圖 15-4　右鍵點(diǎn)擊事件處理程序中的任何一個(gè)塊，會(huì)彈出快捷菜單

圖 15-5　在快捷菜單中選擇“Do It”，可以執(zhí)行該塊，并查看返回值（如果有）

“Do It”在調(diào)試塊的邏輯錯(cuò)誤時(shí)非常有用。還是回到“總統(tǒng)測試”例子中的NextButton.Click事件處理程序，并假設(shè)程序中存在邏輯錯(cuò)誤，無法瀏覽所有的問題。調(diào)試過程需要在開發(fā)環(huán)境及測試設(shè)備上同時(shí)進(jìn)行。在用戶界面上點(diǎn)擊“下一題”按鈕，然后回到塊編輯器查看是否每次點(diǎn)擊都顯示了適當(dāng)?shù)膯栴}。也可以監(jiān)視變量index在每次點(diǎn)擊時(shí)的變化。

但是這類測試只允許檢查整個(gè)事件處理程序的執(zhí)行效果，在運(yùn)行完所有的塊之前，你無法檢查你要監(jiān)視的變量或用戶界面。（抓不到逐句的中間狀態(tài)）

“Do It”允許你減緩測試過程，并檢查任何一個(gè)塊執(zhí)行完成后的整個(gè)應(yīng)用的狀態(tài)。一般是從用戶界面上的事件開始跟蹤，直到發(fā)現(xiàn)問題所在。在發(fā)現(xiàn)無法顯示最后一題之后，你可能在用戶界面上點(diǎn)擊“下一題”一次轉(zhuǎn)到第二題，然后不再繼續(xù)點(diǎn)擊“下一題”，而是在塊編輯器中讓整個(gè)事件處理程序一步一步地運(yùn)行。在NextButton.Click事件處理程序中，每次對一個(gè)塊使用“Do It”讓塊執(zhí)行，如圖15-6中，先右鍵點(diǎn)擊第一行的塊（讓變量index遞增），并選擇“Do It”。

圖 15-6　使用“DoIt”工具，每次只執(zhí)行一個(gè)塊

此時(shí)index的值變?yōu)?，應(yīng)用停止執(zhí)行——“Do It”只能使被選中的塊以及它所包含的子塊運(yùn)行，這可以讓測試者檢查被監(jiān)視變量以及用戶界面的變化。接下來，選擇下一行要測試的塊（if測試）并選擇“Do It”來執(zhí)行該行，其中的每一步都能看到每個(gè)塊的執(zhí)行效果。

使用“Do It”漸進(jìn)式開發(fā)

有一點(diǎn)需要強(qiáng)調(diào)，這種逐行執(zhí)行指令的方式不僅僅適用于程序的調(diào)試，它同樣適用于開發(fā)過程中的隨時(shí)測試。例如，如果你寫了一個(gè)很長的公式來計(jì)算兩個(gè)GPS坐標(biāo)之間的距離，你可能要分步測試這個(gè)公式，來驗(yàn)證這些塊的使用是否正確。

啟用與禁用塊

另一個(gè)有助于漸進(jìn)式調(diào)試應(yīng)用的方法是啟用或禁用某些塊，它允許應(yīng)用中保留有問題的或未經(jīng)測試的塊，并讓系統(tǒng)在運(yùn)行過程中暫時(shí)忽略它們，然后充分調(diào)試那些啟用狀態(tài)的塊，而不必?fù)?dān)心那些有問題的部分。禁用塊很簡單，在塊上點(diǎn)右鍵，在快捷菜單中選擇Disable Block即可，被禁用的塊呈現(xiàn)為灰色，在應(yīng)用運(yùn)行時(shí)，這些塊被忽略；需要時(shí)，還可以重新啟用這些塊，方法是在塊上點(diǎn)擊右鍵并選擇Enable Block。

小結(jié)

App Inventor的偉大之處在于它的易用性——可視化的特點(diǎn)讓你可以直接開始一個(gè)應(yīng)用，而不必?fù)?dān)心那些低層的細(xì)節(jié)。但現(xiàn)實(shí)的問題是，App Inventor不可能知道你的應(yīng)用要做什么，更不知道如何來做。盡管直接進(jìn)入組件設(shè)計(jì)器與塊編輯器創(chuàng)建應(yīng)用是件讓人著迷的事情，但這里要強(qiáng)調(diào)的是，花一些時(shí)間來思考并詳細(xì)、準(zhǔn)確地設(shè)計(jì)應(yīng)用的功能，是非常重要的。這聽起來有些煩，但如果你能聽取用戶的想法、創(chuàng)建原型、測試并跟蹤應(yīng)用的邏輯，那么創(chuàng)建出精彩應(yīng)用的目標(biāo)指日可待。