如何制作出最有用的demo呢？達內科技Android培訓技術專家為您提出了一些建議。

　　在demo中，我們要專注于單一的主題。我們的教學覆蓋了很大的知識范圍，因此，化整為零是非常必要的。

　　例如，我們要說明Android或iOS中的一個新特性，那只講這一個話題就好了。別跟我說你的demo能“以一敵三”――既展示Material design中最新的UI元素，又介紹RecyclerView，同時還討論RxJava的新特性。真想好好講上面這些知識的話，那你就應該為每個知識點分別寫demo。

　　共情是所有這些建議的基礎。教學的時候，我們要努力在學生的角度換位思考。我們要記得學習新知識的感覺，尤其是當新知識是以實例展現的時候。我們要記得哪些demo曾對我們有過幫助。我們還要記住，有些demo在學習中其實是起反作用的。

　　學生的水平良莠不齊。某個學生可能有10年開發經驗，但另一個可能只接觸了1年。

　　制作demo時，我們很多時候會過度低估聽眾的經驗水平，盡力做到詳盡清晰。然而，我們的目標是幫助更多有經驗的開發者從demo中獲益。

　　達內Android培訓技術專家認為：demo不可能盡善盡美。必須要“抄近路”，建立一些框架用以輔助展示你的主題。Demo和真正的應用不同；“抄近路”不失為好的選擇。每當“抄近路”或做一些不該做的事情的時候，你一定要確保跟別人講清楚自己在做什么。若不這樣做，你面臨兩個風險：

　　經驗豐富的開發者會看到你代碼不對勁，從而對你失去信任。他們會一直存有疑慮，當你開始認真展示demo的核心部分時，很難轉而讓他們信服。如果在建立提供虛擬后臺數據的模型存儲時搞不好，那你何以說服別人面對實際問題時能做好呢？你得跟那些有經驗的人說清楚，讓他們知道自己是在有意識地“抄近路”。

　　你不希望demo中不完善的方案被新手實際拿去用。新手可能會檢查你的代碼，看到它技術上運行沒問題，就直接把它移植到自己的項目中去了。我們要努力成為好的老師，確保學生不要養成任何壞習慣。

非核心部分使用原生解決方案

　　我們的大腦很擅長挑選新知識而忽略舊事物。讀代碼時尤其如此。

　　在訓練營講新話題時，我們希望與話題高度相關的代碼能夠足夠醒目。要做到這一點，一個辦法就是依靠人們最熟悉的代碼，讓所有非必要的部分“消失”。

　　例如，我們展示RxJava中的新特性，建立了一個虛擬的片段和視圖來讓結果可視化。如果我們使用額外的高級方法，例如為widget使用Butterknife注釋，那必將喧賓奪主，RxJava的相關細節無法得到突出。那些不熟悉Butterknife的人就會分散注意力，開始疑惑：“這是什么鬼？這跟Rxjava有何相關之處？”

　　我們應該堅持使用守舊卻好用的findViewById()，而不是搞一大堆無關信息出來。這樣，學生會看到findviewbyid()，認出這是個熟悉的東西，然后忽略它。他們就可以繼續往下搜尋陌生的代碼了。

　　正式的應用與demo要有不同的文檔技術和庫，它們分別面向不同的聽眾。GitHub很擅長把README.md文件格式化，從而達到更好的閱讀效果。它可以很好地展示demo的內容。通過它，我們可以高度概括地向聽眾說明我們所要展示的東西。截圖、Gif動畫和詳細的安裝說明，這些都很有價值。好好利用它們。

　　當你知道自己在找什么的時候，Javadoc是很好用的。但對于學新東西的人而言，它們不啻洪水猛獸。你要寫的文檔不是開發者日常所用API的文檔。讓文檔更通俗一點，這會好很多。

　　在正式項目中，我們可以在注釋多寡間找到一個平衡。實際中，你面臨著注釋與代碼脫節的風險，可能導致團隊重構。然而，demo項目通常很少更新，所以這倒不是個大問題。記住，你是在向別人解釋新知識。帶領學生逐行分析代碼會非常有效。

　　實際項目中，開發者在閱讀和理解代碼時有很多上下文能幫忙。對于代碼應該是什么樣，他們心中可能已經高度有數了。他們還可能聽其他同事談論過這些代碼所要解決的問題。甚至在這些代碼所依賴的設計方面，團隊可能已經取得了一致。這些項目的注釋跟我們的有完全不同的目的。它們提供簡單、高層次的指導。

　　而對于第一次看到demo項目的開發者而言，他們沒有上下文能幫助理解。無論是項目本身，還是項目中展示的技術和庫，對他們而言都是嶄新的。因此，我們有必要用大量注釋來讓邏輯和流程更加清晰。

　　達內科技Android培訓技術專家認為：有些demo只有與之互動才能充分理解，僅僅看代碼則難以咀嚼。如果你的demo是前者，一定要把它給大家實際用一下。編譯項目，把它們放在Google Play或Apple Store上，然后在你的README里將其鏈接好。因為學生不可能花時間去復制你的repo、導入到IDE、再編譯并部署到本地設備上。你應該讓大家盡量容易和快速地開始互動。