2021軟工-我的閱讀做業#2

項目	內容
這個做業屬於哪一個課程	2021春季計算機學院軟件工程(羅傑 任健)
這個做業的要求在哪裏	我的閱讀做業#2
我在這個課程的目標是	和個人團隊開發一個真正的軟件，一塊兒提高開發與合做的能力
這個做業在哪一個具體方面幫助我實現目標	閱讀教材提煉所思所惑；初探Git / CI / CD相關工具

1、閱讀提問

---

問A：結對編程總能作到1 + 1 > 2 嗎？

教材中第四章出現告終對編程(Pair programming)，這是一種變態的代碼複審，有別於傳統的Code Review。書中強調"複審的目的在於糾錯改進與教育更多的開發人員"，隨後在4.5.3節說到Pair中兩人對程序深刻了解，複審效果好。但代碼複審包括具體代碼、效能、設計規範等多方面，Pair中有時間像Code Review同樣周全的考慮嗎？在傳授經驗這個方面，Pair中比較多的也是口頭交流吧，那麼有些經驗不就只停留在兩人之間了嗎？當開發想到一個新idea，爲何不造成書面形式在Code Review中「讓更多的成員熟悉項目各部分的代碼」？爲何想着不間斷地複審而不去花時間提升團隊Code Review的效率？

在團隊中，開發者是人而不是工具，合體以後就必定能1 + 1 > 2嗎？書中提到:

極限編程對工程師提出了更高的要求。這種要求不關乎技術水平，也不關乎學歷水平或工做經驗。這張要求是對一我的的心智、道德修養的更高要求。結對編程中，編碼再也不是私人的工做，而是一種公開的「表演」。 (4.5.3節-不間斷地複審)

Pair對技術力也有要求，不熟悉技術的兩人進行Pair只能是一齊學習。文中將Pair的漸進的成長過程比做雙人舞的各個階段，但實際中Pair是否會由於對人的要求過高而停滯在某一階段，Pair的普適性何如？

4.6節也談到了合做之道，說到底結對編程仍是交流的藝術，可否高效快速解決問題仍是得靠實踐出真知吧。

問B：代碼測試中覆蓋率要達到100%嗎？

教材在2.1.2節-好的單元測試的標準中有提到:

單元測試應覆蓋所測單元的全部代碼路徑，包括錯誤處理路徑。爲了保證代碼覆蓋率，單元測試必須測試公開的私有的函數/方法

...

要注意：100%的代碼覆蓋率並不等同於100%的正確性

那我想反過來問：實際中代碼覆蓋率必定要達到100%嗎？從投入產出比的角度考慮，覆蓋率達到100%勢必要更多地考慮瑣碎的問題，覆蓋率不錯的狀況下邊際收益豈不是降低了？或者說，實際測試中是否是應該搞雙標，僅對更核心的模塊代碼做更全面的測試覆蓋來保證工做效率？更重要的是，100%的代碼覆蓋率並不說明代碼正確，我認爲覆蓋率是一個基本指標，而不是目標。全覆蓋的測試不必定考慮全了外部的問題，好比特殊的輸入值，I\O中的File Not Found，這些都是難以發現的隱患，因此測試用例是否是應該從場景出發，更多地考慮程序功能與邏輯上的完備性呢？

問C：敏捷開發？

衝刺到一半的時候，產品負責人忽然要立刻作重要的改動！或者某個大佬要看某個不在計劃中的功能的演示，怎麼辦？種種狀況很是考驗Scurm Master

...

也要等到衝刺完了再說啊！ (6.2節-敏捷流程的問題和解法)

根據敏捷的價值觀，對於執行原定計劃更傾向於響應變化，並與客戶合做。因此在衝刺中產生新的需求不該是常態嘛。真有重要變化時，爲何不在Scrum Meeting中一齊討論此改動的重要性和急迫性再考慮進不進行工做上的調整？既然每次新的需求產生時均可能波及到系統中多個模塊，或者是如今徹底沒有考慮的優化方向，那麼有時重構不可避免，拖到Sprint結束會不會致使問題積壓，錯太重構的黃金時間，Sprint中的安排不可改變嗎？

敏捷中的產品Backlog究竟是什麼樣的呢？它的主要表現形式爲用戶故事。

用戶故事是描述對用戶有價值的功能，一個好的用戶故事應該包括角色、功能和商業價值三個要素。

1. 角色：究竟是誰要使用這個功能，這個功能是爲誰而設計的？
2. 功能：這個功能是怎樣的，要達到什麼程度？
3. 商業價值：爲何要這個功能，這個功能最後能帶來什麼有益的商業價值，對用戶來講有什麼意義？

敏捷還強調我的和交流，這在小團隊很奏效，團隊規模大了之後難以保證高效的交流。並且相比傳統的軟件開發模式不重視正式的文檔，這在團隊工做交接的時候會不會有困難，敏捷開發中怎麼將一個項目作大作長遠？

問D：寫不出好代碼的PM是好PM嗎？

書中9.4節關於一個PM(Program Manager)的自我修養:

專業能力：PM一般也能寫代碼，能玩轉Excel, PPT, Visio, 甘特圖，有文字功力...

既然PM要作其餘的那麼多事情，那麼對TA的代碼能力有要求嗎，要求多好呢？我認爲PM應該作到的是對開發使用的技術路線與架構有個基本的認識，才能更合理地評估某一功能開發的難度，這樣能夠避免異想天開的設計，也更方便與開發者交流。在這個回答中微軟的答主也說到:"雖然理論上程序經理並沒必要然是程序大拿，但我見過的不少微軟的程序經理都是開發轉過來的，技術實力並不比同組的開發弱。...不多能看到諸如藝術類專業出身的人作程序經理的狀況。"

