| 項目 | 內容 |
|---|---|
| 這個作業屬於哪個課程 | 2021春季軟件工程（羅傑 任健） |
| 這個作業的要求在哪里 | 個人閱讀作業2 |
| 我在這個課程的目標是 | 認識軟工，擁抱軟工，提升相關能力以便日后與其朝夕相伴 |
| 這個作業在哪個具體方面幫助我實現目標 | 於《構建之法》中理解軟工，於實際應用中理解CI/CD |
一、閱讀提問
1.什么是Bug？
原文參見《構建之法》第1章第2節
什么是Bug呢？簡單地說，軟件的行為和用戶的期望值不一樣，就叫Bug。例如，某聊天軟件啟動時就崩潰了，用戶期望這個聊天軟件不能崩潰。例如，某聊天軟件不支持視頻聊天，用戶期望這個聊天軟件支持視頻聊天。但是該軟件的開發人員說，這個軟件根本沒打算支持視頻聊天。
相應問題：
-
如果不同用戶的期望值不相同，此時如何比較軟件的行為和用戶的期望值？“不一樣”從何談起？
-
如果軟件行為因為商業盈利而沒有達到（或有損於）用戶期望，也算作Bug么？
-
軟件的行為是否一定要追求和用戶期望保持一致呢？
個人理解：
- 比如微信上線的“拍一拍”功能，上線后用戶體驗有褒有貶，有的人認為很有趣，增加了互動的方式；有的人則認為毫無增益，十分反感，那么此時可以說明“拍一拍”功能是Bug么？筆者認為不能單純地以軟件行為與用戶期望值是否一致判定是否為bug，軟件的一些基礎功能（大部分用戶都有相應的期望值的功能，比如書中的啟動崩潰的例子）應當毫無疑問地達到用戶的期望值，而軟件的一些擴展功能（比如“拍一拍”）應當秉持“風物長宜放眼量”的態度，不能因為不能達到大部分用戶的期望值就過分苛責軟件的行為，當然軟件行為也不能因為存在部分用戶的肯定而忽視批評的聲音，兩者應當是不斷磨合的關系（比如后續增加了“拍一拍”撤回的功能，反感的用戶也逐漸適應並使用拍一拍功能），只有彼此的正向反饋才能促進軟件的發展和提升用戶的體驗。
- 比如大部分用戶都期望看視頻的時候沒有廣告，但是各類視頻軟件都不約而同地為了盈利投放廣告，此時軟件的行為與用戶的期望值並不相符，也並不能算作軟件的Bug，畢竟如果軟件完全以用戶期望為導向，而不考慮自身生存，可能軟件本身便會不復存在了，所以筆者認為軟件開發設計的導向應當不僅僅局限於用戶需求，應當綜合多方面的因素和考量。
- 在觸摸屏誕生之前，大部分用戶對手機的需求（期望）恐怕仍然停留在希望按鍵手機有更多的功能，可以更加好用吧，所以有時用戶的期望存在一定的局限性，但同樣不可否認的是，正是少部分用戶的需求推動了硬件或軟件的發展，進而拓展了大部分用戶的期望空間，所以如果置身於歷史的長河中，軟件的行為和用戶的期望更像是一種交替前進的狀態，並不是單方面的追求，而是攜手共進，此時再回首看一看那些“Bug”，不過是一朵朵浪花罷了。
2.單元測試
原文參見《構建之法》第2章第1節
單元測試必須由最熟悉代碼的人（程序的作者）來寫。代碼的作者最了解代碼的目的、特點和實現的局限性。所以，寫單元測試沒有比作者更適合的人選了。
相應問題：
如果程序的作者在程序的設計實現階段便忽略了對某些情況的考量，此時再由作者構造單元測試，是否仍然不能注意到這些在程序設計實現上的漏洞呢？
個人理解：
雖然程序的作者最為熟悉自己的代碼，可以較快地構造出對應的單元測試，但是這些單元測試只能保證當前已經實現程序的正確性，並不能說明當前的程序設計是完備的，如果此時由他人構造一些單元測試，則有可能發現程序本身的漏洞，才可以讓程序盡可能的完備。
3.goto的使用
原文參見《構建之法》第4章第3節
函數最好有單一的出口，為了達到這一目的，可以使用goto。只要有助於程序邏輯的清晰體現，什么方法都可以使用，包括goto
相應問題：
goto是否能有助於程序邏輯的清晰體現
個人理解：
從1968年的一篇名為《 Go To Statement Considered Harmful》的文章，作者Edsger Wybe Dijkstra提出不加限制地使用GOTO語句應當從高級語言中廢止，因為它使分析和驗證程序正確性（特別是涉及循環）的任務變得復雜，到現如今程序語言的教學中不推薦使用goto語句，這一切已然可以說明在程序中不寫goto語句是一份共識，那么再在程序設計實現時使用goto則可能影響團隊中他人對代碼的理解，對他人而言並不是一種程序邏輯的清晰體現，反而影響團隊的開發效率。
4.結對編程
原文參見《構建之法》第4章第5節
結對編程中駕駛員和領航員的角色要經常互換，避免長時間緊張工作而導致觀察力和判斷力下降。
相應問題：
駕駛員和領航員不應當是各有所長、各司其職么？如果互換的話，會不會不能達到開發效率的最大化？
個人理解：
結對編程的兩位程序員存在水平上的差距，程序員A可能更擅長架構設計或構造測試，程序員B可能更擅長代碼實現，因而存在駕駛員和領航員兩種角色，如果結對編程追求的是1+1>2的效果，那么角色互換則可能讓兩者在並不擅長的領域內工作，無法達到提升項目質量、提高開發效率的效果。
5.蘿卜與白菜
原文參見《構建之法》第17章第4節
由於蘿卜的設計有缺陷，導致模塊非常復雜，蘿卜也成了唯一了解其模塊的開發人員......所以我們要讓“蘿卜快了不洗泥”的人慢下來，這樣能減少他們的危害，我們要胡蘿卜和大棒並用。我們的大棒就是“小強地獄”
相應問題：
“小強地獄”是否真的合理？
個人理解：
一個團隊內的各個成員在完成任務時應當有明確的分工，團隊開發過程中也應當有明確的DDL，如果某位成員提前完成開發任務，應當立即進行測試或者探討更優設計，而不應當着手開發新的功能，項目的每一步進展應當是扎實有效的。所以筆者認為通過小強地獄讓蘿卜慢下來不如讓蘿卜在開發的同時更注重提升代碼的質量，在開發的過程中盡量通過優化設計減少問題的產生而不是等到問題出現再進行修復，當然這僅僅是筆者目前的粗淺理解，后續結合軟工開發經驗觀點也會有所改變。
二、調研源代碼版本管理軟件
相同之處
Github/Bitbucket/Gitlab均可以
- 利用git進行版本控制，管理項目
- fork/clone 倉庫
- 支持Markdown
- 問題跟蹤
- 雙向認證
- 高級權限管理
- 提供功能豐富的API
不同之處
| GitHub | GitLab | Bitbucket |
|---|---|---|
| 提供了API用於應用程序開發 | 提供了API用於應用程序開發 | 集成了多個API和服務 |
| 提供錯誤跟蹤系統，用於提高編碼質量 | 提供了錯誤跟蹤系統以及基於Web的代碼編輯選項，用於提高編碼質量 | 使用語義搜索來分析編碼語法，以提高編碼質量 |
| 支持導入Git，HG，SVN和TFS | 支持Git，Google Code，Bitbucket和FogBugz | 支持Git，Google Code，SourceForge，HG，CodePlex和SVN。 |
| Free Plans允許托管無限的公有代碼倉庫，隨時進行clone, fork 和 contribute，對磁盤使用沒有限制。但是，項目不能超過 1 GB和單個文件不能超過 100 MB。 | cloud-hosted plan 允許無限數量的用戶在無限數量的公共和私有項目上進行協作，並且每個存儲庫有 10GB 的空間限制 | Small teams plan 允許 5 個成員加入，公有/私有倉庫均免費。 |
調研持續集成/部署工具
Gitlab CI
1.選取OOpre2Task1課程作業作為本次集成的測試，並利用JUnit對代碼進行測試
2.配置.gitlab-ci.yml文件，並上傳至gitlab倉庫（注：當前因沒有權限直接在gitlab創建個人公開倉庫，目前利用原OO課程作業倉庫調試）利用CI在線編譯，在線運行，在線測試
Github Action
1.相同程序部署到github的個人倉庫中
2.根據文檔編寫.github/workflows/maven.yml，觸發action編譯運行
CI/CD相關
CI/CD 是一種通過在應用開發階段引入自動化來頻繁向客戶交付應用的方法。CI/CD 的核心概念是持續集成、持續交付和持續部署。作為一個面向開發和運營團隊的解決方案，CI/CD 主要針對在集成新代碼時所引發的問題
GitLab-CI是一套配合GitLab使用的持續集成系統，從GitLab 8.0后就默認集成了GitLab-CI，並且所有項目默認啟用，只要在項目倉庫的根目錄添加 .gitlab-ci.yml 文件，並且配置了Runner，那么每一次MR / push 都會觸發CI Pipeline
actions可以用來作為CI/CD使用，但是它不只是CI/CD，因為它其實是一組docker容器所組成的Workflow，Workflow的觸發條件，公共倉庫目前僅支持push，私有倉庫則支持check_run、create、delete、issue comment， commit comment, pull request等許多事件, 通過這些事件，可以完成除了CI/CD之外的許多自動化操作，例如接收到issue comment之后使用telegram bot發送通知等等
4.CI/CD工具作用分析
- 持續集成中的任何一個環節都是自動完成的，無需太多的人工干預，有利於減少重復過程以節省時間、費用和工作量
- 開發和測試人員可以共用gitlab的pipeline界面或github的workflow界面, 測試人員能夠隨時把握代碼部署的情況，同時還可以通過交互界面手動啟動pipeline(workflow)，自己去部署測試，從而節約和開發之間的溝通時間
- 持續集成可以及早的發現代碼中的問題，及早解決
- 代碼庫存越是積壓，就越得不到生產檢驗，積壓越多，代碼間交叉感染的概率越大，下個
release的復雜度和風險越高，持續集成可以保證團隊開發人員提交代碼的質量，減輕了軟件發布時的壓力
5.CI/CD工具對比
Gitlab CI與Github Actions的系統對比詳見Continuous Integration Comparison，在此不再贅述
由於Gitlab的Runner已經預先配置且作業要求中提供了最小示例，以及Github actions的文檔較為詳細，所以在兩個平台部署CI的過程較為順利，希望隨着軟工課程的不斷推進，可以切實感受到CI/CD帶來的便利和對項目質量的提升。