關於VBA教學方式的解答

剛剛有一位知友在我的一個回答中提出問題:「楊洋老師 我聽了您的入門課程,想談一點自己的看法,概念性的東西介紹的確實太少了,課下的作業我都是照貓畫虎去做的,但是自己不是很理解,或者說換一個作業可能我就不會做了。」

對這個問題,我認真撰寫了兩千字的回復,但點下發布按鈕之後,知乎只彈出一句「評論發布失敗」,就什麼也沒有留下。想來知乎對評論的長度可能有所限制,所以我只好單獨開一個文章與感興趣的同學討論一下這個問題。下面就是我的一點理解:

==================正文分界線========================================

非常感謝你的反饋 :-) 關於怎樣的教學方式更加合適,確實是一個很有趣的問題。先聊一個我自己的教學經歷:根據同濟的要求,評定職稱時必須由兩位資深教授到申請者的教室隨機聽課,然後做教學能力評分。不過我評職稱時卻享受了一次高級待遇:學校先後指派了三個專家來聽課。事後了解到,第一位專家給了我70分,第二位專家給了100分。由於這麼顯著的差異很少出現,所以師資管理部門只能安排評定組組長出馬第三次聽課。我運氣不錯,第三位專家也給了100分,而且據說附上了一個很長的個人意見說明。

nn

這裡我想表達的就是:每個人都有自己的學習方式和偏好,相應的,對於每一個同學,自然都有不同的最佳教學方式。在我教過的同學中,有的人偏好紮實沉穩的方式,善於從抽象嚴謹的定義中逐字理解、最終逐步推演到實踐問題,因此能夠非常有耐心的從序言一行行讀到附錄,認真理解每一個概念中的每一個關鍵字;也有的人偏好快速實踐的學習方式,喜歡先半懂不懂做出一個東西,然後圍繞它的每個細節去逐個「領悟」共性與特性,並且下意識的在自己心中勾畫出某些概念框架,最後再去閱讀或「重讀」經典定義。當然,這也與所學課程有關,往往理論性較強的課程會更傾向於前一種學習方式,而應用性較強的課程會傾向於後一種。

nn

在大學課堂里,我們可以隨時與同學溝通互動,從而根據每個同學的背景、興趣和特徵來組織語言與講解方式,即所謂「因材施教」。不過網路視頻課程的問題在於,我們無法知道每個同學的情況,也無法針對不同類型的同學錄製不同形式的課程,更無法在講解的同時觀察聽眾的表情、從而在語速、案例乃至教學模式上做出任何調整。所以我們唯一能做的,就是選擇一個對多數人適合的教學方法。而根據我們十幾年的教學經驗,無論在東北財經這樣的專業性院校、同濟這樣的綜合性院校,還是各類社會IT培訓機構里,絕大多數初學程序設計的同學,都更加偏好後面一種,也就是「提出問題——快速解決——反思細節——總結規律」這樣一種教學模式。我這麼說不是主觀判斷,因為各種教育機構每個學期都會組織同學進行匿名教學打分和評價,並統一反饋給任課教師。我所有的課程都是9.9或10分,所以個人對這個結論比較有信心。

nn

不過具體到《全民一起VBA》這門課程上,還有另外一點需要說明。那就是聽眾並沒有想深入理解計算機科學,只是想通過學習編程來解決辦公室/實驗室裡面的手邊數據處理。對於這一類型的編程初學者,必須掌握的概念本來就非常少,而重點在於,怎樣真正的理解這些基礎概念,並對應到實際代碼問題中。以《基礎篇》第3、4節介紹的「變數」概念為例,我隨手在網上copy了一個概念(聽說在某乎上引用某度屬於政治不正確,所以我只好找來了wiki,可惜沒有簡體版):

在程序設計中,變數(英語:Variable,scalar)是指一個包含部分已知或未知數值或信息(即一個值)之儲存地址,以及相對應之符號名稱(標識符)。通常使用變數名稱參照儲存值;將名稱和內容分開能讓被使用的名稱獨立於所表示的精確訊息之外。計算機原始碼中的標識符能在執行期間綁紮一個值,且該變數的值可能在程序執行期間改變。

