面向開源源碼大數據的數據質量研究*

包盼盼，陶傳奇,2,3,4＋，黃志球,2,4

1.南京航空航天大學 計算機科學與技術學院，南京210016

2.南京航空航天大學 高安全系統的軟件開發與驗證技術工信部重點實驗室，南京210016

3.南京大學 計算機軟件新技術國家重點實驗室，南京210023

4.軟件新技術與產業化協同創新中心，南京210016

1 引言

為了幫助開發人員進行代碼復用，部分研究人員關注編程智能化相關的研究。比如，在代碼推薦中，Jiang 等人[1]將機器學習算法和傳統信息檢索方法結合進行方法塊推薦，Gu 等人[2]利用深度學習方法進行API（application programming interface）使用序列的推薦。但是，大部分編程智能化相關的研究都聚焦于各種算法的研究，而忽略了研究所使用數據的質量問題。大部分相關研究中所使用的數據都來源于GitHub。GitHub 作為開源平臺，項目托管者可能來自正規組織或軟件公司（如Apache、Google 等），也有可能是新手開發者，由于開發者代碼編寫水平參差不齊，GitHub 上的項目并不能保證都具有較高質量。根據“garbage in，garbage out”，源碼的數據質量會對基于大規模源碼進行智能化學習的結果質量產生重要影響。

當前對開源源碼數據進行處理的工作主要關注數據的過濾、清洗等。比如，江賀等人在進行方法塊推薦的相關研究時，對采集的數據進行了篩選處理，包括刪除代碼行數少于5 行的代碼片段和刪除結果中可能重復的方法塊。但是，鑒于源碼數據的復雜性[3]，簡單處理較難滿足研究人員對代碼數據質量的要求。結合傳統的數據清洗相關研究可以發現，方法塊的冗余清除屬于重復對象檢測，僅僅是數據清洗研究內容的一方面。代碼數據集作為智能化編程系統研究的基礎，其數據質量的問題還缺乏相關的研究。

針對上述問題，本文對已有的開源數據托管平臺上的海量源碼數據進行綜合分析，從不同的維度對源碼數據質量進行評估，并建立一種面向開源源碼大數據的質量分析方法。本文工作的主要貢獻在于，考慮到已有研究工作的困難和不足，研究回答了以下兩個重要問題：

（1）開源項目托管平臺上的源碼數據可能存在哪些質量問題。

（2）如何利用定性或定量的方式對開源代碼數據質量進行評估。

2 研究背景

本文以國際通用的開源軟件代碼庫GitHub 中的開源項目作為代碼數據質量問題的研究對象。

通過對各種智能化編程系統的調研分析，以推薦系統為例，根據推薦結果進行分類，比較常見的推薦系統類型有方法塊推薦[1]、API 序列推薦[2]、token 以及tokens 推薦[4-5]等。總的來說，其數據粒度小于等于方法塊，因此以方法塊作為數據質量評估的基本單元具有代表性和通用性。因此，本文評估的對象選擇的是從開源項目中抽取的方法塊。

本文分別以線上和線下兩大類數據信息對源碼數據質量進行評估。

線上數據信息來自于GitHub 中包含的對應項目信息。GitHub 代碼庫中包含對應項目的各種統計信息，包括Watch、Star 和Fork 等，這些統計信息中隱含著對應項目一定程度的質量信息，如果能夠找到合適的指標并充分使用，就能在一定程度上對項目質量進行評估。本文在充分理解各個統計指標的基礎上，綜合使用各種指標信息來對項目質量進行科學可信的評估。圖1 所示是GitHub 上單個項目的主頁中10個可能包含項目質量信息的統計指標。

線下數據信息來源于項目本身，主要是源碼質量[6-7]信息、方法塊功能重復[8]信息和自定義方法調用信息等。因為本文選擇以方法塊作為數據質量評估基本單元，所以除了源碼本身質量以外，是否具有獨立、完整的功能也應該作為方法塊數據質量的衡量維度之一。

