陳丹，何鵬,2

(1.湖北大學計算機與信息工程學院,湖北 武漢 430062;2.湖北大學湖北省教育信息化工程技術研究中心,湖北 武漢 430062)

開源社區(qū)中開發(fā)者的commit提交行為挖掘分析

陳丹1，何鵬1,2

(1.湖北大學計算機與信息工程學院,湖北 武漢 430062;
2.湖北大學湖北省教育信息化工程技術研究中心,湖北 武漢 430062)

以Github開源社區(qū)為研究對象，分析社區(qū)中開發(fā)者在commit提交過程中的行為，探索開發(fā)者之間的交互關系.研究內容包括分析影響開發(fā)者提交行為的因素，探析commit的提交者與創(chuàng)作者關系,進一步分析commit的評論者的行為.研究結果發(fā)現：1)構建項目團隊的成員組織數不宜超過10，但開發(fā)者規(guī)?？梢赃m當擴大；2)項目commit的提交90%以上都以核心成員為主，未充分調動開源社區(qū)中廣大愛好者參與的積極性；3)參與一個commit評論的開發(fā)者數大多在5人以內，且參與同一個commit評論的開發(fā)者多來自不同的項目或組織.

開源社區(qū)；提交行為；軟件開發(fā)；開發(fā)者網絡

0 引言

隨著物聯網、云計算等應用技術的日益普及和廣泛使用，依托于社區(qū)化群體開發(fā)的各類虛擬社區(qū)開源軟件生產組織模式也得到了快速發(fā)展，人與人之間的社會關系分析也成為研究熱點.開源社區(qū)提供豐富的軟件自由下載，支持大眾參與到社區(qū)的開發(fā)中，也允許二次開發(fā)并按照相應的開源協(xié)議進行發(fā)布.隨著開源軟件的流行，人們愈發(fā)渴望理解開源社區(qū)中的諸多現象，如影響開源軟件成功的決定因素[1-2],開發(fā)者自愿參與的動機[3-4]，開源社區(qū)中影響開源軟件擴散的主要動力[5]，開源軟件開發(fā)者合作機制與合作意識[6]等.開源社區(qū)(如Github)作為一類典型的群體軟件開發(fā)社區(qū)，來自不同國家、有著不同背景的開發(fā)者通過加入社區(qū)與其他開發(fā)者互惠合作，強調源代碼免費、開放以吸引更多的人成為社區(qū)的參與者，積累下來的軟件數據與制品將成為社區(qū)的共享資源.

開源社區(qū)門檻低、源碼開放、自由參與等特征，便于大量的軟件開發(fā)者可以自由加入感興趣的項目當中去.但同時問題也隨之而來，很多開源社區(qū)上的開源軟件開發(fā)效率低下，軟件質量得不到保證.Github作為當今最為流行的軟件項目托管平臺，集版本控制、信息交流、代碼分析、團隊協(xié)作為一體.本文中以GHTorrent提供的Github社區(qū)數據(截止到2013年10月)為基礎，分析開源社區(qū)中開發(fā)者的commit提交行為以及影響其提交行為的因素，從而獲取開發(fā)者的典型提交行為模式.

以下內容的組織結構為：第1部分為相關研究工作的介紹；第2部分為相關理論基礎介紹；第3部分是研究方法及實驗數據分析；第4部分對于本文的研究結果及不足之處進行討論；第5部分為全文的總結與工作展望.

1 相關工作

目前為止，開源社區(qū)中關于開發(fā)者的角色、開發(fā)者之間的合作關系產生的動機以及開源軟件項目質量的影響因素等的分析已經引起廣泛關注，很多文獻都對此進行過分析與驗證.He等人[7]通過對SourceForge.net社區(qū)中開源軟件項目進行收集，在項目-管理者二分網絡基礎上構建管理者合作網絡模型，對管理者的度分布進行分析發(fā)現網絡呈現明顯的核心/邊緣結構.Robinson等人[8]利用序列挖掘方法對Github上124個項目進行挖掘，得到開發(fā)者活動的回歸模型，發(fā)現行為的變化與情緒變化的相關性.

