編程困難檢測概述

王瑞文

（四川大學計算機學院，成都 610065）

0 引言

在21世紀，IT行業在全球經濟中所占的比重變得越來越大，而編程能力也逐漸成為科研和工程領域的高端人才不可或缺的技能之一，而且越來越多的工作被程序所取代，社會對編程技能的需求以及編程的效用也不斷增加。在McKinsey全球研究院于2013年發布的《至2025年決定世界未來經濟的12大顛覆技術》中，排名前六位的都是與編程密切相關的技術，且大約占到了經濟規模的90%[1]。但是，無論是剛接觸編程的學生還是專業的程序員，在編程中都不可避免地遇到各種困難，這些困難則會阻礙他們的學習或者開發進度。

在編程教學方面，如果能夠檢測到學生在編程中遇到的困難，并在恰當的時機由系統自動地給予學生適宜的反饋，例如在內容上提示學生應當如何改善代碼，或者在情緒上給予支持及鼓勵，增強其學習動機。另外，可以將自動檢測得到的學生困難信息提供給教師，例如每個學生遇到困難的次數、經常出現的困難類型等。依據這些補充信息，教師可以進一步了解各個學生的特點，以及在不同知識點上的掌握程度，如此一來，教師就可以針對性地為各個學生提供個性化的教育，做到因材施教。

在工業生產方面，專業程序員也常常面臨編程困難，這些困難如果得不到解決，則會明顯地限制開發進度，降低程序員的生產力。Herbsleb等人[2]發現，如果團隊成員均處于同一建筑物中，其生產力要高于成員分散于各地的團隊，其原因在于前者能夠使成員之間互相幫助更多。Herbsleb和Grinter[3]的一項早期研究指出了這一現象的原因之一：分散在不同地點的團隊成員之間相對地會在詢問幫助上感到更加不舒服，因為他們之間的互動比共處一地的團隊少很多。而Teasley等人[4]的研究則進一步證明了這一事實。他們發現處于同一個房間的團隊，其生產力要高于成員分散于不同房間的團隊。這是因為共處于同一房間的開發者可以看到以及聽到其他人在做什么，這使得他們可以在注意到某人遇到困難時為他提供幫助。這些研究共同表明——團隊之間互相幫助越多，其困難就能越順利地得到解決，從而促進團隊生產力的提高。因此，自動地檢測開發者遇到的編程困難，并適時地提供恰當的困難上下文信息提供給團隊中的其他開發者，促進他們之間的互助，可以提升團隊生產力。

綜上所述，無論是從教育界的視角還是工業界的角度來看，檢測開發者在編程中遇到的困難都具有很重要的意義。本文對已有文獻進行了概括分析，對編程行為數據收集工具進行了介紹，對已有工作進行了概括與分類，總結了當前編程困難檢測研究的進展。

1 編程行為數據收集

對于編程困難檢測而言，特征數據的收集至關重要。但是在對于開發者行為數據的收集，能夠采集到什么編程語言的行為數據，能夠采集到什么層次的哪些行為數據，取決于所使用的IDE以及行為記錄工具。Ihantola等人[5]在他們對于教育數據挖掘的綜述中總結了多款可用于編程數據收集的工具，見表1前10行。

對于編程行為數據收集工具來說，其能收集的數據類型越豐富越好。Yoon等人[6]開發的FLUORITE1http：//www.cs.cmu.edu/～fluorite/research.html可以記錄Eclipse下Java編程的多種事件級信息。他們宣稱該工具可以記錄Eclipse代碼編輯器內的全部低層次事件。FLUORITE分為兩個部分：其logger部分能夠記錄各種編程事件并保存到xml文件中；其analyzer部分可以用來檢測代碼編輯模式、對收集到的數據進行統計和可視化。Fluortie記錄三種類型的事件：

●命令（Command）：直接由用戶動作引發的事件，包括：輸入文本、移動文本光標、通過鍵盤或鼠標選中文本、調試以及各種編輯器命令（如復制、粘貼、撤銷）。

●文檔變化（Document Change）：執行任意命令導致文件變化時被記錄的事件。該類型事件會記錄文檔變化的內容、位置、時間等信息。

●注解（Annotation）：這類事件用于讓開發者向調查人員提供注解。用戶可以點擊注解按鈕，然后在下圖所示彈出來的對話框中添加注解。