這些方法塊通常會被用于構建智能化編程系統所使用的數據集，因此本文希望能夠幫助相關領域研究人員得到海量的、編程風格良好的、具有盡可能少的缺陷以及具有獨立完整功能的方法塊數據集。

代碼數據質量評估核心在于選用哪些維度進行數據質量衡量，以及如何具體地評估各個維度，方法則主要有定性和定量兩類。這也是本文主要的研究內容。

3 開源源碼數據質量問題

本章研究回答兩個重要問題中的第一個，即開源項目托管平臺上的源碼數據可能存在哪些質量問題。

本文的數據質量評估方法不局限于具體的程序設計語言，為了方便描述，本文用Java 程序設計語言為例進行陳述。

3.1 項目作者可信度問題

傳統衡量GitHub 代碼質量的方法通常基于項目的star數，即一個項目具有的star數越高，該項目質量越高。某些公司在招聘開發人員時，一個重要的加分項就是應聘者擁有高star數的GitHub 項目。然而，調查發現，部分被調查者有過幫助GitHub 項目作者“刷star”的行為。正是這樣的欺詐行為的存在，使得GitHub 上低質量的項目也可能具有較高的star 數，因此本文將作者刷star 數量的行為作為一個重要的數據質量參數。

本文希望能夠幫助智能化編程領域相關的研究人員得到海量的高質量方法塊，因此如果能夠判定某個具有高質量項目的作者確實是可信的，通常認為該作者具有較高的編程能力。進一步認為該作者的相關項目具有較高的質量，即使它們或許在單個項目統計指標上的數據質量并不是最優。

3.2 項目健康度問題

GitHub 作為全世界最大的開源項目托管平臺，擁有海量的開源代碼項目，給源代碼方面相關研究提供了極為豐富的數據資源。但因為其作為項目托管平臺，任何開發人員都可以在GitHub 上托管自己的任何項目。項目托管者可能是Apache、Google 這樣的正規組織及軟件公司，也有可能是正在學習編程開發的新手開發者。因此，開源平臺上的項目質量也參差不齊，并不能保證都具有較高質量。

項目本身作為比方法塊更大的粒度級別[9]，其質量的高低在一定程度上可以表征對應方法塊的質量。因此對方法塊進行質量評估，首先要對對應的項目整體進行評估。因此如何對海量的開源項目中單個項目進行質量評估也是一個重要的研究問題。

3.3 源碼質量問題

一個通過編譯的Java 項目，其源碼中仍然可能含有一些問題[10-12]。比如，不符合命名規則的變量或方法命名、未使用的局部變量或參數、空的try 語句等。如圖2 所示，一個能夠運行的方法塊中仍然存在一些問題，1 和3 是不規范的變量命名，2 是沒有使用的對象。

從方法粒度級別來看，這些問題通常不會影響方法塊的功能實現。但在更小粒度上，比如進行API、API 序列、token sequence 等相關研究時，上述問題就會產生較大影響。比如，進行token sequence 相關研究時，需要對源碼中用戶自定義的變量名進行統一化處理，而不符合命名規范的變量名可能會對該處理操作帶來困難。

因此，源碼本身也是代碼數據質量評估的一個重要方面。源碼本身可能存在哪些問題和如何找出以及統計這些問題是本文一個重要的研究內容。

3.4 方法塊功能常用性問題

刪除數據集中的重復方法塊可以解決數據冗余問題，盡可能使數據集具有最小性，在整個數據集層面上是必要的。但換個角度看，一個方法塊在整個數據集中的冗余程度越高，它所具有的功能就越常用[13]。比如，在Java 開發中，兩個方法塊分別具有功能“Write content to file”和功能“Serialize an object to a file”，兩個都是比較常見的功能需求。但是前一個功能更常見，所以一個進行方法塊推薦的系統所使用的數據集中更應該包含前者，否則可能會導致用戶需要卻無法獲取該功能。因此從方法塊數據質量評估的角度來看，功能越重復的方法塊，它的質量應該越高。

因此在方法塊功能維度上，本文需要解決如何對方法塊相似度進行計算[14]以及得到一個相似度閾值，使得能夠判定相似度大于該閾值的兩個方法塊功能是相似的。