Wang等人[9]通過分析Tomcat 6各個版本下開發(fā)者合作網絡中開發(fā)者的活躍度演化趨勢，提取出典型的角色演化模式，并且對比了不同演化模式下開發(fā)者在特定工作類型的貢獻程度.Choi等人[4]通過網上調查研究的方式獲得的結果表明開發(fā)者參與開源軟件項目開發(fā)的動機(如學習需求、興趣、與工作經歷相關等)的多樣化.Huang等人[10]根據開發(fā)者提交的日志信息，構建開發(fā)者-模塊網絡來描述開發(fā)者之間的交互，并建立LPP邊緣學習過程模型用于劃分開發(fā)團隊中成員的角色.Onoue[11]等人通過Github提供的APIs研究每個開發(fā)者產生的Github事件發(fā)現敏捷的軟件項目往往擁有多樣化的開發(fā)者，且這些開發(fā)者往往參與了不同類型的開發(fā)活動.

commit提交是開源軟件版本控制中的一個非常重要的操作.隨著研究者們研究的不斷深入，關于開發(fā)者commit行為的研究也逐漸涌現，Ma等人[12]調查了軟件開發(fā)者集體和個人提交commit的時間間隔，發(fā)現項目無論在整個生命周期還是每個版本中的commit提交時間間隔均大致滿足冪率分布，且大多數連續(xù)性commit提交到軟件庫的時間間隔很短，其中只有少數情況經過長時間等待.Yang[13]定義四個指標來衡量開發(fā)者提交行為和代碼演化規(guī)律，即每次commit的變化、提交commit的時間間隔、每次變化的提交作者和源代碼依賴，發(fā)現之前版本中對文件的更改可能會影響下一個版本，且修改“huge commit”所需的天數平均是普通commit的3倍.此外，一些研究者也嘗試通過commit行為本身的屬性去對軟件項目進行定量分析.如Hofmann[14]指出在軟件項目分析中提交的commit量是衡量對軟件貢獻度的一個重要指標，并設計算法計算commit的量.

此外，Cavrak[15]等人對分布式軟件開發(fā)者合作行為模式、動機和角色進行了分析，以便更好地理解分布式項目的開發(fā)動態(tài).Gharehyazie[16]等人針對Apache社區(qū)中開發(fā)者的技術貢獻和社會交互行為分析其是否適合作為一個committer角色.Zhou[17]等人對新成員如何在項目問題解決過程中體現自己的貢獻，從而提高他們在項目的影響力問題展開開發(fā)者行為分析.

綜上所述，開源社區(qū)中分析開發(fā)者個人角色及行為方面的研究層出不窮，但與已有工作不同，本文中將重點關注開源社區(qū)中開發(fā)者的commit提交行為，探索開發(fā)者在項目開發(fā)過程中，尤其是commit提交行為過程中不同開發(fā)者之間的交互關系.

本研究的貢獻主要為:

1) 與已有的文獻不同，本文中以整個Github社區(qū)中的項目開發(fā)者commit行為為切入點，探析開發(fā)者commit提交行為的潛在交互規(guī)律.

2) 分析影響commit提交行為的一些因素，并進一步探索commit的評論人之間的交互關系.

2 理論基礎

2.1 開源社區(qū) 開源社區(qū)又稱開放源代碼社區(qū)，是一個供廣大熱愛開源開發(fā)的開發(fā)者自由學習交流的虛擬平臺.本文中選取Github開源社區(qū)為研究對象，作為當今最為流行的開源軟件項目托管平臺，據統(tǒng)計該平臺已有超過1 200萬用戶和超過3 100萬個開源項目.Github為每個部署的開源軟件建立一個repository庫，用于存儲各種軟件開發(fā)數據，如項目成員信息、項目描述信息、項目缺陷修復信息、commit提交信息，以及commit評論信息，等等.

GitHub社區(qū)的獨特性在于從另外一個項目進行分支的簡易性.為一個項目貢獻代碼非常簡單：首先點擊項目站點的“fork”的按鈕，然后將代碼導出并將修改加入到分出的代碼庫中，最后通過內建的“pull request”機制向項目負責人申請代碼合并.因此，有人將GitHub稱為代碼玩家的MySpace.當文件修改到一定程度時，可以“保存一個代碼快照”，在Git中被稱為commit.一旦錯改或誤刪了文件，還可從最近的一個commit恢復.

