項目	內(nèi)容
這個作業(yè)屬于哪個課程	2023年北航敏捷軟件工程
這個作業(yè)的要求在哪里	個人作業(yè)-軟件案例分析
我在這個課程的目標是	學習并掌握現(xiàn)代軟件開發(fā)和項目管理技術，體驗敏捷開發(fā)工作流程
這個作業(yè)在哪個具體方面幫助我實現(xiàn)目標	從軟件工程角度分析比較我們所熟悉的軟件，以指導后續(xù)的軟工項目實踐

代碼倉庫管理系統(tǒng)有很多，他們對于你熟悉的目標用戶 （中國高校大學生）有什么缺陷和需要改進的地方，并且該如何改進？

本文上手使用并分析了兩個常見的代碼倉庫：Github 和 Gitee。

第一部分 調研，評測

Github

使用記錄

Github 首頁：

在個人主頁可以看到自己的所有倉庫：

可以在搜索欄使用過濾器語法搜索開源項目：

可以查看一個倉庫：

可以對某個倉庫提 issue（社區(qū)版 issue 界面）：

可以回復和 close issue：

綜合評價

優(yōu)缺點

首先從數(shù)據(jù)量/界面/功能/準確度多個維度，分析 Github 的優(yōu)缺點。

優(yōu)點：

• 用戶基數(shù)大！！！
  開發(fā)者可以在 Github 平臺上搜索到極為豐富的開源項目，單憑這一點就值得國內(nèi)程序員即使需要通過一些特殊手段上網(wǎng)也更青睞 Github。比如我最近的實習項目需要集成 remesh 功能到我司軟件，我在 Github 上搜索 remesh，從成百上千的倉庫中找到了正合我需要的幾何處理庫，而在 Gitee 上搜索該關鍵詞卻得到 0 條記錄。
• 搜索功能強大便捷
  搜索是 Github 核心功能之一，而 Github 的搜索欄支持過濾器語法，可按語言、倉庫、用戶、收藏數(shù)等條件過濾，我認為這是一件十分符合程序員直覺的事——我上一份實習就是在谷歌做支持過濾器和自動補全的搜索欄，谷歌自己內(nèi)部的代碼管理平臺也有非常完善的搜索功能。
• UI 設計舒適
  Github 的 UI 設計簡潔大方，（熬夜大戶程序員喜愛的）深色模式支持良好，能夠給與使用者愉悅之感。
• 豐富的第三方支持
  Github 有著良好的生態(tài)，支持豐富的第三方服務。

缺點：

• 國內(nèi)訪問不穩(wěn)定
  可能是對國內(nèi)開發(fā)者最不友好的問題。我們一定都體會過明明掛上了 ladder，卻還是 pull 不下來代碼，罵罵咧咧又打開 host 文件更新的經(jīng)歷。
• issue 和 pr 功能簡單
  社區(qū)版 Github 的 issue 不支持分級（P1/2/3…;S1/2/3）（企業(yè)版也沒支持這個），pr 不能開分支保護（企業(yè)版支持這個，對保護的分支合并必須要指定的 reviewer 審核）。WIKI 也是至少團隊版才能使用。但對于高校學生團隊來說，付費使用團隊或企業(yè)版是不必要的開銷。

改進建議

對于 Github 的改進建議，我作為個體用戶希望他們可以在社區(qū)版也可以引入更健全的 issue 和 pr 功能。但正如《構建之法》所說，軟件企業(yè)=軟件+商業(yè)模式，這也是商業(yè)模式的一部分。企業(yè)大概率不考慮采納這樣的建議。

綜合評價

總體而言，我對于 Github 給出 “e) 非常推薦” 的評價，鑒于它可以幾乎完全滿足個體開發(fā)者和中小型團隊的需求。

Gitee

使用記錄

進入 Gitee 首頁：

可以使用搜索欄搜索開源項目和博客：