3.5 方法塊功能原子性問題

正如之前所述，進行質量評估之后的方法塊會被用于構建智能化學習的數據集，比如用于方法塊和API 序列等推薦。無論方法塊最終會被用于哪種類型的代碼推薦，它都應該盡量具有獨立完整的功能，即在方法體中盡可能沒有對其他自定義方法的調用操作。

以方法塊推薦為例，如果一個方法塊中存在對其他自定義方法的調用，那么即使在最終推薦時用戶獲取到該方法塊，但由于調用方法的缺失，用戶也無法使用，這樣就使得推薦結果在一定程度上喪失了實用性。因此，如果一個方法塊中存在對自定義方法調用，該維度上應該被評估具有較低的質量。

4 開源源碼數據質量評估

本章研究回答之前所述兩個重要問題中的第2個，即如何利用定性或定量的方式對開源代碼數據質量進行評估。如圖3 所示，本文的評估方法包含5個維度。

Fig.2 Example of method that is still problematic through compiling圖2 一個通過編譯仍存在問題的方法塊示例

Fig.3 5 quality evaluation dimensions for open source big data圖3 面向開源源碼大數據的5個質量評估維度

本文的評估方法充分利用作者可信度、項目健康度、源碼質量、方法塊功能常用性和方法塊功能原子性5個維度信息，得到單個方法塊的評估結果。一個完整的評估流程如圖4 所示。

4.1 項目作者可信度評估

GitHub 的項目托管者刷star 數一般有兩種常見的方式：請其他的GitHub 用戶幫其進行該行為和委托該服務的提供商實施該行為。一般來說，第一種規模較小；第二種，結合圖2 內容可知，規模可以較大，并且可能存在同時刷star以及fork 的行為。

針對上述兩種情況，本文提出的解決方案是，通過從可信的GitHub 作者信息中獲取可信作者具有的一般規律。因此，本文的解決方法是通過在具有較高質量的項目地址集上計算watch/(watch+star+fork)的值，評估項目作者可信度。具體來說，利用收集的365個具有較高質量的項目地址，獲取其項目托管者主頁地址，進而獲取該作者在GitHub 上所有項目地址。然后，利用獲取到的地址，獲取對應項目watch、star 和fork 數，將各項對應相加之后，得到每個作者GitHub 所有項目得到的watch、star 和fork 總數。然后按照上述計算方法，得到watch/(watch+star+fork)的值，該值表征了該可信任GitHub 作者在該質量維度上的定量情況。計算對應作者所有項目總和在watch/(watch+star+fork)的值實際在一定程度上反映了該作者是否存在刷star 以及fork 的行為，比值越小，可能性越高。部分GitHub 作者對應總watch、star和fork 數統計和比值情況如表1 所示。

Table 1 Numbers and ratios information of some GitHub authors’total watch,star and fork表1 部分GitHub 作者總watch、star和fork 數統計以及比值情況

為了避免極端數值的影響，閾值計算方式是將365個watch/(watch+star+fork)比值去掉5個最大值和5個最小值之后，計算剩余355個值的平均值作為最終的閾值。最終計算得到的閾值保留3 位小數后為0.058。因此，對GitHub 項目作者可信度的評估方法為，計算對應作者所有項目總和在watch/(watch+star+fork)的值，如果值高于閾值0.058，則評估為可信。

4.2 項目健康度評估

Fig.4 Complete flow chart of data quality evaluation for method block圖4 一個完整的方法塊數據質量評估流程圖

GitHub 每個項目主頁會顯示對應項目的各種統計信息，包括Watch、Star 和Projects 等。為了進行項目健康度評估，本文構建了一個Java 項目數據集，共包含6 000個Java 項目地址，該數據集可以在一定程度上代表GitHub 總體Java 數據質量情況。根據已有的數據集和指標，本文對項目質量進行評估的基本想法是，給出GitHub 總體Java 項目的一般性質量表征，然后對單個Java 項目，根據其對應指標上的對比，可以得到該項目的一個定性的質量度量。

