2021軟工-個人閱讀作業#2

一、閱讀提問

問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：創新不必是領域內專家，關鍵不必是技術？

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

我們在這里看到，除了技術的創新，還有很多方面的創新：商業模式的創新，用戶體驗的創新，生態系統的創新，

這些迷思基本是以商業價值在衡量創新，如果很多企業都只安于跟上主流技術，一味追求這些模式創新，怎么解決相關市場的同質化問題，有熱度一窩蜂來，沒熱度一窩蜂去？如果都想做后來者，那誰還愿意承擔風險當實干者，這對社會的長遠發展是好是壞？埃隆·馬斯克為什么能成功？

二、調研源代碼版本管理軟體

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.總覽

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

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功能更全面，有里程碑設定，代碼評審和合并請求啥的...

標籤：其他

上一篇：Cypress UI/API測驗的使用參考

下一篇：Springboot集成flyway實作資料庫自動遷徙