引用：Latoza T D , Di Lecce A , Ricci F , et al. Microtask Programming[J]. IEEE Transactions on Software Engineering, 2018:1-1.
摘要：
諸如開源軟件開發之類的傳統眾包形式利用人群貢獻來使軟件創建民主化。但是，潛在的貢獻者必須首先克服加入障礙，迫使那些隨心所欲的貢獻者花上幾天或幾周的時間參加培訓，從而減少該類人員的參與。為了更有效地利用人群的潛在貢獻，我們提出了一種編程方法，其中的工作完全通過微任務來完成，為貢獻者提供簡短，獨立的任務，例如實現功能的一部分或更新調用了某一函數的功能點來匹配對該函數所做的更改。在微任務編程中，微任務涉及對單個功能點的更改，由系統根據需要自動生成，并通過迭代來提高質量。一項研究了微任務編程在創建小程序上的可行性的研究發現，開發人員能夠在不到 15 分鐘的時間內完成 1008 個微任務，在機上提交第一個微任務，平均在不到 5 分鐘的時間內完成所有類型的微任務并創建 490 行代碼和 149 個單元測試。結果證明了微任務編程的潛在可行性，并揭示了要成功地將微任務編程擴展到更大，更復雜的程序仍然需要解決許多重要的挑戰。
關鍵詞：編程環境，管理
1.介紹
眾包軟件工程為縮短軟件投入市場時間，生成替代解決方案，聘請專家，通過工作學習以及使參與軟件工程更加民主化提供了許多機會。如今，最古老，最流行的軟件眾包形式之一就是開源軟件開發（OSS）。在 OSS 中，從人群中征求意見，向愛好者，專業人員甚至公司開放功能開發和錯誤修復。 OSS 是一種基于平民的對等生產形式，可以實現以下三個關鍵的結構化特性：（1）可以將輸出分解為單獨的貢獻單位（例如，解決問題跟蹤器中的問題），（2）貢獻的粒度足夠細，可以吸引那些僅會付出很小努力的人的貢獻，并且（3）低成本的機制可以抵御不稱職和惡意的貢獻，并將其整合為一個整體（例如拉取請求）。但是，當今的開源項目尚未完全意識到該模型的潛力，因為它們對潛在的貢獻者施加了巨大的加入障礙。其中包括：（1）識別適當的聯系方式并定時收到反饋，（2）識別適當的任務和相應的功能點，（3）了解項目結構，復雜的代碼并設置工作區，（4）過時，不清楚的文檔和信息過載，以及（5）學習項目實踐，領域知識和技術專長。綜上所述，這些障礙強阻止了忙碌或隨便投入的人做出貢獻，并將數以百萬計的潛在貢獻者池限制為僅最有貢獻的人。
通常在其他領域中使用的一種解決方案是微任務。 微任務是一個簡短，獨立的工作單元，目標明確。 在微任務中組織工作可以使工作人員完成的任務脫上下文，從而可以在不進行其他工作的情況下做出貢獻，而無需先驗知識。 將工作去上下文化為微任務已應用于許多領域中的問題。 例如，在 Soylent 的工作中可以將編輯文檔去上下文化，并分解為“查找”，“修復”和“驗證”微任務，在這些微任務中，獨立的工作人員可以識別修改的機會，生成潛在的修改并對修改進行投票。 FoldIt 游戲的玩家解決難題任務，然后將其結果用于生成有挑戰性的蛋白質折疊任務的解決方案。
微任務眾包已發現在軟件工程領域可行的去上下文化的任務分解的應用方法。 如今，開發人員通常在 StackOverflow 上完成微任務，其中問題的提問者通過以問題的形式識別簡短，清晰的目標（通常構造為要生成或修改的簡短代碼片段）完成任務的去上下文化[10]。 uTest1 等網站將自由測試人員與項目匹配，從而幫助項目從 300,000 多名注冊測試人員中快速招募。
但是編程可以應用微任務嗎？對于開發人員來說，今天是否有可能花 10 分鐘來回答關于 StackOverflow 的問題，而花同樣的 10 分鐘來為開源項目編寫代碼呢？為了實現這一目標，需要新的方法來減少上下文需求，并減少加入傳統上由開源項目施加的障礙以擴大參與度。但是，擴大參與范圍與提高團隊生產力相比是一個截然不同的目標，甚至可能與之相反。與一個開發人員相比，五個人組成的團隊會產生單個開發人員不必要的協調開銷。同樣，將一個開源項目的貢獻者數量從 20 個增加到 2000，很可能意味著每個貢獻者的小時數都會增加，這是因為每個貢獻者在項目上花費的時間更少，專業知識更少，工作更慢。正如 Shirky 所認為的，我們的目標不是利用團隊的生產力，而是要利用 1980 名短時貢獻者的貢獻，否則他們的貢獻潛力就無法發揮作用。
為了解決微任務編程的挑戰，我們提出了一套針對新編程環境的設計原則，并根據這些原則描述了系統設計。 為了實現細粒度的貢獻，將工作組織成對單個功能點（例如功能或測試）的本地更改。 然后，系統本身負責創建，管理和分配微任務，跟蹤功能點的狀態以確定需要執行的操作，并在必要時傳播功能點之間的接口更改。 為了確保所創建的最終程序的質量，將通過草繪，重復編輯，報告問題，檢查過程和測試來迭代評估和修改功能點。 為了做出貢獻，工作人員只需登錄，完成一個簡短的教程并開始處理分配的微任務。
我們的工作是對微任務在軟件工程中使用的長期探索的一部分。 在本文中，我們考慮在較小的范圍內進行編程，在這種情況下，可以通過編碼，測試和調試來實現對由客戶端構成的組件的明確定義的請求。 我們的方法建立在早期探索和原型檢查機制的基礎上，這些機制用于為編程和小型先導實驗推導微任務。 其他工作研究了微任務眾包與其他眾包模型的關系，并考慮了協調開發人員對微任務進行編程的機制。 在這項工作中，我們不考慮微任務創建軟件需求，體系結構，設計或用戶界面。 在其他工作中，我們已開始探索如何將軟件設計任務眾包。
在本文中，我們為微任務編程提供了一組新的設計原理，以反映從我們先前的方法中吸取的教訓。 尤其是，我們貢獻了新技術來確保質量，向貢獻者提供反饋，模塊化調試，使貢獻者更輕松地重用代碼并更快地啟用新貢獻者。 我們還提供了一項新的實證研究，探討了微任務編程在可行性，入門速度，貢獻速度和質量控制機制等方面的潛力和挑戰。
我們首先通過一個例子來說明微任務編程。 然后，我們介紹我們的方法并描述新的微任務編程環境的設計。 為了評估微任務編程的可行性，我們描述了一項用戶研究的結果，其中兩群用戶使用微任務編程來構建小程序。 最后，我們討論了將微任務應用到編程中的前景和挑戰。
2.激勵例子
Doug 剛剛啟動了一個開源項目，以構建更好的繪圖應用程序。 在初步了解其應具有的功能之后，他決定下一步是開始構建原型實現。 他決定使用 CrowdCod 應用微任務來創建該原型。 他首先將繪圖程序的核心邏輯指定為一個組件，該組件由四個功能和描述這些功能將使用和產生的數據的抽象數據類型（ADT）組成。 Doug 在 CrowdCode 管理界面中輸入此信息，為項目聲明，在其網站上發布該項目的鏈接，并在在線編程論壇上宣布其新的繪圖應用程序。
愛麗絲找到項目，單擊并登錄到 CrowdCode。她首先看到一個簡短的教程，描述了 CrowdCode 界面的主要元素，包括任務描述，微任務窗格，聊天，活動提要和頁首橫幅。然后，她被分配到了”編輯功能”的微任務。她閱讀了第二篇教程，其中描述了該微任務，確定了微任務的目標，可能采取的行動，并強調只寫幾行代碼或偽代碼，而不必完成該功能的實現。然后，她開始處理“編輯功能”微任務，并讀取其中包含的函數 moveElement。她發現其中已經包含偽代碼，因此將其替換為部分實現。她認為實現功能來檢查先決條件是在其他地方表現最好的實現方式，因此她在底部編寫了一個用于新功能 validElementType 的函數聲明用于檢查先決條件，并在 moveElement 中添加了一個調用（圖 1，底部）。她努力完成工作，發現 10 分鐘的倒數計時器幾乎快到期了。寫下一個最后的想法，她添加了自己的偽代碼，該偽代碼描述了仍需要完成的一部分功能并單擊提交。
在 Alice 工作期間，其他人同時從事七個獨立的微任務，為繪圖程序的 API 其余部分構建代碼和測試。 Bob 被分配了一個微任務來測試 moveElement。 微任務提供函數的描述和聲明，描述移動矩形的測試用例的文本以及將測試用例實現為單元測試的請求。 使用測試構建器界面，Bob 首先瀏覽一個列出可用數據類型的面板，以了解 Element 數據類型的字段。 然后，他意識到自己不知道正在使用什么坐標系。 鮑勃沒有立即看到答案，而是在聊天中問了一個問題，愛麗絲回答了這個問題。 鮑勃完成測試，然后單擊提交。
查爾斯（Charles）坐公車回家，真的想編程。 他登錄到 CrowdCode，并被分配了 Write Test 微任務。 毫不激動，他單擊“跳過”，并被分配了一個新的“編輯功能”微任務，繼續執行 Alice 在 moveElement 上離開的位置。 更熱心的是，他迅速實現了愛麗絲（Alice）描述的算法，并編輯了其他幾行以使代碼更簡潔。 然后，他單擊提交。
Dave 評論了查爾斯的工作。 他注意到算法中的一個細微問題。 在他的評論中，他描述了該問題并將該作品評為 3 星。 Ellen 被分配了 Edit a Function 微任務來解決該問題，她已解決了該問題。 愛麗絲（Alice）受委派審查艾倫（Ellen）的貢獻，很高興地發現，自從她先前的貢獻以來，對 moveElement 的工作已經取得了較大的進展，并給埃倫（Ellen）的作品給予了 5 星的評價。
當 CrowdCode 跟蹤 moveElement 的狀態時，它確定沒有剩余的偽代碼要完成，也沒有要完成的測試。 使用分布式測試運行程序執行每個測試后，它會收到測試失敗的報告，并創建一個“調試任務失敗”微任務。 Charles 被分配了該微任務以調試 moveElement，選擇失敗的測試，并將鼠標懸停在表達式上以查看其在執行中的值。 將鼠標懸停在從 moveElement 到 validElementType 的調用上，他發現 validElementType 返回 false，這與它在描述中所承諾的行為相矛盾。 他使用編輯器編輯 validElementType 的返回值，并將其替換為 true。 重新運行測試后，他發現現在可以通過測試，然后單擊提交。 這會自動為 validElementType 生成一個新測試，該測試將自動執行并失敗。
Frank 登錄到 CrowdCode，并被分配了 對于 validElementType 的“調試測試失敗”任務。 查看失敗的測試，他發現對于有效的形狀，它返回的是 false。 編輯代碼后，他發現該函數缺少檢查形狀有效性所需的參數。 在編輯聲明以添加參數后，他添加了一些功能，重新運行測試，查看其通過并提交。 然后自動生成微任務以更新每個調用站點并測試 validElementType。
3. 設計原則
在本節中，我們提供了一組表示微任務編程方法的設計原理。 我們通過檢查現有系統以及我們根據自己的經驗來設計和評估一系列系統的早期原型，從而為我們的原則提供佐證。
3.1 貢獻去上下文化
傳統的軟件開發任務要求開發人員首先學習上下文，例如代碼中功能的位置，構建和運行代碼的步驟以及向誰詢問信息。 學習上下文會創建一個冗長的入門過程，從而延遲了開發人員首次可以做出有價值的代碼貢獻的時間。盡管不可能完全消除對上下文的需求，但是減少上下文可以降低入門成本，并使開發人員能夠更快地做出貢獻。
3.1.1 定位編輯到單一功能點
為開發人員提供單個任務以在單個小的功能點上執行（例如，功能或測試）具有多個優點。開發人員需要修改的功能點應該已經被定義好了，而不是還要在代碼庫中尋找可以進行更改的適當功能點。 減少此類上下文可能會大大減少在代碼庫中高效工作所需的知識。
使開發人員一次只能與單個功能點進行交互會帶來一些挑戰。 與其依賴開發人員訪問調用點或功能定義來了解相關功能的作用，不如將此類信息嵌入其他功能點的接口中。 不應依賴開發人員通過閱讀相關代碼來推斷參數的運行時類型，而應為參數顯式指定靜態類型。 開發人員需要進行仔細考慮才能更改其他的上下文信息。
3.1.2 提供預配置的環境
安裝適當的工具，從服務器下載代碼，識別和下載適當的依賴項以及配置工作區以構建項目，這些都構成了重大的貢獻障礙。 提供一個預先配置的環境可以大大減少這些障礙，從而減少啟動時間。 可以通過包含配置的開發環境的預設虛擬機，安裝的庫，腳本或通過 Web 應用程序來提供預配置環境
3.2 自動生成微任務
微任務描述了要取得進展的下一步。準確，完整地捕獲所有必要步驟非常重要，這樣就不會丟失所需完成的工作，也不會拖延進度。在任何給定的時間點，可能有許多并發的微任務正在進行中。一種方法是讓經理明確創建每個微任務并評估每個結果貢獻。但是，對于由短暫貢獻者進行的微任務簡短編程，這種方法對微任務的管理者要比他們自己簡單地完成工作要花費更多的時間，從而抵消了微任務的好處。此外，它還假定一個或多個經理在任何時候進行的工作始終可用。編程之外的領域中的傳統微任務眾包系統已通過使用完全自動化的微任務生成來解決了該問題，在這種情況下，客戶描述了初始請求，系統負責自動并立即生成全套微任務以完成，以及諸如冗余的機制投票確保質量。這樣，不再需要由請求者手動創作，管理和評估每個微任務的成本，而是由系統在眾包的幫助下組織工作。
但是，自動微任務生成帶來了新的挑戰。 在傳統的眾包方法中，微任務是通過固定的步驟序列生成的，例如 MapReduce 工作流程，其中描述了將每個輸入轉換為輸出的步驟。 相反，軟件任務是動態的，并且可能無法預先枚舉可能需要的功能和測試以及可能出現的問題和錯誤。 需要一種不同的方法，以便在程序出現時動態生成微任務。
3.2.1 跟蹤功能點狀態
為了跟蹤程序的當前狀態及其在滿足其要求方面的進展，可以分別跟蹤程序中每個功能點的狀態。考慮函數創建時的狀態。在任何時間點，一個功能可能都需要編寫聲明，完成實現或對其代碼進行調試。通過跟蹤描述完成或未完成的屬性，可以使用狀態機來描述功能點可以通過其進行過渡的狀態，并規定要完成的工作（例如，在開始其功能之前強加一個功能必須具有聲明的約束）。無論何時提交微任務，功能點都可以改變其屬性（例如，記錄已添加聲明），并轉換到反映這些屬性改變的新狀態。然后，每個轉換可以生成適當的微任務。功能點的演變甚至不必是單向的。例如，在開發人員在修復缺陷時添加偽代碼之后，功能點可能會轉換回以前的狀態。
3.2.2 跨依賴指示接口更改
當工作人員編輯功能點時，對功能點界面的編輯可能需要更改系統中其他位置的功能點。 例如，添加功能可能需要通過新參數傳遞其他信息，這隨后需要所有函數調用點和調用該函數的測試進行更新以提供此信息。 由于微任務僅跨越單個工件，因此需要一種機制來向其他功能點發出信號，說明發生了接口更改。
為了響應界面更改通知，功能點必須生成適當的微任務。一個關鍵的決定是依賴功能點應響應哪個接口更改。例如，一個函數可能會在其實現中發生行為更改，對其行為描述進行更改或對其聲明進行更改。但是，通常很難確定實現的更改或對函數描述的更改是否表示或不表示該功能接口的更改，這可能會影響該函數的調用者。根據我們對早期原型的經驗，我們發現工作人員經常更改函數描述只是為了澄清文本并修復格式和拼寫錯誤。在這種情況下，向這些函數的調用者發出信號更改會產生許多不必要的微任務，從而大大降低了生產率。更好的替代方法是僅針對明顯需要進行更改（例如聲明更改）的更改發出信號，并在不太頻繁的情況下依靠測試來捕獲其他行為界面更改。
在開發人員工作時，他們利用任務上下文描述其他相關功能點的接口。 開發人員可能會發現此任務上下文與他們的功能點不一致。 例如，我們發現編寫測試的工作人員有時意識到無法按照測試用例描述中所述測試函數的行為。 結果眾包工人不可能完成他們被要求執行的微任務。 因此，允許工作人員報告任務上下文相關的問題，中止微任務的工作，并為其他功能點創建微任務以解決問題是很重要的。
3.3 通過迭代實現質量
所有眾包方法的關鍵考慮因素是設計機制以防止不良貢獻并確保高質量的工作。 然而，使用眾包來征集許多貢獻者進行開發，也可以提高軟件質量，因為眾人貢獻的多樣化為實現更高質量的設計提供了基礎。 眾包本身不是由單個經理或架構師負責來監督項目，而是隨著工作的進行，通過個人的貢獻來確定項目的方向。 因此，重要的是要詳細考慮分解工作流組織和協調機制對產生的輸出質量的影響。
3.3.1 通過草圖鼓勵修改
長時間的貢獻會阻止眾包在完成工作時提供反饋，從而使貢獻在沒有眾包投入的情況下偏離正常。 出于多種原因可能會導致質量下降。 工人可能會因為困惑、不了解足夠的知識而無法提供高質量的解決方案、付出了很少的努力或是惡意而偏離了正常軌道。 無論出于何種原因，即使是單個低質量的貢獻，也可能通過引入使后續實施工作更具挑戰性的決策或引入缺陷來顯著降低總體質量。
防止低質量貢獻的一種機制是減少任何個人貢獻可能造成的損害。 通過減小貢獻的粒度，許多工人就有機會貢獻于相同的功能點，并且任何有問題的貢獻都可以修改。 這樣，犯錯誤的工人可能會迅速對其進行修正。 但是，我們在初步研究中發現，盡管另有明確指示，開發人員有時仍希望在單個功能點上繼續工作直至完成，這反映了開發人員對編程任務的期望。 例如，在一項關于早期原型的非正式研究中，一名工人在一個“編輯功能”微任務中工作了 66 分鐘。 由此，我們了解到創建限制貢獻規模的機制（例如限制單次貢獻的最大時間或規模）非常重要。
編程任務通常需要多行代碼。 在這些情況下，開發人員可能首先開始進行一項功能，然后將工作移交給其他人繼續。 在這種情況下，對于開發人員而言，重要的是要有辦法通過草圖實現設計的機制來傳達其方法的意圖。 草圖可以采用偽代碼的形式，其中開發人員為算法編寫高級計劃，而不必擔心仔細考慮所有細節。 如果算法中的步驟可能包含功能的整個單元，則開發人員可以編寫功能樁，描述該功能預期提供的功能。 通過這種方式，開發人員可以在更高的抽象水平上做出貢獻，隨后的開發人員可以隨后進行填寫。
3.3.2 支持審核和測試
防范低質量貢獻的第二種機制是明確檢查貢獻的質量。 創造機會來審查貢獻將創造一個貢獻必須經過的質量把關，并為貢獻提供可能有價值的反饋。 審查可以快速確定朝著無效的方向發展的新貢獻者的工作，并教導困惑的工人正確的工作方式。
評審提供了一種冗余形式，其中兩個貢獻者必須共同簽署工作才能繼續進行。 當然，與任何冗余一樣，評審本身可能是錯誤的。如果審稿人能夠決定放棄某些貢獻，這在導致有價值的貢獻被丟棄方面會成問題。 一種解決方案是僅允許使用評審修改工作。 這樣，引入了更多的冗余，因為隨后的貢獻者必須再次對先前的貢獻做出反應。例如，響應于評審修改貢獻的貢獻者可以確定所請求的修改本身是錯誤的并且忽略它。這樣，隨后的工作人員便可以看到以前的貢獻并采取他們認為合適的任何行為。
與傳統軟件開發一樣，測試提供了重要的質量關卡。 此外，通過將編寫測試和實現功能劃分為單獨的微任務，測試為另一個開發人員提供了一個機會，使他們可以在測試中了解該功能的改變，從而可以揭示實現者可能未曾考慮過的問題。 但是，在某些情況下，測試本身可能不正確，而不是功能不正確。 因此，重要的是提供必要的功能以同時修改功能和測試。
4. 系統
根據我們的設計原則，我們開發了用于微任務編程的 CrowdCode 環境。 在以下各節中，我們將描述用戶工作流，系統架構及其實現。
4.1 工作流
所有工作都從客戶請求開始，客戶請求描述了要通過一組功能描述和聲明，一組 ADT 描述以及一組驗收測試待實現的 API。所有工人的貢獻都是通過微任務完成的。當工作人員首次訪問 CrowdCode 時，將向他們顯示一個歡迎屏幕，解釋 CrowdCode 的基本概念，并提供簡短的交互式教程，解釋主要的界面元素。當工人第一次開始他們以前沒有做過的微任務時，會為他們提供一個額外的教程，其中使用一系列示例（例如，圖 2）詳細說明了如何執行微任務。 然后為工作人員提供系統自動分配的微任務，他們可以選擇完成或提交或跳過。
表 1 列出了 CrowdCode 環境中的微任務。 圖 3 描繪了為實現功能而生成的微任務的簡單示例。 根據客戶請求創建新項目后，將為每個 API 函數生成“編寫功能”（圖 3. 1）和“編寫測試用例”（圖 3.2）。 每當提交包含偽代碼的函數時，都會生成一個新的“編輯函數”微任務以繼續進行該函數的工作。
編寫測試分為兩個步驟。 在“編寫測試用例”微任務中，工作人員首先通過枚舉用于標識應測試行為的測試用例描述列表來指定功能的測試計劃。 在第二步中，每個測試用例為要作為單元測試實現的測試用例生成一個單獨的“編寫測試用例”微任務，從而使工作人員可以并行地完成每個測試（圖 3.4）。
提交包含一個或多個新功能樁時，將生成“重用搜索”微任務，使工作人員有機會找到提供與所請求樁相似的功能的現有功能，或表明不存在此類現有功能（圖 3.5）。 在這種情況下，將創建一個新功能并生成一個“寫功能描述”微任務，以根據提供的功能請求和請求功能的實現編寫新功能的聲明和文本描述（圖 3.6）。 然后遞歸地繼續工作，繼續生成微任務以編輯功能和編寫測試用例。 同時，一個事件被發送到調用函數，并且一個“編寫調用”微任務被生成并排隊（圖 3.7）。
當一個函數不包含剩余的偽代碼時，它將被編寫并準備進行測試。 隨著每個測試的實現，將針對該功能執行該測試。 如果某個功能未能通過一個或多個測試，則會為每個失敗的測試生成一個唯一的“調試測試失敗”微任務，以提供所有通過的測試以及恰好一個失敗的測試（圖 3.8）。 然后，工作人員可以編輯該功能，使其通過先前通過的測試和其他失敗的測試，插入新的偽代碼和樁，或報告一個或多個功能測試的問題。
當然，測試失敗可能不是功能中的缺陷。這就提出了一個挑戰：當故障定位似乎首先需要知道包含缺陷的功能時，如何才能將故障定位取消關聯，以使開發人員能夠使用單個功能模塊化地工作。為了應對這一挑戰，CrowdCode 使用了使用樁的模塊化調試過程。在調試函數時，工人可以隨時將鼠標懸停在函數調用上以查看實際參數和返回值。如果工作人員發現某個函數的返回值似乎與該函數的描述不匹配，則該工作人員然后可以編輯該函數的輸出，從而自動創建樁。然后重新運行測試，使工作人員可以檢查對功能行為的建議更改是否可以修復缺陷并導致測試通過。如果微任務是通過樁提交的，則請求的行為更改隨后將傳播到調用的函數，從而創建一個相應的測試，然后該測試將運行并且將失敗（除非功能已同時更改）。這樣，故障定位過程將在函數調用中遞歸地繼續，從而為每個相關函數創建一個新的“調試測試失敗”微任務。
在提交每個微任務之后，在微任務被標記為完成之前，首先會生成一個相應的“評審”微任務（“調試測試失敗”和“重用搜索”微任務除外）。 復查微任務向員工展示了貢獻和原始任務背景，并要求員工提供五點量級的質量評級。 得分為 1-3 的微任務被標記為“重發”，并且必須包含說明原因的評論； 否則，微任務將標記為“已接受”，并且評審文本是可選的。 然后，評審的結果將通過反饋通知工人。 一旦評審接受了，微任務就完成了，微任務的內容被用來更新相應的功能點。 如果標記為“重新發布”，則會生成一個新的微任務，該任務將復制原始微任務，并包括原始貢獻和評審。 然后將此微任務分配給新工作人員，以解決所報告的問題。
在查看微任務的任務上下文時，工作人員可能會發現任務上下文存在問題，從而阻止他們完成微任務（例如，無法測試的測試用例）。 在這種情況下，工作人員可以通過描述問題而不是微任務并提交來報告任務上下文中引用的特定功能點的問題。 然后為功能點生成一個新的微任務以解決該問題。
為了確保貢獻不會偏離軌道并獲得頻繁的反饋，微任務的時間和貢獻大小受到限制。 微任務的持續時間限制為 10 分鐘，通過顯示剩余時間的條形圖向工作人員顯示（圖 1-4）。 6 分鐘后，顯示警告消息。 如果 10 分鐘后仍未提交微任務，則會自動跳過該微任務并將其丟棄。 此外，除任何偽代碼外，“編輯功能”和“調試測試失敗”微任務中的貢獻僅限于凈增加十個語句（圖 1-3）。
CrowdCode 為工作人員提供了項目進度的總體展示，列出了所有功能的總代碼行以及功能和測試的數量（圖 1-8）。 工作人員可以通過全局聊天與其他當前登錄的工作人員進行交互。 最后，CrowdCode 提供了一個鼓勵貢獻的基本游戲化系統。 提交微任務的工人將獲得與評分相應的分數。 為了鼓勵員工承擔別人不希望做的微任務，跳過微任務會使其價值增加 20％。 每個工人的得分都顯示在排行榜中（圖 1-8）。
沒有剩余的未完成的微任務時，項目即已完成。 要使用眾包工人實現的代碼，客戶端可以隨時訪問項目的管理頁面，并下載所創建代碼的當前或過去版本。
4.2 服務
微任務編程基本上是分布式的，需要每個貢獻者分別做出貢獻之間的協調和同步。 CrowdCode 通過中央服務協調工作，該中央服務負責處理新的貢獻，更新功能點的狀態并生成新的微任務。
微任務生成器。 在客戶提交貢獻并由評審者審核之后，貢獻將用于更新功能點的當前版本。 基于這些更新，功能點的屬性可能會更改。 三個屬性確定每個功能的總體狀態：是否具有功能描述（已描述），是否具有不包含偽代碼的完整實現（已編寫）以及當前是否具有任何失敗的測試（錯誤）。 更新功能后，將檢查這些屬性以確定接下來應生成哪個微任務。 如果未描述功能，則會生成“寫功能描述”微任務。 如果未編寫函數，則會生成“編輯函數”微任務。 如果某個功能有錯誤，則會生成“調試測試失敗”微任務。 圖 3 描繪了工件過渡和生成的微任務生成的示例。
函數的工作已完成，并且進入描述，編寫且沒有錯誤的狀態時，不會生成任何微任務。 但是，當調用它的函數添加新的樁并將測試傳播到該函數時，該函數可能再次進入錯誤狀態。 在這種狀態下，工作人員可以自由地編輯函數并添加偽代碼，并且它可能會再次轉換為未編寫狀態。
每個功能都有一組相關功能，這些功能包含該功能的調用站點。 每當消息通過更改其名稱或參數來更改其接口時，都會向該函數的每個依賴項發送一條消息。 然后，此消息為每個調用者生成“編輯功能”微任務。 某些微任務還可以報告功能的問題（表 1），這將會會為該功能生成“編輯功能”微任務。
分布式測試執行器。 為了減少服務器資源的使用并促進對眾包的可伸縮性，所有測試都在客戶端而不是服務器上執行。 每個客戶端都維護一個測試執行服務，該服務執行測試并返回測試結果。每次對功能進行編輯后，所有測試的運行都計劃由服務器執行。這項工作分發給客戶，客戶將報告每次測試執行的結果。 測試失敗會生成“調試測試失敗”微任務。 此外，在“調試測試失敗”中，工作人員可以直接運行某個功能的所有測試。
版本控制系統。 要使測試能夠在客戶端上執行，客戶端必須具有被測功能的相應實現。 由于功能可以任意調用其他功能，因此客戶端必須具有系統中所有功能的代碼。 因此，CrowdCode 維護了一個簡單的版本控制系統，將當前代碼和測試從服務器同步到所有客戶端。 服務器確保每個功能點的活躍微任務不會超過一個，因此不會發生合并沖突。 每當接受貢獻并更新功能點時，都會創建該功能點的新版本。 然后，此新版本將與所有當前活動的客戶端同步。
活動。 各種后端操作跟蹤用于填充客戶端視圖的狀態。這包括每個工人的活動提要，排行榜和項目統計信息。活動服務管理此狀態，并向客戶端廣播更新。
4.3 體系結構
CrowdCode 被設計為由 Web 客戶端，后端和實時 NoSQL 數據存儲組成的客戶端-服務器系統（圖 4）。 后端和 NoSQL 數據存儲區均公開 RESTful 接口。客戶端從后端檢索并提交微任務，該后端處理微任務并更新實時 NoSQL 數據存儲中的數據。后端和數據存儲區經過分片以實現可伸縮性，其中后端被組織成由包括功能點，工作程序和項目的單個實體組成的單獨組件，并由數據存儲區的單獨區域支持。當服務器接收到多個并發請求時，每個組件都能夠將請求處理到自己的狀態并與其他組件并行地更新其狀態，而無需創建競爭條件或資源競爭。
在 Web 應用程序體系結構中，傳統上認為客戶端是不受信任的，因為 Web 應用程序的任何用戶都可以編輯在客戶端上運行的代碼。相反，服務器被認為是受信任的，因為只有擁有服務器的應用程序開發人員才能更改在該服務器上運行的代碼。例如，惡意的眾包工人可能會編輯客戶端實現，以刪除項目的所有代碼，或者為自己提供更有利的活動歷史記錄。 為了防止此類攻擊，所有客戶端都必須通過服務器將所有更改提交給應用程序狀態，服務器會更新應用程序狀態并將更新發布到 NoSQL 數據存儲之前驗證請求的更改。將更新發布到數據存儲后，數據存儲將直接向客戶端廣播更新應用程序狀態，包括對版本控制系統和活動服務的更新。
5.評估
5.1 方法
我們招募了十四名參與者，他們在美國，阿根廷，巴西和葡萄牙進行遠程工作。 參加者是通過個人聯系招募的。 所有參與者都具有計算機科學相關學位，并且在 2 個月到 12 年的行業經驗之間，平均為 4 年。 所有參與者都有使用 JAVAScript 編程的經驗。 參與者獲得的時間補償為 100 歐元。
與實驗者的所有互動都是通過電子郵件和 IM 進行的，參與者之間的所有互動都是通過 CrowdCode 進行的。 我們將參與者分為兩組（A 組為 6 個，B 組為 8 個），以提供兩個觀察眾包人員工作并減少組間差異對結果影響的機會。 兩組都是從相同的參與者人群中招募的，包括不同專業水平的參與者。
在研究期間收集了幾種形式的數據。該服務器用于記錄對功能點的所有更改，生成，提交，跳過和重新發出的微任務，以及使用聊天功能的情況。為了記錄更多參與者互動的細粒度數據，捕獲了所有參與者的屏幕錄像。此外，參與者還完成了兩次有關其經歷的調查。在會議進行中，參與者完成了關于他們在微任務編程方面的經驗和挑戰的調查。 在會議結束時，要求參與者完成對他們的經歷的第二次調查。每次會話總共持續 5 個小時。
在每次會議開始時，通過電子郵件向參與者簡要介紹本研究的目的，要求安裝屏幕記錄儀，提供登錄 CrowdCode 的說明，并要求從登錄開始。 然后，在 CrowdCode 環境中為參與者提供了一系列教程，解釋了整個環境，并在他們處理新類型的微任務時介紹了每種微任務類型。 每個參與者都在自己的計算機上獨立工作。
每個會話中的參與者共同努力，為簡單的交互式繪圖應用程序的核心行為實現一個組件。功能集中于創建，操縱和渲染繪圖元素。特別地，功能集中于將指定為鼠標動作的用戶輸入轉換為圖形的基礎模型的更新，并根據圖形的模型生成渲染元素。該任務是通過客戶請求指定的，該客戶請求為四個函數（createElement，createAction，renderDrawing 和 moveElement）其中的每個函數都以注釋形式提供聲明和簡短描述。這些描述由描述這些函數參數的 ADTs 進行補充（元素，位置，分段和動作），以及每種 ADT 的幾個代表性示例。除了函數聲明，客戶端請求中未提供任何代碼。然后，根據此客戶請求，CrowdCode 會自動為四個功能中的每個功能生成兩個微任務：4 個編輯一個功能微任務和 4 個編寫測試用例微任務。參與者開始工作時，系統會自動為他們分配這些微任務之一。
5.2 結果
5.2.1 可行性
在兩次實驗過程中，參與者提交了 1,008 個微任務，并實現了總共 22 個功能，包括 8 個 API 函數（2 個會話中有 4 個函數）和 14 個從頭創建的函數。參與者的最終輸出包括 490 行代碼和 149 個單元測試和 2920 行代碼。參與者平均每個功能創建 7.8 個測試。創建的測試中有將近一半（47％）是針對 API 函數的 36％的功能，這可能是因為它們的復雜性更高或因為它們是第一位的。在這兩次實驗中，總共 70 個小時的參與者時間中，有 44 個小時花在了提交的微任務上（稱為“貢獻時間”）。參與者將最多的時間用于審閱微任務（37％），編寫測試微任務（22％）和編輯功能微任務（17％）。表 2 列出了每種微任務類型花費的時間。剩余的非貢獻時間用于閱讀研究材料，完成兩次調查，處理被跳過而不是提交的微任務，以及等待分配微任務。
提交的所有 1,008 個微任務由系統自動生成。 例如，圖 5 描繪了在過程 A 中為函數 createAction 生成的微任務。編輯函數并編寫測試用例反復生成，完成和檢查微任務，直到工作完成為止，并生成其他微任務以響應對附加功能的請求。虛線之前提交的最后一個微任務（“評審”微任務）導致功能轉換為已實現狀態，觸發了測試的執行，并為每個失敗的測試生成了單獨的“調試測試失敗”微任務。 其他功能的行為類似。功能有時會在已實現狀態和未實現狀態之間轉換多次。與會人員很少更改一旦定義的功能接口，在過程 A 中只有兩個更改而在過程 B 中只有零更改。
5.2.2 學習速度
登錄 CrowdCode 后，參與者首先閱讀簡短的教程，介紹微任務編程和平臺的基本用戶界面元素，然后分配他們的第一個微任務。 在這一點上，參與者經常花時間熟悉環境。 在某些情況下，參與者開始處理他們的第一個分配的微任務。 在其他情況下，參與者跳過了一些微任務，因為他們想在開始工作之前先研究幾種類型的微任務。 總體而言，參與者平均在 14 分 32 秒后提交了他們第一次完成的微任務。
參與者完成的第一批微任務通常是最具挑戰性的，因為他們了解了微任務編程的各個方面，例如偽代碼，請求功能和評論。 一份報告說：“一旦您已經開始完成一些微任務，這將非常容易。 乍一看，這可能有點奇怪，因為您的時間很少，但是您已經習慣于對其進行管理。” 評審微任務有助于發現早期微任務提交中的問題。 平均而言，首次提交的微任務的評分為 2.8，滿分為 5。78％的評分為 3 或更低，導致他們被重新發布給第二位參與者。
與其直接產生學習成本，不如將特定微任務的學習成本推遲到參與者首次遇到該微任務之前。 在這一點上，參與者再次需要學習新的微任務，從而浪費時間并降低質量。 在開始從事微任務之前，參與者首先閱讀了第二本特定于微任務的教程。 完成一種新的微任務將完成時間從 1 分鐘 31 秒的中值提高到 5 分鐘 29 秒，并且將質量得分的中位數從 5 分降低到 3 分。一位參與者報告說：“直到它完成，我才能理解每個任務 繞了幾次”和“剛開始時，一切都很混亂。 漸漸地我開始理解”。 另一個建議是，使他們能夠完成示例微任務的交互式演示微任務可能有助于加快學習速度。
隨著參與者通過會議獲得 CrowdCode 的經驗，平均評審分數趨于穩定之前趨于上升。 圖 6 描繪了帶有 10 分鐘時間窗口的移動平均評審得分。
5.2.3 貢獻速度
總體而言，工作人員能夠在 5 分鐘內的中位數時間內完成兩次實驗過程中的所有微任務類型（表 2）。 對于較大的微任務，例如“編輯函數”，“編寫測試用例”和“調試測試失敗”，完成時間更長，對于“寫入功能和調試測試失敗”，中值完成時間高達 4:57 或 4:00。 較短的微任務的平均完成時間低于 2 分鐘，包括重用搜索，編寫測試和評審。在所有情況下，中位完成時間都不超過十分鐘截止時間的一半。
參與者跳過了他們開始的所有微任務中的 13％。跳過的原因多種多樣。 在某些情況下，參與者跳過微任務，因為他們似乎無法完成它們。在其他情況下，參與者連續跳過幾個微任務只是為了在選擇開始時先探索可用的微任務類型。由于參與者在微任務上用完時間，系統自動跳過了微任務，占到了總跳過微任務的 17％。一些參與者感到有些倉促，特別是那些錯誤地認為微任務要求更多的參與者。“有時花十分鐘的時間讓我感到很急，尤其是當我不得不從頭開始編寫新功能并且必須閱讀并理解規格時。”
為了衡量參與者在貢獻代碼的微任務上的貢獻，我們計算了修改的代碼行數，包括添加，編輯和刪除的行。參與者平均添加了大約 3 行代碼，并分別刪除和編輯了大約 1 行代碼，平均修改了 5 行。
5.2.4 質量控制機制的作用
在實驗過程 A 和實驗過程 B 中，參與者都沒有時間在 5 小時的會議中完全實現這些組件。在每個實驗結束時，仍然需要進行其他工作以完全實現客戶端請求中指定的功能。為了評估參與者的總體進步和貢獻的質量，我們構建了一個測試套件（未提供給參與者），然后在每個實驗中編輯最終代碼，直到測試套件中的所有測試通過為止。在實驗 A 中，必須編輯貢獻代碼的 3％（7 行），并添加另外 3％（6 行）的代碼。這包括修復較小的拼寫錯誤（例如，添加數組索引，修復拼寫錯誤的變量名稱）以及實現參與者使用偽代碼繪制的幾行代碼。在實驗 B 中，必須編輯 12％（33 行）的代碼，并增加 25％（69 行）的代碼。增加的內容包括實現參與者創建但尚未實現的兩個功能。
在整個實驗期間，參與者反復實現和修改功能。個別功能經常反映出某些參與者的貢獻。 圖 7 描述了在實驗 A 中所做的實現貢獻。平均，大約 3 個工作人員為每個功能的代碼做出了貢獻，從而提高了工作人員對所生成代碼質量的認識。一位參與者報告說：“至少有三個人（通常是更多人）對每一部分代碼進行了檢查。我覺得效果很不錯。”代碼實現的貢獻通常代表了一個在之后仍然需要繼續貢獻的步驟。圖 8 描述了在會話 A 期間對函數 createAction 的三個貢獻。一個工作人員首先實現了該函數的一種情況，其余情況則保留了偽代碼。 在隨后的迭代中，一名工作人員重新處理了某些情況邏輯，另一名工作人員為其他情況實現了邏輯。
為了識別和糾正缺陷，參與者使用了測試和評審系統。工人平均每個功能執行 6.8 個測試。測試失敗時，將生成“調試測試失敗”微任務。測試失敗通常是由瓶邪錯誤，JavaScript 語法使用不正確，函數調用不正確以及錯誤實現的功能引起的。參與者的貢獻時間的 37％用于“評審”微任務。審查系統有助于識別缺陷，例如代碼中的拼寫錯誤，缺少測試用例，錯誤的測試以及對數據類型或功能的不正確使用。一位與會者指出，“您可以從別人指出的錯誤中學習，或者通過更好的方法來實現某一功能的相同目標”。
參與者使用問題報告系統來報告他們通過功能點的當前狀態確定的問題，從而確定了 63 個問題。 許多與過于模糊或自相矛盾的文字有關。 問題的最常見來源是“編寫測試”微任務，參與者報告了 43 個問題。 大多數是因為測試用例的描述不清或難以理解。 例如，實驗 B 的一位參與者報告說，“定義元素格式正確時，測試功能是否返回 true”的測試用例尚不清楚。參與者還報告了調試測試失敗微任務中的 13 個問題。 在發現代碼正確但測試錯誤之后，參與者使用問題報告系統報告測試中的問題。在 A 實驗中 11 次在 B 實驗中 1 次，眾包工人錯誤地解釋了功能規格。例如，在實驗 A 中，測試案例“創建了一個矩形元素，而前一個元素為矩形...”，因為“前一個元素僅用于 Freehand，而在其他情況下未定義”。通過問題報告系統，并沒有捕獲并標記對功能規范的所有不正確或不同的解釋。其他人只有在執行測試時才被捕獲，從而創建了調試測試失敗微任務來解決差異