表1 已有的編程數據收集工具示例

Fluorite在記錄這些事件的同時還記錄了各個事件的內容：如插入刪除的文本、文本光標移動時的位置、打開的文件、事件的時間戳等。在Fluorite的基礎之上，Long等人[17]開發了EclipseHelper這一困難檢測實驗平臺，它集成了實時困難檢測、標記困難標簽、可視化編程行為數據與預測結果等功能。

2 編程困難檢測分類

編程中的困難可以被定義為：開發者（或觀察者）可以感知到的開發速度低于正常[18]。

對于各種編程困難檢測研究，我們可以從各種不同的方面對其進行分類。依據算法是否能夠實時地檢測編程困難，我們可以將它們分為在線（online）的方法以及離線（offline）的方法。依據算法是否需要使用額外的傳感器設備來捕捉編程時的數據，我們可以將它們分為有傳感器（with sensor）的方法以及無傳感器（sensor free）的方法。

2.1 在線 vs離線

依據算法是否能夠在開發者編程的過程中即時地檢測出困難，可以將編程困難檢測分為兩類：在線編程困難檢測以及離線編程困難檢測。

圖1 在線困難檢測流程

如果一個困難檢測器能夠在開發過程中連續不斷采集開發者信息的同時，利用這些信息實時地檢測出開發者是否遇到了困難，那么我們稱這種檢測方法是在線的。在線編程困難檢測的一般流程如圖1所示。首先，程序需要在開發者編程的同時，持續地采集各種變成情境下的原始數據。然后將得到的這些原始數據進行特征提取，將得到的特征作為訓練好的困難檢測分類器中，實時地判斷開發者是否遇到了困難。如果開發者遇到了困難，則可以從原始數據中提取新的特征來檢測更多困難上下文信息，如困難類型。在線困難檢測中，通常使用開發者的生理心理數據（如心率、肌電、腦電圖等）或行為數據以及一些代碼的統計數據作為數據源。在線困難檢測如Cater的研究[19]，Cater手動檢查了被試在遇到困難時的行為變化，總結出了五類開發者遇到困難時可能有明顯變化的行為：文件導航（打開文件、切換文件等）；編輯（文本插入、刪除）；移除代碼（方法或類）；調試；切入切出IDE（Integrated Development Environment，集成開發環境）。依據這五類行為的比率，Carter使用決策樹成功地在開發者編程的同時檢測出了他們的困難。

如果一個困難檢測器需要在開發者完成一次編程之后，才能收集到所需的所有數據或者才能開始訓練檢測器模型，不能做到實時地檢測困難。那么我們稱這種檢測方法是離線的。在離線的困難檢測中，通常是對開發者在編程過程的不同階段進行分析。例如，Piech等人[20]利用學生在編程過程中的代碼快照對其開發路徑進行了建模，以此展示學生的進度，并確定他們在哪里遇到困難。他們記錄學生每次編譯時的代碼快照，利用K-Mediods算法對來自不同學生的代碼快照進行聚類，再使用隱馬爾可夫模型訓練出一個有限狀態機，如圖2所示。這一狀態機可以表示學生在編程時如何在各種高層狀態之中轉移。這些高層狀態代表著學生在編程時的不同里程碑階段。使用這一方法，可以在學生完成編程練習之后，建模他們的編程進展過程，從而識別出學生在編程中何時遇到了困難。學生在編程過程中，可能在連續多個代碼快照中均停留在一個高層狀態，這種狀態則被稱為“下沉狀態”，它指示著學生可能遇到了嚴重的編程困難。

圖2

某一學生在開發一個程序過程中狀態轉移的隱馬爾可夫模型。結點“codet”表示學生在時刻t的代碼快照，而結點“statet”表示的是學生在時刻t所處的高層狀態。N是該學生的代碼快照數量[20]。

2.2 有傳感器 vs無傳感器

依據算法在采集特征數據時是否需要使用額外的傳感器，可以將編程困難檢測分為兩類：有傳感器方法和無傳感器方法。這兩類方法有各自的優缺點。