本文的主要目標是挖掘分析Github社區(qū)中開發(fā)者的commit提交行為，所用到的數據主要涉及數據庫中的8張表，分別為users(用戶表)、projects(項目表)、project_members(項目成員關系表)、issues(問題基本信息表)、organization_members(組織成員關系表)、commits(提交信息表)、commit_comments(提交-評論關系表)、project_commits(項目-提交關系表).這些表之間的關系如圖1所示.

圖1 數據表關系圖

2.2 開發(fā)者提交行為 開源軟件開發(fā)是一個群體協(xié)作的過程，每個愛好者都可自由參與對項目的修改，并提交各自的問題解決方案.提交具體修改內容的開發(fā)者即為commit的author，而對諸多author提交的commit進行決策形成最終采納方案的開發(fā)者為committer.在項目的commit中，一些開發(fā)者既扮演author的角色又扮演committer的角色，且一個問題常需要多次甚至幾十次的修改討論后才能得到解決.

項目的開發(fā)者來自世界各地，他們彼此可能互不相識，一個開源項目的成員可由來自多個組織/團隊的人構成.一個項目中來自同一個組織的開發(fā)者的公司分布位置也可能不同，因此，項目成員來源的多樣性是否對開發(fā)者的commit行為具有影響，是一個值得探討的問題.

2.3 開發(fā)者評論行為 社會網絡主要研究在一定范圍內個體與個體之間的關系，網絡中的節(jié)點是個體，邊則是按一定方式定義的兩個人之間的交互關系.在軟件開發(fā)過程中，常根據存在交互的兩個開發(fā)者間建立合作連邊，構成一個開發(fā)者合作網絡.開發(fā)者對提交的commit內容會進行評論(comment)，利用開發(fā)者之間的相互評論關系，可構建一類開發(fā)者合作網絡.合作網絡中節(jié)點表示對commit做出評論的開發(fā)者，若開發(fā)者A對開發(fā)者B提交的內容進行了評論，則A與B之間被視為存在一條合作連邊.

對于一個項目的commit，對其進行評論的開發(fā)者是否主要為該項目的成員，即表現出項目內部相互討論的局面；還是更多評論來自非本項目的其他開發(fā)者，表現為外部群體貢獻.另外，從問題解決時間上，一個commit提交后，項目管理員可能還關心大致要多久或者經歷幾輪討論方能解決當前問題.研究開發(fā)者對commit的評論頻率、次數及相鄰兩次評論的時間間隔，有助于提高社區(qū)問題的解決效率.

3 實驗分析

3.1 數據 本文的實驗數據借助公開的GHTorrent API，獲取Github上開源項目開發(fā)數據.圖1為我們

表1 實驗數據統(tǒng)計信息

在數據收集過程中涉及的8張表的關聯關系.由于數據量的龐大，為了使研究結果更具有一般性，我們隨機選取其中的1 800個項目作為實驗對象，其中涉及的總開發(fā)者數是1 682個，一個項目成員最多為313個，最少1個，平均具有24.42個開發(fā)者；commit數據共 254 774條，對應的comment數據386 754條，詳細信息見表1.

3.2 開發(fā)者提交行為分析

3.2.1 影響開發(fā)者提交行為因素分析 首先，考慮到一個項目的開發(fā)成員可能由來自多個組織的開發(fā)者所組成，而一個項目中來自不同組織的兩個開發(fā)者之間交互效果可能比來自同一組織開發(fā)者的更差，從而影響開發(fā)者commit提交行為.為分析項目開發(fā)者的commit提交行為是否受該項目成員的組成關系影響，圖2給出了兩者之間的關系圖，結果顯示一個項目的開發(fā)者來自的組織越多，所需提交的commit數也越多.結果證實了不同組織的開發(fā)者之間交流不如相同組織成員之間高效，致使commit數變多.甚至，當組成項目團隊的開發(fā)者來自的組織數超過10時，有些項目的commit相比組織數更小的項目的commit數增加了一倍.

另外，我們也進一步分析了項目開發(fā)者的commit數與項目issue(issue主要指question、bug、enhancement)數之間的關系.根據圖3中給出的項目開發(fā)者提交的commit數與項目問題issue數之間的正相關關系，說明開發(fā)者的整體commit提交行為越頻繁，項目中issue數會越多.換句話說，開發(fā)者之間交流不暢在一定程度上會阻礙開發(fā)過程中開發(fā)者意見達成一致，從而影響項目開發(fā)質量.