在個人主頁可以看到自己的所有倉庫：

Gitee 支持從 Github 導入倉庫：

可以進入自己的倉庫進行查看和各種操作：

創(chuàng)建一個 pr：

審核并合并 pr：

綜合評價

優(yōu)缺點

首先從數(shù)據(jù)量/界面/功能/準確度多個維度，分析 Gitee 的優(yōu)缺點。

優(yōu)點：

• 國內(nèi)訪問穩(wěn)定
  快速穩(wěn)定的訪問，對比 Github，無疑是 Gitee 對國內(nèi)開發(fā)者最大的優(yōu)勢之一。特別是對于主要使用代碼管理平臺進行小組合作開發(fā)的高校大學生，Gitee 能夠提供較大便利。
• 良好的 issue 和 pr 使用體驗
  issue 支持分級；pr 支持指派負責人和測試人員；支持 issue 和 pr 關聯(lián)；區(qū)分只讀/保護/普通分支。以上功能（還有 WIKI）全部在免費版本就支持使用，與 Github 對比具有優(yōu)勢，大幅提升了用戶使用體驗。
• 豐富的第三方支持
  Gitee 也有比較豐富的第三方服務支持，主要來自國內(nèi)各廠商。并且 Gitee 支持一鍵導入 Github 和 Gitlab 倉庫。

缺點：

• 用戶基數(shù)有限
  即使 Gitee 將工作流實現(xiàn)得不錯，但用戶基數(shù)少是現(xiàn)實。能夠搜索到心儀的開源項目應該是代碼托管平臺（面對個人開發(fā)者）的殺手功能之一。但我認為這是“面對個人開發(fā)者”的，國內(nèi)中小企業(yè)和高校依然可以使用 Gitee 進行高效團隊開發(fā)。
• 搜索欄不夠便捷
  我不學 CS 的朋友們看到搜索欄可能想不到有什么過濾器語法，但我在一個代碼托管平臺一定下意識會使用過濾器的。很遺憾我在 Gitee 里并沒有體驗到這個功能。
• 不必要的外圍功能
  Gitee 支持賬號關聯(lián)博客，在搜索界面可以搜索到博文，并且推薦系統(tǒng)也會推薦博客。本人認為博客和推薦系統(tǒng)對于一個代碼管理平臺而言或許有些冗余。
• UI 設計擁擠
  部分源自上一條分析提到的原因，Gitee 的 UI 設計給我感覺有些擁擠?；蛟S從一進首頁看到側邊長長的推薦列表開始，我會有一瞬間的恍惚自己打開了 CSDN。
• CI/CD 收費
  可能不能算“缺點”，但窮學生很遺憾 Gitee 的 CI/CD 服務貌似是收費的。而對比之下， Github 社區(qū)版每月也有一定的免費使用時長。

改進建議

對于 Gitee 的改進建議，希望 Gitee 首先優(yōu)化一下搜索功能和 UI 設計吧。用戶基數(shù)問題或許不好解決。

綜合評價

總體而言，我對于 Gitee 給出 “d) 好，不錯” 的評價，鑒于它可以很好地滿足中小型團隊（包括學生團隊）合作開發(fā)的需求，但對個人開源愛好者可能略有不足。

用戶調研

我采訪了一位歐陽老師軟工班級的同學。該同學有一定使用 Github 的經(jīng)驗，但從未使用過 Gitee。作為計算機學院大三學生，ta 對于開源代碼管理平臺的需求主要是和同學進行合作開發(fā)，完成作業(yè)。我請這位同學用 10 分鐘快速體驗了一下 Gitee 的基礎功能，具體主要是瀏覽首頁及個人主頁、pull 一個開源倉庫到本地、push 一個個人倉庫到遠程。下面是同學分享使用感受（應同學要求已匿名）：

Bug 分析和提交