問E：創新沒必要是領域內專家，關鍵沒必要是技術？

迷思之六：技術的創新是關鍵

咱們在這裏看到，除了技術的創新，還有不少方面的創新：商業模式的創新，用戶體驗的創新，生態系統的創新。

這些迷思基本是以商業價值在衡量創新，若是不少企業都只安於跟上主流技術，一味追求這些模式創新，怎麼解決相關市場的同質化問題，有熱度一窩蜂來，沒熱度一窩蜂去？若是都想作後來者，那誰還願意承擔風險當實幹者，這對社會的長遠發展是好是壞？埃隆·馬斯克爲何能成功？

2、調研源代碼版本管理軟件

---

1.基於Git的項目管理工具

a) GitHub

Github是現今世界上最大的同性交友網站，兼最火的開放源代碼與代碼託管社區。被微軟收購後，Github已經在去年免費開放了私有庫全部功能來對標Gitlab，好耶。Github做爲開山者先入爲主，用戶基數大，社區建設也是最久的，因此要作開源項目的話，它必定是首選啦。後面的代碼託管平臺基本都有具備Github的基本功能:Fork \ Pull Request \ Follow \ issue之類的。

b) Gitlab

GitLab 是一個基於Git的倉庫管理系統的開源項目，並在此基礎上搭建web服務。GitLab CI/CD 是 GitLab 內置的一款工具，易於實現持續集成，持續交付，持續部署的pipeline。GitLab 支持開發團隊對其所轄倉庫擁有更多的控制，因此從代碼的私有性上來看，GitLab 是一個更好的選擇。

c) Gitee

Gitee(碼雲)是國內規模最大的代碼託管平臺哦。相比於其餘平臺，Gitee訪問速度更快更穩定，不會由於某些神祕的緣由登不上去。Gitee在開源倉庫方面差很少是在模仿Github，功能齊全。但感受Gitee比較注重本地化與社區，其目標用戶主要是企業或團隊，相應的有小隊和任務的功能。持續集成方面也有推出正在內測中的Gitee Go

d) Bitbucket

BitBucket 是 2008 年建立的源代碼託管網站，採用 Mercurial 和 Git做爲分佈式版本控制系統，同時提供免費帳戶和商業計劃。主要面向慈善企業和企業用戶/其主要市場是大型企業。

2.總覽

工具名	建立時間	使用人數	項目數	私有倉庫	適用範圍	CI / CD	用戶界面	備註
Github	2008	3100w	10000w	免費，無合做人數上限	全球性開源	支持	簡明乾淨，用着最習慣	最大的開源代碼平臺
Gitlab	2011	3000w	54w	同上	企業、學校等內網Git私服	支持	功能劃分清晰	自託管的 Git 項目倉庫
Gitee(國內)	2013	600w	1500w	免費，最多5人合做	全球性開源	開發中	相對比較亂	針對國內用戶的代碼託管方案
Bitbucket	2008	500w	???	同上	企業/團隊Git私服	支持	很乾淨，喜歡	爲專業團隊而生，"code, manage, collaborate"

3、調研持續集成/部署工具

---

1. GitLab

以oo2020_pre3_task3爲例，倉庫在這裏，用的是樣例中的.gitlab-ci.yml哦，去掉only: tags，否則只有有tag的commit才能觸發pipeline。

Gitlab的CI / CD控制檯，第一個stage:

第二個stage:

爲了得到代碼的測試覆蓋率使用了maven插件:jacoco-maven-plugin，配置在mvn test執行時自動執行mvn jacoco:report。用Stackoverflow上面的方法，從生成的csv中提取出總代碼覆蓋率，設置coverage正則表達式

mvn_test:
  stage: test
  dependencies:
    - mvn_build
  script:
    - echo "------Run JUnit4------"
    - mvn clean test
    - awk -F"," '{ instructions += $4 + $5; covered += $5 } END { print covered, "/", instructions, "instructions covered"; print 100*covered/instructions, "% covered" }' target/site/jacoco/jacoco.csv
  coverage: '/\d+.\d+ \% covered/'

再在Gitlab -> project -> Setting -> CI / CD -> General pipelines settings 找到badge的.md，就可動態顯示coverage了，好耶。

2. Github Actions

Github上使用這個倉庫, 配置yaml:

name: my CI test
on: push
jobs:
  job_build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: check
      run: |
        java -version
        javac -version
        mvn -v
    - name: build
      run: |
        mvn compile
...

Github Action裏一個.yml對應一個頂級元素workflow，它和Gitlab裏的pipeline差很少哦

workflow包含多個job，即不一樣階段，用need字段肯定執行次序。

每一個jobs還分爲多個step，step裏纔是執行的腳本。這一點很好，在控制檯能夠看到不一樣step的輸出信息

固然Github Action有很多開源的Action，直接在step裏用uses指明Action的倉庫名就能直接用了，上文的.yml就用Action安裝了Java環境

3. Gitlab vs. Github Actions

CI / CD主要的工做是自動化單元測試、在QA的類生產環境中自動化集成測試，okay就自動部署到生產環境，這對於敏捷開發而言很舒服。對於下一個可交付的版本，不用再去浪費時間人工操做了。在提升開發效率的同時，你們也都能在倉庫中瞭解當前版本的問題。

上面兩個工具只是稍微嘗試了一下，總的說來Github Actions用的是遠程的服務器，跑起來更快；Github Actions具備Github開源的主要特徵，有很多Action可供調用，但用起來總不夠靈活，Gitlab的腳本結構更清晰，編寫起來容易；Gitlab CI / CD功能更全面，有里程碑設置，代碼評審和合並請求啥的...