有傳感器方法指在標準設備之外的傳感器來收集數據的方法。使用傳感器可以收集到更豐富的，更多類型的數據。常見的傳感器數據包括：被試的心率、皮膚電導等生理特征、被試的面部照片（表情）、按鍵壓力、坐姿，等等。其中很多數據與困難相關。例如微表情[21]可以很好地揭示出一個人的情緒，而開發者在遇到編程困難時，常常伴隨著困惑、沮喪等情緒。Kapoor等人[22]使用多種傳感器來預測孩子何時感到沮喪。他們認為：沮喪感與身體姿勢，面部表情，施加于鼠標的壓力和皮膚電導的變化相關。為了驗證這一猜想，他們在24名中學生解決漢諾塔問題的時候，從相機、姿勢座椅、壓力鼠標和無線藍牙皮膚電導測試收集這些數據。在編程過程中，為了收集類標數據，參與者需要點擊“我很沮喪”按鈕。當參與者沒有點擊“我很沮喪”按鈕時，他們被標記為不沮喪。他們訓練了幾種分類算法來輸出模型，如支持向量機（Support Vector Machines，SVM）。他們的結果顯示SVM算法達到了70.83%的查準率。Fritz等人[23]則使用了心理-生理傳感器收集了15位專業程序員在編碼時的數據，包括眼動儀、皮膚電活動傳感器、腦電圖。他們使用這些數據來預測開發者是否遇到了困難。對于訓練集外的開發者，其查準率達到了64.99%，查全率達到了64.58%。對于訓練集外的編程任務，其查準率達到了84.38%，查全率達到了69.79%。

雖然有傳感器方法可以搜集到更全面的特征信息，從而提升算法準確度。但是它也存在明顯的弊端。首先，傳感器的布置就會造成額外的開銷，尤其是許多專用設備造價高昂使用復雜，導致方法難以普及。其次，使用傳感器可能會對被試造成干擾，并且會涉及到用戶的隱私。

無傳感器方法雖然收集的數據類型不如有傳感器方法豐富，但是它不需要額外布置其他設備，比較易于普及。另外它也不會對開發者造成過多的干擾。無傳感器方法通常使用開發者在開發時的行為日志、代碼快照等數據。行為日志可以體現出開發者的行為模式。例如，Jadud等人[24]依據編程時的編譯事件信息，提出了錯誤商（Error Quotient，EQ）這一概念。錯誤商可以用于發現開發者在什么時候遇到了語法上的困難，即難以解決編譯錯誤。它是使用以下算法計算的：

給定編譯會話，e1到en：

（1）配對連續編譯（e1,e2），（e3,e4），（e5,e6），…，（en-1,en）

（2）對有編譯錯誤的對賦予一個數值罰分。

①如果兩邊都有編譯錯誤，則分配8的罰分。

②如果兩邊有相同的編譯錯誤，則額外再加上3的罰分。

圖3 Kapoor工作[22]中的系統架構

（3）將分配給每一對的分數除以11（每對可能的最大值）

（4）將每對編譯的分數相加

（5）將總分除以編譯對的總數n-1

他們通過反復試驗來確定罰分的數值。完美的錯誤商數為0.0，這意味著學生能夠修正語法錯誤。相反，1.0的錯誤商數意味著每次學生編譯代碼時，編譯都以相同的語法錯誤結束。另外他們還對比發現了EQ指標和作業、考試的平均成績之間存在相關性。

也可以將傳感器數據與編程行為數據結合起來進行編程困難檢測。Carter發現了他們原始的困難檢測方法[6]具有較高的假陰率，于是進一步精練了行為特征集并加入傳感器特征[25]。Carter分別使用Microsoft Kinect Camera和Creative Interactive Gesture Camera來捕捉用戶的坐姿，判斷用戶是否前傾、后傾。他們發現在結合坐姿特征以及編程行為特征之后，可以明顯改進檢測結果，降低假陰率。

3 結語

編程困難檢測作為編程數據挖掘的一個分支，與教育界以及工業界密切相關。在檢測到用戶遇到困難之后，可以采取多種措施來輔助編程過程。對于學生，我們可以給予他一定情感支持來保持其學習動機。對于專業開發者，我們可以為他提供一定的代碼內容上的支持，引導他解決困難。目前的各種編程困難檢測方法存在不足，如在用戶空閑時不能準確地區分用戶是在思考編程還是去做與編程無關的事情；在檢測到困難后給予用戶的反饋不足等缺點。本文概述了編程困難檢測中的數據收集、通用流程、方法分類，希望可以促進編程困難檢測研究的進展。