圖2 開發(fā)者提交行為與organizations關系

圖3 開發(fā)者提交行為與issues數關系

圖4 開發(fā)者提交行為與團隊members關系

前面是從項目團隊的組織來源進行分析，我們也對社區(qū)中開發(fā)者的commit提交行為與項目參與成員規(guī)模之間的關系進行了分析.圖4顯示當項目團隊規(guī)模在26人以內時，項目開發(fā)者提交的commit數隨項目團隊規(guī)模增大而增多；然而，當項目團隊規(guī)模再增大時，開發(fā)者提交的commit明顯減少.該實驗結果表明：開源項目中并不是成員越多，他們之間的交互就越頻繁.小規(guī)模團隊之間交互頻繁，大團隊可能采取任務分工，因而局部成員之間的交互行為更緊密，這也是為什么規(guī)模大的項目開發(fā)者平均commit數變小的一個可能原因.

因此，開源軟件開發(fā)者的commit提交行為與成員的組織來源數和規(guī)模大小相關，整體上表現為項目成員的組織來源不宜過于分散，成員的規(guī)模可以適當擴大(超過26人).項目管理者可通過吸引更多與已有開發(fā)者來自同一個組織的其他開發(fā)者參與項目的開發(fā)，來提高項目的開發(fā)效率與質量.

3.2.2 commit的提交者與創(chuàng)作者關系以及他們在項目中的角色分析 開發(fā)過程中，先是開發(fā)者生成commit (這類開發(fā)者為commit的創(chuàng)作者author)，再提交給具有更高權限的核心開發(fā)者或管理員(這類開發(fā)者負責把收到的commit提交到軟件庫中，即為committer).因此，本節(jié)我們將重點研究分析commit的author和committer為同一個人和不是同一個人時，他們之間的關系情況.

我們分析了所有收集的commit數據，通過整理分析，發(fā)現項目commit的committer和author在大多數情況下是同一個人，其中author和committer是同一個人的commit數占90.2%的比例，而不是同一個人的commit數有54 211條.這說明大多數情況下，從事項目commit提交行為的開發(fā)者都是項目的核心開發(fā)者，僅有少量具有較低權限的邊緣開發(fā)者參與其中，這也間接反映了社區(qū)中在可供利用的人力資源基礎上調動的還不夠充分，還未能充分對群體智慧加以利用.

針對54 211條author和committer不是同一人的commit數據，我們按照以上兩類角色的開發(fā)者是否來自同一個項目和同一個組織進行分類.圖5顯示這些commit中author和committer來自不同項目的比例占84.5%，author和committer來自不同組織的比例占87.3%，而兩人來自于同一項目和同一組織的比例均不超過20%.另外，我們還發(fā)現即使兩個開發(fā)者來自同一個項目或同一個組織，但他們之間有共同參與commit提交的合作者比例也分別僅占0.03%和6.56%(見圖6).說明項目commit的author和committer之間往往沒有太多交集，但是卻能自覺地建立合作.

圖5 author與committer來自同項目或同組織的比例

圖6 author與committer有共同合作者的比例

由于committer一般為項目的核心開發(fā)者，author為外圍或邊緣開發(fā)者.因此，上述結果表明，絕大部分項目依舊還是其主要開發(fā)者在進行開發(fā)與維護，還沒有充分調動開源社區(qū)中廣大愛好者參與開源項目開發(fā)的積極性.

3.3 開發(fā)者評論行為 每個項目提交的commit數通常至少上百個不等，而每個commit的評論人數也各不相同，本節(jié)我們重點探討關于項目commit的評論行為.

首先，我們將commit的評論人劃分為3類：來自同一個項目(組織)、來自不同的項目(組織)、其他.根據圖7發(fā)現大部分commits的評論人是來自不同的項目(組織)、極少部分是來自相同項目(組織)的開發(fā)者之間交互，只占0.45%(8.26%)；而一個commit中參與評論的開發(fā)者既有一部分來自同一個項目(組織)，又有一部分來自不同項目(組織)的情況大約占四分之一.說明目前參與commit評論的人多是彼此之間素不謀面或者相互合作過的開發(fā)者.然而，通過對相鄰兩個評論人之間發(fā)表評論的時間間隔分析，圖8中我們可以看出大部分commit的評論在一個月內完成，超過一個月的比例僅占19.8%.并且我們對所有commits的評論人數進行統(tǒng)計分析發(fā)現大部分的commits的評論人在5個以內，只有少部分的項目commits的評論人超過24個.

