| 項目 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2021年春季軟體工程（羅傑 任健） |
| 這個作業的要求在哪裡 | 2021年軟工-個人閱讀作業#2 |
| 我在這個課程的目标是 | 初入軟體工程 |
| 這個作業在哪個具體方面幫助我實作目标 | 了解軟體開發的基本流程和團隊協作，了解 CI/CD 的使用與部署 |
第一部分：閱讀提問
比較粗略地閱讀完了《構件之法》，對于一款軟體的開發，對于一個團隊的形成，對于一款産品的釋出，算是有了一個大概的架構，有許多地方開闊了自己的眼界，打破了定式思維，比如一款軟體的開發需要大量的測試，不同次元的測試，采用典型使用者來确定軟體的開發目标等。
Q1：單元測試必須由最熟悉代碼的人來寫嗎？
“代碼的作者最了解代碼的目的、特點和實作的局限性。是以，寫單元測試沒有比作者更适合的人選了。”
——2.1.2 好的單元測試的标準《建構之法》
之前對企業招聘的崗位中的測試崗不是很了解，在查找相關資料的時候看到了這樣一則趣話：
- 一個測試工程師走進一家酒吧，要了一杯啤酒
- 一個測試工程師走進一家酒吧，要了一杯咖啡
- 一個測試工程師走進一家酒吧，要了0.7杯啤酒
- 一個測試工程師走進一家酒吧，要了-1杯啤酒
- 一個測試工程師走進一家酒吧，什麼也沒要
...
測試工程師們滿意地離開了酒吧
然後一名顧客點了一份炒飯，酒吧炸了
從這則趣話中，我們可以看出測試人員常常會因為因為軟體的适用範圍而局限了測試範圍，而使用者卻不一定會按照軟體的要求來進行操作，如果進行了要求之外的操作，沒有按照開發者的意圖來操作，往往很容易出 bug。
是以如果是代碼的作者來對代碼進行測試，會不會因為正是對代碼的目的、特性和實作有着充分的認知，才更容易導緻單元測試的局限性？
關于這點，我大概從第13章 軟體測試部分找到了答案。單元測試是對最基本的功能/參數上驗證程式的正确性，而像其他功能，會有場景測試，Alpha/Beta測試等來進行全面的測試，可能就不需要再單元測試中覆寫了？
Q2：充分授權和信任的邊界
“在一個高效的團隊中，所有的成員都應該能得到充分的授權，他們有權在職權範圍内按照自己的承諾完成任務，同時，他們也充分信任其他同僚能實作各自的承諾。”
——7.2.3 充分授權和信任《建構之法》
充分授權和信任固然是對人的自信和成長有着關鍵的作用，但是更經常存在的問題應該是人對自己的能力有着錯誤的估計（規劃謬誤），或許長，或許短地估計了自己對于項目的把控。
如果僅僅是根據團隊成員的自己承諾來充分授權，在一兩個成員沒有按照要求完成任務的情況下上司還是可以進行督促和幫助的；但若整個團隊都對項目有着錯誤的把握，那麼這種基于成員自己承諾和評估的授權和信任還是值得奉行的原則嗎？
我認為可能需要從第三方的角度來評估能力，并進行授權和信任，第三方可以是其他團隊開發的時間進度作為參考，也可以是長期與團隊成員合作後，他的進度完成達标率來作為參考，并且制定對應的規則和每周或者每日的名額，在充分授權和信任成員去獨自完成的同時，更需要定期的檢查或者對應的規則。
Q3：如何評價不符合“使用者滿意度-投資力度”曲線的産品？
“功能變好，使用者滿意度就高，功能品質和使用者滿意度有一個線性的關系...”
——8.5 功能的定位與優先級 《建構之法》
關于這類産品，我認為釘釘應該是一個比較典型的例子，使用的雙方一般在團隊中有着明顯的監管關系。對于産品本身的定位，是一個企業溝通軟體，這個産品友善了監管者對被監管者的管理，在這點上它做得很好；但是從另一方面來說，使用這款軟體的更多是普通的員工，也就是被監管者，在一些功能（如Ding功能，如果長時間沒有讀通知，那麼就會直接發送短信或者電話告知）做得更好，品質更高的同時，使用者的滿意度卻也更低了，更多的使用者的體驗沒有被考慮。
當一個産品是屬于“對立”雙方使用的時候，如何更好地去評價産品和産品的功能是否很好地服務了使用者呢？
Q4：顧客真的知道他們想要什麼嗎？
“MSF強調産品團隊與顧客的交流與合作，并不是産品團隊拿到合同之後，就閉門造車，直到産品完成才告訴使用者，給他們一個驚喜（通常“驚”大于“喜”）。”
——7.2.9 與顧客合作《建構之法》
顧客對于一款具體的産品，所能夠提出的需求一般是産品的基本功能，或者随着主流的功能，他們真的能夠提出“殺手功能”嗎？或者團隊将“殺手功能”與顧客交流時，他們真的能夠預見這個功能在未來的使用情況嗎？如果顧客對于此功能給予了否定的答案，産品團隊是否還要繼續開發這個功能？産品的“殺手功能”，産品的創新到底是顧客的需求作為主導，還是團隊的創新和嘗試作為主導？
Q5：結對程式設計在企業中是否真的有得到很好地應用？
4.5.4 如何結對程式設計《建構之法》
現在的開發流程已經有着完善的設計，開發，複審，測試等流程，結對程式設計是否是對測試（複審）部分流程的重複？并且企業需要高強度工作，也就是我們常說的996，已經有着如此重的開發任務，還讓兩個開發人員結對程式設計，是否會讓結對雙方更加勞累，這種開發方式是否已經不适用于企業中了？
第二部分：調研源代碼版本管理軟體
平台介紹
- Github
GitHub 是第一個供“用Git進行版本控制系統的軟體開發項目”使用的基于Web的代碼托管服務，是目前全球最大的開源社交程式設計及代碼托管網站。
- GitLab
GitLab 是一個利用 Ruby on Rails 開發的開源應用程式，實作一個自托管的 Git 項目倉庫，可通過 Web 界面進行通路公開的或者私人項目。
- Bitbucker
BitBucket 是 2008 年建立的源代碼托管網站，采用 Mercurial 和 Git 作為分布式版本控制系統，同時提供免費賬戶和商業計劃。
相同之處
三個平台都有提供關于團隊協作和項目管理的基本功能：
- 拉取請求
- 檢視分支之間的變化差異
- Markdown 編輯支援，内聯編輯，問題跟蹤等
- 支援豐富的第三方內建工具
- 一鍵合并和删除源分支
不同之處
- Github：是最流行的代碼管理工具，在上面有着全世界最大數量的公共開源項目，在上面可以搜尋需要的開源項目，用于私人項目托管的費用更貴
- GitLab：相較于 Github 和 Bitbucker 有着更少的内置內建，但是它是開源的，可以自定義代碼的任何部分，提供免費的私人代碼倉庫（隻有在團隊變得更加專業時才開始需要付費）
- Bitbucket：被 Atlassian 收購，與 Atlassian 的其他服務（Git GUI SourceTree、HipChat、Cloud）等順利內建，并在購買托管服務的方案中提供了産品定制功能，提供免費的私人代碼倉庫（隻有在團隊變得更加專業時才開始需要收費）
第三部分：調研持續內建/部署工具
1. Gitlab CI
使用了 OO 課程的第一單元的第一次作業作為實驗項目，配置 Gitlab CI/CD，進行了輸入輸出測試。
項目位址
.gitlab-ci.yml的配置如下：
image: local-registry.inner.buaaoo.top/image-dev/java:8u201
stages:
- build
- test
before_script:
- java -version
- javac -version
- mvn -v
mvn-build:
stage: build
script:
- echo "Build TAKS1 PROJECT"
- mvn compile
mvn-test:
stage: test
dependencies:
- mvn-build
script:
- echo "RUN TEST"
- cd target/classes
- echo "x**3+x**2" > test.txt
- cat test.txt | java task1.MainClass 2. Github Actions
使用了 OO 課程的第一單元的第一次作業作為實驗項目，配置 Gitlab Action，先進行了文法檢查，然後進行了輸入輸出測試。
name: deploy
on:
push:
branches:
- master
jobs:
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: Build Maven
run: |
echo "Build Project"
mvn compile
- name: Test Maven
run: |
echo "Test Project"
cd target/classes
echo "x**3+x**2" > test.txt
cat test.txt | java task1.MainClass 3. 使用CI/CD後的感受
- CI/CD 感覺類似軟體産品正式釋出前的一次檢查，在具體的配置情況下進行釋出測試，能夠更早地幫助開發者發現問題，降低修複問題的難度和時間
- 部署的每一個步驟都可視化，能夠更好地看到部署的具體細節
- 關于個人使用體驗，我覺得 Gitlab 的 CI/CD 需要指定鏡像，但是部署和測試的每一步都簡單清晰；而在 Github Action 上，在環境配置上更加便利，有着現成的環境可以直接調用，單隻在部署的步驟描述上相對麻煩。總體來說，二者在部署的流程上都很簡單，在使用上也十分友善
- 在使用的場合上，我覺得二者都比較适合中小型的項目部署測試，大項目不太适用于這種 CI/CD 的部署測試（從資源使用和花費的時間上來說）