“選擇任意一個軟件（鼓勵大家選擇開源軟件），找出至少兩個功能性 bug…” 有這種事？那自然要選擇本人目前實習所在公司的產(chǎn)品 ZENO 了。
ZENO 是澤森科工創(chuàng)造的一個面向高性能物理計算而研發(fā)的可視化編程系統(tǒng)和平臺，一款全流程 3D 內(nèi)容生成開源工具。 用戶可以從官網(wǎng)或 Github 上下載發(fā)行版本或自行構建。
作為開發(fā)組實習生我顯然是使用自行構建版本，舉兩個最近發(fā)現(xiàn)的 bug。

依賴聲明有誤

測試環(huán)境

Ubuntu 20.04, gcc 9.4, CMake 3.18, CUDA 11.8，開發(fā)者自行構建版本。

bug 復現(xiàn)

在上述環(huán)境中穩(wěn)定發(fā)生。

bug 具體情況描述

編譯選項之一 -DZENO_WITH_CUDA，在滿足官網(wǎng)所聲明的依賴 gcc 9+，CUDA 11.6 的環(huán)境中編譯無法通過。（當時在視頻會議里展示的，沒有保留截圖。）

bug 分析

1. 推測成因：CUDA 優(yōu)化部分主要只由一個人負責，他自己的電腦應該配置了更高版本環(huán)境，無意中使用了新版本特性。
2. 嚴重性：一星。（假設五星為致命性系統(tǒng)故障、致命性安全性漏洞、用戶體驗嚴重影響；一星為無實際影響）因為使用者以及美術組員工均使用構建好的程序，不會每次從頭編譯；開發(fā)組員工基本也不會開和自己工作部分無關的 CUDA 選項。
3. 分析原因：沒有嚴格審查修復，主要因為軟件面向的用戶群體不需要用到這個功能，沒有必要。

bug 改進建議

應該調整代碼，使其能夠在官網(wǎng)聲明的依賴要求下正常編譯。

bug 反饋

跟大哥 1 on 1 時說了一下，大哥確實不知道，用了一分鐘看了一下編譯報錯然后表示這里需要 gcc 10 ，而他自己的機器確實是 gcc 10，驗證了我對于 bug 成因的猜想。

窗口點選崩潰

測試環(huán)境

Ubuntu 20.04, gcc 10.2, CMake 3.18, CUDA 11.8，開發(fā)者自行構建版本。

bug 復現(xiàn)

在上述環(huán)境中偶爾發(fā)生。頻率為：我每天進行 5 小時左右的開發(fā)，在經(jīng)常進行可引發(fā) bug 的操作前提下，大概每兩天遇到一次。

bug 具體情況描述

當節(jié)點圖較復雜，窗口顯示多個物體時，在進行一系列拖拽旋轉視角操作后，再點選物體，可能引發(fā)程序崩潰。
比如這樣的圖：

bug 分析

1. 推測成因：可能是顯存泄露。考慮到之前其它同事報過類似 bug，后來查明原因就是顯存泄露。
2. 嚴重性：二星。目前公司內(nèi)只有兩三個人的環(huán)境可能出現(xiàn)該問題，在大多數(shù)環(huán)境下程序能正常運行，并且發(fā)生頻率不高。而且即使 Microsoft Word 這種大軟件也不時崩潰呢，大家依然都喜歡用。
3. 分析原因：由于只有特定環(huán)境可以復現(xiàn)該 bug，負責該部分的開發(fā)者可能并沒有意識到存在問題。

bug 改進建議

應該排除代碼問題，提高軟件穩(wěn)定性，盡量降低用戶使用過程中軟件崩潰的概率。

bug 反饋

跟同事們說了一下，得知有一個美術組同事在我之前已經(jīng)提出了，相應開發(fā)組同事正在排除問題做修改。

題外話——歡迎使用 ZENO！

第二部分 分析

讓我們回到開源代碼管理平臺的話題上來。

工作量分析