在指標選取上，根據對有GitHub 使用經驗的人員進行廣泛的信息收集，最終確定選用的指標為Watch、Star、Fork、Issues、Pull requests 和commits，并且對這6個指標分別計算閾值，然后得到一個項目健康度的定性評估方法。

為了降低極端值對閾值的影響，本文先統計6 000個項目各個指標值的對應各個值出現次數，按照出現次數從高到低進行排序，然后取前0.3 的次數值計算平均值得到各個指標對應的閾值。閾值計算過程如算法1 所示。

算法1 項目健康度評估的閾值計算

如算法1 描述，首先對6 000個項目數據，針對指標Watch、Star、Fork、Issues、Pull requests 和commits分別獲取每個項目的單個指標值，并統計各個指標值的對應各個值出現次數。比如，項目1 的Watch 指標值為200，則以200 為Watch 指標HashMap 的key、1為value，如果項目2 的Watch指標值也為200，則HashMap 中key 為200 的value 變為2。循環執行得到所有指標對應數值以及值的出現次數。然后，對各個指標對應的HashMap 按照value 大小從大到小排序，取前面的30%的數據，取出HashMap 中key 和value值，并計算均值，即得到對應指標的閾值。

本算法的優點在于：第一可以消除極端值對閾值的影響；第二可以利用更具有代表性的值來計算閾值。最終，保留3 位小數后，計算得到的各個指標對應閾值如表2 所示。

Table 2 Corresponding threshold value for each metric表2 各個指標對應閾值

因此，最終確定的對GitHub 項目質量進行評估方法為，采用定性的方式，待評估項目在對應指標上高于閾值則可以判定為質量較高。此外，由于本文給出了每個指標的對應閾值，用戶也可以根據自身需求，只采用其中部分指標，或者是根據需要給指標指定優先級，進而進行項目質量的評估。這樣可以更好地滿足用戶的特定需求，具有更好的實用性。

4.3 源碼質量評估

源碼質量評估主要分析源碼本身可能存在哪些問題以及如何對這些問題進行定性或定量度量。本文利用靜態代碼分析方法[15]，使用PMD（programming mistake detector）來對源碼中缺陷進行分析和統計。選擇PMD 的理由有兩點：首先，PMD 是一種比較常用的靜態代碼分析工具，其性能值得信賴；此外，PMD 和腳本語言的結合使用，能夠對Java 項目進行批量化靜態分析。PMD 通過其內置的編碼規則對Java 代碼進行靜態檢查，主要包括對潛在的bug、未使用的代碼、重復的代碼、循環體創建新對象等問題的檢查，這些規則在一定程度上覆蓋了源碼本身可能存在的問題，因此可以充分利用已有規則找出源碼中可能含有的問題。

本文需要解決的一個問題是：PMD 進行靜態代碼分析的基本單位是Java 文件，而本文的目標是對一個Java 方法塊進行缺陷類型和數量進行統計。為了解決這個問題，可以將PMD 和Java 抽象語法樹（abstract syntax tree，AST）結合使用。

另一個問題是，Java 代碼中不同的問題對源碼數據質量影響程度不同，因此對應的PMD 內置規則也應該具有不同的優先級。為了解決這個問題，將調查研究和統計方法相結合。首先，根據30個具有4～6年Java 開發經驗人員的意見，選擇比較重要的8個PMD 規則集。然后，在質量比較高的Java 項目集中對不同PMD 規則集檢查出的問題進行數量統計，在這些項目中某類問題出現次數越多，說明該類問題對源碼數據質量影響越小。這里所使用的高質量Java 項目集是具有較高質量的項目中的Java 項目，共選用了45個。如表3 所示，是在45個高質量Java 項目上統計出的8個PMD 規則集對應的問題數量。

Table 3 8 types of PMD rules in high quality Java project sets表3 高質量Java 項目集中8 類PMD 規則檢查情況

根據表3 的數量統計情況，可以得到各個規則集對應的優先級。在源碼質量維度，本文使用這些PMD 規則集來進行質量評估，最終用戶可以根據各個規則集在某個方法塊中檢查出問題的數量，結合已經測定的優先級，對該方法塊質量進行定性的評估。