圖7 commit的評論人同項目或同組織分配比例

圖8 commit的評論產生頻率

圖9 commit評論人構建的開發(fā)者網絡模型

其次，我們選取commit數為3 411的項目(proj_id=22980)作進一步分析，選取原因是該項目的開發(fā)者數適中且其commit數接近所抓取的項目commit數分布的中位數，具有一定的代表性.我們利用網絡可視化軟件Gephi對該項目下的一個commit(commit_id=124 678)的全部評論人(共123人)建立合作網絡模型(見圖9).其中節(jié)點代表對commit進行評論的評論人，節(jié)點之間的邊則說明兩個開發(fā)者之前有過共同評價.由圖9可見123個評論人中，合作緊密程度并不大，主要以兩個評論人為主，存在大量只是參與此次commit的評論但跟其他評論人沒有交互經驗的開發(fā)者.

實驗結果表明：整體上commit的評論人在5個以內，且參與同一個commit評論的評論人大多來自不同的項目或組織，這些人之間有關聯的占少數，表現出群體交互還不夠緊密.

4 討論

本文中對開源軟件項目開發(fā)者的commit提交行為進行了挖掘分析，得出了一些結論，如開發(fā)者的commit提交行為受成員的組織來源和規(guī)模大小的影響，commit的author和committer通常都是同一個人，評論人之間的聯系不夠緊密，等等.然而，本文也存在著以下不足之處.

首先，我們選用作實驗的數據為2013年10月以前抽取的數據，目前GHTorent項目中數據已更新到2016年，提供的數據表中還包括其他信息，如項目的編程語言、里程碑(milestone)、用戶的關注者(watcher)，以及issue的評論等.這些信息目前我們都沒有考慮，主要是出于數據量的處理問題，毫無疑問在后期的工作中我們將對這部分信息進行進一步分析利用.

其次，在3.2.1節(jié)中分析項目開發(fā)者的commits數與成員的組織數之間關系時，圖2中橫坐標設置為20以內，根據對數據的統(tǒng)計發(fā)現，平均每個項目的開發(fā)者數不超過25個，且只有少數的項目開發(fā)者數比較多，所以我們僅考慮那些開發(fā)者來源組織數不超過20的項目是具有一定的代表性的.

目前較為流行的開源社區(qū)除Github之外，還有Sourceforge、Rubyforge、Google code等.本文中以Github社區(qū)為研究對象，除了因為該社區(qū)提供了大量的數據集，其知名度更廣也是一個原因.我們選用該社區(qū)進行分析，相信我們的結論在其他社區(qū)中大體一致.

5 總結與展望

本文中主要圍繞開源社區(qū)中項目開發(fā)者的commit提交行為進行了挖掘分析，分析了影響開發(fā)者commit提交的因素、commit的提交者與創(chuàng)作者關系分析，以及commit的評論者之間的交互關系.研究發(fā)現：1)開源項目在招募開發(fā)者時因考慮成員的組織來源不宜太分散，但規(guī)模可以適當擴大；2)大多數項目的commit提交主要來源于少數核心成員的貢獻，對社區(qū)中廣大愛好者的參與積極性調動不夠；3)整體上參與commit評論的開發(fā)者并不多，且參與同一個commit評論的評論人多來自不同的項目或組織.

我們的工作為開源社區(qū)中項目成員的招募與推薦提供了一定的指導依據，但正如前面討論部分所提到，Github社區(qū)中還提供了更多豐富的數據，所以還有很多有價值的工作等待我們去挖掘.在下一步工作中，我們將根據得到的分析結果對開發(fā)者提交的commit及時推薦評論者，幫助軟件高效開發(fā)，提高軟件開發(fā)質量.

[1] Lee S, Kim H，Gupta S. Measuring open source software success[J].Omega, 2009, 37(2): 426-438.

[2] Crowston K, Annabi H, Howison J. Defining open source software project success[C]//Proceedings of the 24th International Conference on Information System，New York,USA,2003:327-340.

[3] Roberts J, Hann I, Slaughter S.Understanding the motivations, participation, and performance of open source software developers: a longitudinal study of the apache projects[J].Management Science，2006,52(7):984-999.