我認為就基礎架構以及完善程度而言，兩個代碼管理平臺在常用基礎功能上應該是相近的，因此共同分析。
假如我們不考慮后續(xù)的第三方服務接入和軟件生態(tài)建立過程，僅考慮基礎功能的開發(fā)，并且假設我們擁有充足的資源支持……說個題外話，我覺得大學生的水平差異還是挺大的，我現(xiàn)任職公司的架構師是個雙非學校本科大四在讀生 geek 老哥，像一部行走的 cpp reference，其他語言也了解不少，能力不知道比我們這種忙忙碌碌卷畢業(yè)、去互聯(lián)網(wǎng)大廠老實寫幾年并不比培訓班出來的強多少的前后端、裁員首當其沖的 985 畢業(yè)生強到哪里去了。雖說我是搞圖形的，并沒打算去寫前后端。

還是試圖以北航比較優(yōu)秀的同學的水平估算一下時間：

1. 需求分析和設計（3 個月）：目前的需求比較清晰，也有現(xiàn)有的模型和解決方案作為標桿，但考慮到功能繁多，具體的架構設計還是需要一段時間的。

2. 技術選型和開發(fā)（2 年）：說實話我難以想象，至少我不相信我可以做到。首先需要和 git 對接，并實現(xiàn)網(wǎng)頁端的 git UI；需要實現(xiàn)網(wǎng)頁端的編輯器；需要對接 ssh；需要實現(xiàn) issue 和 pull request 功能；需要實現(xiàn)倉庫數(shù)據(jù)的可視化；需要對接 WIKI；需要實現(xiàn) fork ，release 功能，watch 和 star 就像是順手完成的了；需要實現(xiàn) sponsor 功能；需要實現(xiàn)關注和提示功能；需要實現(xiàn)個人代碼倉庫統(tǒng)計及可視化；需要實現(xiàn) CI/CD 功能；需要實現(xiàn)搜索功能——我大二暑假一個搜索功能實習做了三個月啊；還有不同權限用戶和不同收費標準版本……我覺得兩年是按照線性進度估計的，實際操作起來未必保持效率為常數(shù)。

3. UI 設計和調整（3 個月）：鑒于已經(jīng)有專業(yè) UI 團隊進行設計，我們這里只需要調整時間。但考慮到上述功能的復雜程度，我認為即使只是“執(zhí)行命令”式的調整也需要一段時間。

4. 測試和優(yōu)化（6 個月）：考慮到上述功能的復雜度，我認為在測試過程中應該會發(fā)現(xiàn)很多問題，問題的解決與后續(xù)優(yōu)化（加上解決優(yōu)化產(chǎn)生的問題）需要一定時間。

綜上，我估計 6 個北航本科優(yōu)秀畢業(yè)生全職搞 3 年也許能完成一個基礎代碼管理平臺的開發(fā)工作吧。在實際開發(fā)中上述四個過程應該不是依次而是循環(huán)出現(xiàn)的，以上估計數(shù)字大約是一個總數(shù)。

軟件質量分析

1. Github 以其完善的軟件質量和龐大的生態(tài)體系，兼有行業(yè)先手優(yōu)勢，無疑穩(wěn)位居同類產(chǎn)品之首。Gitee 作為中國內(nèi)地網(wǎng)絡情況下誕生的 Github 競品，也已經(jīng)擁有較高的產(chǎn)品質量，在國內(nèi)市場除去 Github 和 Gitlab 外，大概位居第一。

2. 對 Github 整體給予比較高的評價，如果要提建議大概是可以更加完善一些細節(jié)功能，全方位占領絕對行業(yè)優(yōu)勢；對 Gitee 的建議是，想要在 Github、Gitlab 已經(jīng)占據(jù)先手優(yōu)勢的市場中占據(jù)一席之地，不能僅做到模仿和跟隨，更好是要找到自己的獨特優(yōu)勢，打造產(chǎn)品亮點。