4.4 方法塊功能常用性評估

一個方法塊在整個數據集中冗余程度越高，對該方法塊自身而言，它所具有的功能就越常用。因此，本文從方法塊功能常用性維度對其質量進行評估。在該維度上，需要確定方法塊相似度的計算方法以及相似度閾值的計算方法。

本文選擇使用Simhash[16-17]方法計算方法塊相似度。選擇的原因主要有兩個：（1）Simhash 是用來進行網頁去重常用的高效方法，而評估方法塊功能是否常見需要將單個方法塊和數據集中每個方法進行相似度計算，因此計算速度對實用性影響較大；（2）Simhash 是一種局部敏感hash，如果兩個字符串具有一定的相似性，在hash 之后，仍然能保持這種相似性。而這是進行代碼相似度計算中的重要特性。

在相似度閾值計算方面，首先從Stack Overflow和相關論文中獲取10個比較常見的Java 方法塊功能需求。然后，將10個指定的功能發布給30個具有4～6年Java 開發經驗的開發人員進行Java 方法塊編寫，最終得到10 組共300個具有相同功能的方法塊。相似度閾值通過對10 組方法塊計算相似度并取平均得到，保留兩位小數之后的值為0.82。

本文考慮對單個方法塊質量進行評估，而不是構建方法塊數據集，因此還需構建一個用于和被評估方法塊計算相似度的方法塊數據集。并且，將不具有實際功能的main()函數、set()/get()函數、測試單元以及部分重寫函數等函數進行清除。最終可以根據給定的數據集，計算待評估方法塊與數據集中方法塊功能的相似性，并根據閾值評估該方法塊功能的常見程度，用戶可以決定是否使用該方法塊。

4.5 方法塊功能原子性評估

方法塊功能的獨立完整性作為方法塊數據質量評估的一個維度是有必要的。這里需要統計方法塊中對自定義方法的具體的調用次數。

首先，對一個Java 項目中所有Java 文件分別構建一個抽象語法樹。利用該語法樹來識別Java 類中所有方法調用以及其所屬的方法塊。對方法中的所有方法調用進行處理之后，可以得到對應方法塊中所有方法調用所使用方法的方法名及所屬類，然后以類名+方法名的形式進行保存。對方法塊進行識別、切分和保存之后，可以進一步抽取所有方法塊對應方法名及其所屬的自定義Java 類，進而得到單個Java 項目中所有的自定義方法的方法名，并同樣以類名+方法名的形式進行保存。最后，將單個方法所調用方法和自定義方法進行比較，如果存在交集，則存在自定義方法調用情況，也可以統計出總的調用次數。并且，由于利用了方法所屬類的信息，即使存在自定義方法和Java 已有方法或第三方JAR 包中方法同名的現象，也能根據所屬類信息進行區分。而類名和方法名都重名的情況，本文認為該情況比較極端，暫且不予考慮。

因此針對方法塊功能完整性評估，最終得到的是單個方法塊中對自定義方法的調用次數。根據該值，用戶可以判斷對應方法塊功能是否獨立完整，以及對其他方法塊功能依賴程度，最終決定是否使用該方法塊。

5 實例應用及方法有效性驗證

本章系統化介紹對GitHub 上一個Java 項目實施完整的數據質量評估過程，將結合具體實例對提出的方法塊評估方法的有效性進行驗證。主要針對包含數值計算和閾值的維度進行驗證，即項目作者可信度、項目健康度和方法塊功能常用性維度。而源碼質量和方法塊功能完整性維度是指導性的評估，用戶根據自身需求決定是否使用，本文不再專門進行有效性驗證。

5.1 數據收集

本章在開源軟件項目托管平臺GitHub 上收集開源項目數據用于進行數據質量問題分析，按照需求的不同收集了兩種不同質量級別的項目地址集。