[4] Choi N, Pruett J.The characteristics and motivations of library open source software developers: an empirical study[J].Library & Information Science Research,2015,37(2):109-117.

[5] Whitmore A, Choi N, Arzrumtsyan A. Open source software: The role of marketing in the diffusion of innovation[J].Information Technology and Control,2015,38(2):91-100.

[6] He P, Li B, Yang X，et al.Research on developer preferential collaboration in open-source software community[J].Computer Science，2015,42(2):161-166.

[7] He P, Li B, Pan W，et al.Centrality analysis of the manager collaboration network in open source community[J].Journal of Chinese Computer Systems,2013,34(1):161-166.

[8] Robinson W,Deng T,Qi Z.Developer behavior and sentiment from data mining open source repositories[C]//49th Hawaii International Conference on System Sciences，Koloa, HI, 2016:3729-3738.

[9] Wang W, Li B, He P. An analysis of the evolution of developers’ role in open-source software community[J].Complex Systems and Complexity Science,2015,12(1):161-166.

[10] Huang S,Liu K. Mining version histories to verify the learning process of legitimate peripheral participants[J].ACM SIGSOFT Software Engineering Notes, 2005,30(4):1-5.

[11] Onoue S, Hata H, Matsumoto K. A study of the characteristics of developers’ activities in github[C]//Software Engineering Conference,2013 20th Asia-Pacific，Bangkok,2013:7-12.

[12] Ma Y, Wu Y, Xu Y.Dynamics of open-source software developer′s commit behavior: an empirical investigation of subversion[C]//Proceedings of the 29th Annual ACM Symposium on Applied Computing，New York, USA, 2014: 1171-1173.

[13] Yang W,Shen B,Xu B.Mining GitHub: why commit stops-exploring the relationship between developer’s commit pattern and file version evolution[C]//Software Engineering Conference (APSEC), 2013 20th Asia-Pacific，Bangkok,2013:165-169.

[14] Hofmann P, Riehle D. Estimating commit sizes efficiently[M].Open source ecosystems: diverse communities interacting，Berlin：Springer Berlin Heidelberg,2009:105-115.

[15] Cavrak I, Orlic M, Crnkovic I. Collaboration patterns in distributed software development projects[C]//Software Engineering (ICSE), 2012 34th International Conference on，Zurich,Switzerland,2012: 1235-1244.

[16] Gharehyazie M, Posnett D, Vasilescu B, et al. Developer initiation and social interactions in OSS: A case study of the Apache Software Foundation[J].Empirical Software Engineering, 2015, 20(5): 1318-1353.

[17] Zhou M, Mockus A. Who will stay in the floss community? modeling participant’s initial behavior[J].Software Engineering, IEEE Transactions on, 2015, 41(1): 82-99.

(責任編輯 江津)

Analysis of developers’commit behaviors in open-source software community

CHEN Dan1, HE Peng1,2

(1.Faculty of Computer Science & Information Engineering,Hubei University,Wuhan 430062,China;
2. Hubei Province Engineering Technology Research Center for Education Informatization(Hubei University),
Wuhan 430062, China)

We takes Github community as the subject, and mainly focuses on developers’ commit behaviors and their interactions during this process. The contents are comprised of analyzing the factors that may affect developers’ behaviors, studying the relationship between commits’ committers and authors, and exploring developers’ comment behaviors. The results show that 1) for an open-source project, the number of organizations its developers belong to should not be more than 10, but the scale of developers can be appropriate to expand. 2) More than 90% contribution to the commits is from mostly central developers, the participation degree of the majority of developers in the community is still not fully motivated. 3) The number of developers involved in the commits’ comment is not more than 5, and they are often from different projects or organizations among the developers.

open-source community; commit behavior; software development; developer network

2016-11-17

國家973重點基礎研究發(fā)展規(guī)劃項目(2014CB340401),國家自然科學基金(61273216),湖北省重大科技創(chuàng)新計劃(2013AAA020),武漢市青年科技晨光計劃(2014070404010232)和湖北大學青年自科基金資助

陳丹(1992-)，女，碩士生；何鵬，通信作者，講師， E-mail:penghe@hubu.edu.cn

1000-2375(2017)02-0176-07

TP301

A

10.3969/j.issn.1000-2375.2017.02.014