第三部分 建議和規(guī)劃

市場概況

• Github 和 Gitee 等代碼管理平臺的市場，主要由軟件開發(fā)行業(yè)從業(yè)者和計算機及相關專業(yè)學生構成。

• 直接用戶：軟件開發(fā)行業(yè)從業(yè)者。
  根據(jù) Statista 在 2021 年 1 月發(fā)布的統(tǒng)計數(shù)據(jù)，截至 2020 年底，全球軟件開發(fā)行業(yè)從業(yè)人數(shù)大約 2.45 千萬人，預計該數(shù)字到 2024 年底將達到 2.87 千萬。
  

• 間接用戶：計算機及相關專業(yè)學生。
  對于每年全球畢業(yè)生人數(shù)沒有找到比較可信的數(shù)據(jù)，但根據(jù)一篇印度報道引用的統(tǒng)計數(shù)據(jù)，印度每年產(chǎn)生最多的計算機專業(yè)畢業(yè)生（21.5 萬），緊隨其后的是中國（18.5 萬），其他大國還有美國（6.5 萬）、俄羅斯（1.7 萬）。估計全球每年 CS 專業(yè)畢業(yè)生至少 50 萬人。

市場現(xiàn)狀

• 目前市場上最主流的代碼管理平臺，大概全球范圍內(nèi)最流行的就是 Github 和 Gitlab，中國國內(nèi)最流行的就是 Gitee 了。

• Github 憑借其龐大的生態(tài)體系其位居同類平臺中的全球第一。除了 Github 以外，還有 Gitlab 同樣在全球范圍內(nèi)廣受開發(fā)者和特別是企業(yè)歡迎，企業(yè)可使用 Gitlab 搭建自己的私有倉庫，保障私有數(shù)據(jù)安全。但以上兩者由于網(wǎng)絡問題，在中國國內(nèi)都會遇到使用上的麻煩。Gitee 在國內(nèi)大約是除去 Github 和 Gitlab 之外最受歡迎的同類產(chǎn)品，但在國際范圍內(nèi)影響較小。
  Github 注冊數(shù)超 1 億：
  
  Gitlab 注冊數(shù)超 3 千萬：
  
  Gitee 注冊數(shù)超 1 千萬：
  

• 他們?nèi)卟糠种饕δ苤丿B，互為競品。但 Gitlab 一大特色應用場景為公司可獨立搭建私有代碼倉庫。而 Gitee 作為國內(nèi)產(chǎn)生的競品，就我作為個人使用者的體驗視角，其主要競爭者還是國際領頭羊 Github。（Github 的企業(yè)版我是使用過的；但Gitee 的企業(yè)版沒有嘗試，不甚了解。）

• 目前三者均呈上漲趨勢，對比往屆學長博客中引用的統(tǒng)計數(shù)據(jù)可以對比得到這一結論。雖然 Github 已經(jīng)較為成熟完善，難以做出改變適應新潮流，但憑借其強大的功能、龐大的生態(tài)，在短時間內(nèi)其領域領頭的位置不會改變。Gitlab 同理。Gitee 的主要賽道為國內(nèi)市場，其也不斷完善著對國內(nèi)市場的特色支持，用戶量上漲，但短期內(nèi)還很難撼動 Github 在國內(nèi)市場的地位。

市場與產(chǎn)品生態(tài)