nn

上面這個概念任何人都可以在一分鐘內讀完,但是很少有人能夠通過逐字理解這個概念來徹底理解變數、更少有人願意學習一門充滿這種文字的課程(自我表揚一下,我覺得我自己屬於能做到這一點的,不過說實話並不很情願)。而我們在《全民一起VBAn基礎篇》中,先是把上面的概念貼出來,然後迅速跳轉到一段動畫,借用「喜羊羊」和「大富翁」的背景,用土地開發解釋了變數。雖然這些解釋並不嚴謹,但是對於連內存都了解不多的初學者,足以使大家在短時間內領悟很多變數內存管理問題,並且同時對應到各種VBA代碼問題上。而在後面《全民一起VBA 提高篇》深入講解數據類型時,我們繼續沿用這一動畫框架,並隨著每節課的深入,對其進行修訂完善、補充新的動畫元素進來,使變數的本質愈加清晰。從一年來一萬多名同學的反饋看,絕大多數同學還是很喜歡這個模式的。

說到「嚴謹性」,我個人認為對於大多數初學者,最好還是採取「先理解、後嚴謹」的策略。比如有時候我們在闡釋某些概念或規則時,會選擇一些看上去與計算機無關、但是更貼近受眾的生活經歷、因而更容易引起共鳴的事物來做類比。這樣的好處是可以使同學首先抓住並領會這個概念的核心意義和宗旨,在此基礎上,我們再對各個相關細節進行明確的定義,就更容易被接受了。比如下面也是《基礎篇》講「變數」時的一個截屏,嘗試告訴大家變數命名不能使用特殊符號。很多同學反饋說這個畫面確實讓他們印象更加深刻:

關於你提到的「課後作業」的問題,我覺得重點不是因為「概念」,而是在於「程序設計思維」的養成。這是所有編程初學者都會遇到的問題,是必須邁過去的一個坎,而解決方式也只有一個:多做模仿,反覆練習。其實你能夠在第一次學習時就根據課堂案例「照貓畫虎」的做出課後練習,已經很不錯了。而且既然能夠根據課堂案例模仿出一個作業的答案,自然就能夠根據作業答案模仿做出其他類似問題的答案…… 如此擴展下去,是完全有能力「頓悟」的。所以你接下來要做的,就是反覆思考你做出來的代碼,做到你能夠不藉助任何參考,直接默寫出這些簡單的小程序。然後多去嘗試簡單的陌生的問題,很快你就會「突然間」領悟到編程的思維,然後會發覺之前你一直想不明白的地方其實竟然如此簡單。到了這個層次,雖然還是有很多技巧、知識沒有掌握,但從思維上和信心上,已經開始擺脫初學者階段了。

nn

寫了這麼多,其實也是一直有點感慨,因為前幾天有知友邀請我回答一個教育話題,討論「教學是不是一個技術」。我思考再三暫時還是沒有作答,因為在我的理念中,就像我的網站logo一樣,認為「講課是一門藝術」 (yycollege.com)。既然是藝術,就沒有一個精確的評價標準,一切都只能靠我們自己的感受去表達,而每個受眾也都會有自己與眾不同的理解方式與欣賞偏好。我想這也就是為什麼對於同一個科目,會同時有很多不同風格老師開設很多網課,而每門課程或多或少總有同學選聽的原因。

nn

最後再次感謝你的提問。教學互長,我們自己也在不斷搜集和總結同學們的反饋,爭取在網路教學中能夠不斷的完善和提高。

推薦閱讀:

ollie是什麼?滑板中ollie這一動作怎麼做?經常會遇到哪些問題?
手把手教學:如何設計一款「完美」的「失敗」產品?
演講或講課過程中,形式大於內容?
我實名反對
如何開發一個學生作業互評系統?

TAG:VBA | MicrosoftOffice | 教学 |