第一種是具有平均數據質量的項目集地址，本文將該數據集作為GitHub 總體項目數據子集，能夠在一定程度上代表GitHub 總的數據質量情況。因此，本文的收集方法是通過language 和star 對項目數據地址進行檢索爬取。為了更具一般性，取star 數在0～10 000 之間，以這樣的方式爬取到6 000個Java 項目地址，具有典型性和代表性。

第二種是具有較高質量的項目集地址，進而獲取其項目托管者主頁地址，這里不再針對特定語言。本文收集了365個，語言包括C、C++、Java、C#、Android、iOS 以及Python 在內的，公認具有較高質量的項目的作者主頁地址，具有典型性和代表性。考慮到本文是利用高質量項目對應作者的信息來計算項目作者可信度閾值，相當于使用了365個專家信息，可以滿足閾值的計算需求。部分項目信息如表4所示。

Table 4 Information of partial project examples with high quality表4 部分所使用的高質量項目信息示例

5.2 實例應用

為了更好地理解本文評估方法的評估過程，本文從GitHub 中隨機抽取一個Java 項目進行實例應用分析，項目主頁鏈接為https://github.com/mi***cs/mi***er。

首先進行項目作者可信度評估。利用項目主頁鏈接，可以獲取到對應作者主頁鏈接為https://github.com/mi***cs，進而統計該作者對應的所有項目的watch、star 和fork 數量，分別為157、1 679 和292，計算watch/(watch+star+fork)比值為0.074。該值大于項目作者可信度閾值0.058，因此在項目作者可信度維度可以判定該項目的作者是可信的。

進行項目健康度評估時，根據項目主頁鏈接可以獲取到Watch、Star、Fork、Issues、Pull requests 和commits 這6個指標值分別為121、1 338、275、97、25和1 366，分別大于對應閾值11、76、28、4、1 和58。因此，在項目健康度維度該項目評估為健康。

在源碼質量評估中，利用AST 和PMD 將項目中所有Java 文件以方法塊為單位進行切分，并得到每個方法塊中不同PMD 規則檢測出的缺陷數量。該項目切分得到的方法塊數量為380，每個方法塊中對應各個規則缺陷數量不等。以方法塊metricData 為例，該方法塊中有3個rulesets/Java/naming 規則檢測出的規范，而該規范優先級較低，即在一定程度上是可以接受的。因此，該源碼質量評估中，方法塊metricData可以評估為具有較高質量。

進行方法塊功能常用性評估時，同樣以方法塊metricData 為例，先計算該方法塊和方法塊數據集中每個方法塊相似度，計算后得到相似度最大為0.78，小于閾值0.82。因此，在方法塊功能常見性維度，該方法塊功能不是較常見的功能。

在方法塊功能原子性評估中，利用AST 得到該方法塊中調用的方法數量為6，但都不是自定義方法，也就是說該方法對自定義方法調用為0。因此，該方法塊功能具有原子性。

綜合上述5個維度的評估結果，雖然該方法塊功能不是較常見的功能，但在其他4個維度的評估中評價較高，因此最終評估該方法塊具有較高的質量。

同理，該項目對應的其他379個方法塊按照metricData 的評估方式，可以繼續得到源碼質量評估、方法塊功能常用性評估和方法塊功能原子性評估的評估結果，得到5個不同維度的最終評估結果。最終，該項目對應的380個方法塊中，337個方法塊評估為具有較高質量，其他的43個方法塊質量評估為較低。

5.3 方法有效性驗證

對于作者可信度的評估方法是計算對應作者所有項目總和在watch/(watch+star+fork)的值，值高于閾值0.058 評估為可信。為了驗證該方法和該閾值是否有效，本文隨機爬取GitHub 中10個watch/(watch+star+fork)的值低于該閾值的項目作者主頁，然后人為分析對應作者所有項目中是否存在有問題的項目。如表5 所示，是10個評估方法判定為不可信作者的具體信息統計情況。

Table 5 Statistics on 10 untrusted authors through proposed evaluation approach表5 10個評估為不可信作者的信息統計

從表5 可以看出，大部分項目作者可信度維度評估為不可信的作者最終人為檢查中也是有問題的。這能夠說明，至少在項目作者可信度這個維度上，本文的評估方式是比較合理的。