• 核心用戶群正如前文分析，由軟件開發(fā)行業(yè)從業(yè)者和計算機及相關專業(yè)學生構成。
  列舉以下幾類典型用戶（以下人物在本人現(xiàn)實生活中均有原型）：

  1. 成鋒，30歲，國內(nèi) top 2 計算機專業(yè)本科畢業(yè)，某國際大型互聯(lián)網(wǎng)公司 dev，愛好周末騎公路車，每月穩(wěn)定收入 5 萬左右，需求是休息時間在開源代碼平臺上尋找和工作內(nèi)容相關的優(yōu)秀的開源項目，吸收借鑒到日常開發(fā)工作之中。
  2. 王壘，31歲，國外名校計算機專業(yè)博士畢業(yè)，某創(chuàng)業(yè)公司核心員工，公司主業(yè)務為打造一款開源軟件，愛好是看 c++ talk 和開發(fā)庫，收入隨公司項目拿獎金，好消息是公司一直都有項目，主要需求是利用企業(yè)版開源軟件管理平臺和同事合作開發(fā)，潛在需求是使用完善的 issue 和 pr 機制審核并通過同事代碼。
  3. 金眾，35歲，國內(nèi)某 985 計算機專業(yè)本科畢業(yè)，目前同時從事多份開發(fā)工作，愛好卻是作為獨立開發(fā)者貢獻開源代碼，收入成謎，收入合法性成謎，反正從來不缺錢，表面需求是利用開源代碼管理平臺托管自己的產(chǎn)品，潛在需求是給他人的倉庫提 issue 和開 pr，參與開源貢獻。
  4. 姜竹，20歲，計算機專業(yè)本科在讀學生，愛好是讀書，月收入只有 4 位數(shù)實習工資，表面需求是利用開源代碼管理平臺和同學合作開發(fā)完成軟工作業(yè)，以及學習他人的優(yōu)秀軟工項目，潛在需求是熟悉合作開發(fā)流程和代碼管理技術，為大四兼職更高薪實習做鋪墊。

• 典型用戶 2 和 3 也部分存在著典型用戶 1 的需求，典型用戶 4 可以成長為典型用戶 1 或 2 或 3。

• 對于同一個開源代碼管理平臺可能有多個版本，社區(qū)版的主要用戶可能是典型用戶 1 和 3；企業(yè)版的主要用戶可能是典型用戶 2；學生版（如果有）的主要用戶可能是典型用戶 4。面向學生的子產(chǎn)品可能為企業(yè)版或團隊版增加用戶，因為學生畢業(yè)后可能加入企業(yè)或創(chuàng)業(yè)。

產(chǎn)品規(guī)劃

• 我想加入書簽功能。即用戶可以通過點擊某行代碼左側來將其加入用戶在該倉庫的書簽。目前 Github 的瀏覽功能不是很友好，每切一個文件就要重新加載。但書簽功能再結合 Github 新的 code view——代碼左側文件樹，可以提高用戶瀏覽代碼的使用體驗。

  項目	內(nèi)容
  Need	目前 Github 的代碼瀏覽用戶體驗不佳
  Approach	加入書簽功能，用戶可以對重點代碼行做標記
  Benefit	改善用戶的代碼閱讀體驗，無需 clone 也可以快速理解倉庫代碼
  Competitors	大概沒有競爭者，相似功能的代替也只能是用戶 clone 到本地然后使用編輯器打開并添加書簽
  Delivery	憑借 Github 本身的流行程度普及這項功能

• 6 人角色與分工如下

  • 架構師 & 救火員： 1 人
  • 美工 & 前端開發(fā)：1 人
  • 前端開發(fā) & 測試：1 人
  • 后端開發(fā) & 測試：2 人
  • 測試 & QA：1 人

• 周數(shù)	任務
  1	需求分析，工作流確認
  2-3	技術棧確認，架構設計
  4-5	前后端框架構建
  6-8	具體開發(fā)，同時進行單元測試和每日構建測試，每個模塊加入總架構時進行集成測試
  9	alpha 測試，bug 修復
  10	beta 測試，bug 修復，總結反饋意見
  11-12	根據(jù)反饋意見修改產(chǎn)品，過程中做測試
  13	beta 測試，bug 修復，總結反饋意見
  14	根據(jù)反饋意見完善細節(jié)
  15	部署至生產(chǎn)環(huán)境
  16	產(chǎn)品上線