一個需要解釋的地方是，10個評估為不可信的項目作者中有4個被人為判定為是可信的，這是因為本文對項目作者可信的評估比較嚴格。因為本文希望能夠通過該維度的評估來幫助相關的研究人員得到海量的高質量方法塊，所以判定某個具有高質量項目的作者確實是真實可信的，就認為該作者確實具有較高的編程能力。進一步就可以將該作者所有項目都視為具有較高的質量。因此總的來說，本文對項目作者可信度的評估方法以及評估閾值的設定還是比較合適的，確實能夠在一定程度上識別有問題的項目作者。

對GitHub 項目健康度進行評估方法為，在對應指標Watch、Star、Fork、Issues、Pull requests 和commits上高于測定閾值則可以判定為質量較高。因此，為了對該評估方法進行驗證，本文隨機爬取了5個在不同指標上低于對應閾值的項目，然后人為分析其對應項目源碼，判定其質量高低。具體項目信息統計情況如表6 所示。

Table 6 Statistics on 5 low-quality projects through proposed evaluation approach表6 5個評估為低質量項目的信息統計

通過表6 的內容，可以發現，5個在項目健康度維度評估為質量較低的項目，在人為評估中確實是由于各種不同的原因而具有較低的質量。并且其對應各個評估指標都具有較差的表現。

和項目作者評估類似，本文對項目健康度的評估也比較嚴格。因為本文的面向對象是智能化編程系統，比如代碼推薦系統，源碼質量可能對整個系統的性能影響都很大，本文希望能夠盡可能地只收集質量較高的項目。因此，可能會舍棄掉一些質量并不低的項目。

本文對項目健康度的評估方法以及評估閾值的設定還是比較合適的，能夠在一定程度上篩選出質量較高的項目。

針對方法塊功能常用性的評估是根據本文構造的數據集，計算待評估方法塊與數據集中方法塊功能的相似性，然后可以根據閾值評估該方法塊功能的常見程度。因此，對方法塊功能常用性維度進行驗證的方法是，對數據集中方法塊相似度大于閾值的方法塊功能進行人為獲取，進而判斷對應功能是否常見。具體來說，直接計算數據集中方法塊之間相似度，并將相似度大于閾值的方法塊歸為一簇。對簇規模較大的簇中方法塊功能常用性進行評估。為了和已構建的方法塊數據集進行區分，從GitHub上另外爬取了200個Java 項目來構建驗證所使用數據集，切分得到方法塊總數為118 254。表7 所示為10個較大簇方法塊功能信息。

Table 7 Statistics on commonly-used function information in 10 clusters表7 10個方法塊簇功能常用性信息

通過表7 的內容可以發現，統計的10個規模較大的簇中方法塊都具有較為清晰的功能實現，并且從功能上看也是比較常見的一些Java 功能需求。從每個簇中方法塊數量來看，雖然數量大小和對應功能的常用性并不是嚴格一致，但是總體來說仍然具有一定的正相關性。

根據驗證結果，本文給出的方法和測定的閾值確實能在一定程度上篩選出功能比較常見的方法塊。因此，本文認為對方法塊功能常用性評估方法是比較合適的。

5.4 實驗討論

本文通過大量調研發現，源碼數據的質量對源碼相關的研究有重大影響，并最終會對推薦結果的質量產生影響。這一點本文之前的代碼推薦相關的研究工作中已經得到證實。

而已有的一些對收集到的數據進行處理的工作相對簡單。比如，江賀等人在進行方法塊推薦的相關研究時，對采集的數據進行了簡單的篩選處理，這難以滿足研究人員對代碼數據質量的要求。已有的聚焦于源碼數據質量的研究工作較少，并且更關注如何對數據進行清洗問題，如周傲英等人的研究重點就是對數據進行清洗。他們較為具體地說明了數據質量的重要性和衡量指標，定義了數據清洗問題。然后對數據清洗問題進行分類，并分析了解決這些問題的途徑。還說明數據清洗研究與其他技術的結合情況，并分析了幾種數據清洗框架。

而在本文中，綜合考慮了項目作者可信度、項目健康度、源碼質量、代碼塊功能常用性和代碼塊功能原子性，共5個維度對代碼塊質量進行評估，而不是對源碼數據進行篩選或者清洗。本文最終給出對單個代碼塊的質量評估結果，將代碼塊的篩選工作交由進行具體研究工作的研究人員來完成，研究人員可以根據自身需求進行自主選擇是否使用某個代碼塊。

本文方法的有效性在5.3 節進行了驗證。對于作者可信度評估方法的驗證，結果如5.3 節中表5 所示。從表5 可以看出，大部分項目作者可信度維度評估為不可信的作者最終人為檢查中也是有問題的。這能夠說明，在項目作者可信度這個維度上，本文的評估方式是比較合理的。對項目健康度評估方法的驗證，結果如5.3 節表6 所示。5個被項目健康度評估維度的評估方法評估為質量較低的項目，在人為評估中確實是由于各種不同的原因而具有較低的質量。這在一定程度上說明了本文的項目健康度評估方法的有效性。針對方法塊功能常用性評估方法的有效性驗證，結果如5.3 節表7 所示。可以發現，本文給出的方法和測定的閾值確實能在一定程度上篩選出功能比較常見的方法塊。因此，本文認為方法塊功能常用性評估方法是有效的。

綜上所述，數據質量問題相當重要但是沒有引起足夠重視，本文方法較為有效地彌補了編程智能化相關研究在數據質量評估問題上的不足，具有一定的實用性和創新性。

5.5 方法有效性威脅

首先會對本文的面向開源源碼大數據質量評估方法的性能產生影響的是項目作者可信度維度。本文對該維度的評估主要是利用watch/(watch+star+fork)比值，因為本文考慮刷star 數的兩種方式是請其他的GitHub 用戶幫助進行該行為，以及委托專門提供該服務的服務商實施該行為，尤其是考慮到大量刷star 的行為只能通過服務商提供。因此，本文認為所提出的針對該維度的評估方式是比較合適的。但是，如果一個項目刷star 的方式主要是請其他的GitHub 用戶幫助進行該行為，并且他委托的用戶有很多，那么就可能造成對watch、star和fork的數量都有舞弊的行為，在這種情況下，本文針對該維度的評估方法可能就不太適用了。雖然這是一種極端情況，但是該情況確實對本文方法的有效性有很大的威脅。因此，這個問題會在未來工作中進行進一步研究。

此外，本文的評估方法當前主要針對Java 語言。理論上本文的方法適用于所有編程語言。但是，由于本文只對Java 語言項目進行了研究，而沒有考慮其他語言項目的特點，因此編程語言可能也是一個對本文方法有效性產生威脅的一個比較重要的因素。將來，會結合不同編程語言各自的特點，將本文的方法擴展到其他的語言環境。

6 總結

高質量方法塊是進行智能化編程及相關研究工作的基礎。隨著基于開源源碼的智能化軟件開發日益盛行，研究人員也逐漸認識到源碼數據質量的重要性，并嘗試進行了一些簡單的數據處理。然而，當前對于源碼數據質量問題的關注度還比較缺乏。因此，本文面向相關研究中經常使用的開源項目托管平臺上的代碼數據，根據開源源碼中可能存在的數據質量問題，從不同的維度，提出一種針對開源大數據的代碼數據質量評估方法。本文旨在讓從事相關研究的開發人員能夠通過本文方法對研究中所使用的方法塊質量進行系統的評估，從而提高智能化軟件開發水平和質量。

未來工作將繼續關注編程智能化方面的相關工作，包括將本文的數據質量評估方法應用到其他語言以及研究其他語言采用的代碼檢測工具及使用方法的工作。將深入進行評估方面的研究。目標是能夠實現對智能化編程系統所使用數據集質量的自動化評估、所使用測試集的自動構建、所使用算法的自動分析和智能化編程系統評估使用的指標的自動選取及可解釋性分析等。同時對常見的，如API 及方法塊推薦等，建立完整的自動化、智能化和可解釋性較好的評估系統。