軟體工程-個人閱讀作業2

項目	内容
這個作業屬于哪個課程	2021春季軟體工程
這個作業的要求在哪裡	作個人閱讀作業#2
我在這個課程的目标是	擁有一定的軟體開發經驗
這個作業在哪個具體方面幫助我實作目标	結對作業以及疊代項目

閱讀提問

1. 學生與職業程式員的差別

問題出自建構之法，第三版，P36頁

顯然從學生到職業程式員，并不是更加沒完沒了地寫程式——花在寫代碼的時間反而少了很多

作者使用編碼時間的對比得出此結論，但筆者認為此結論以偏概全。

假定圖2-3中學生和工程師最後都完成了一份很好的個人項目作業。

學生寫代碼的時間是36%，工程師寫代碼花費的時間是21%。學生寫代碼花費的時間确實比工程師多，但筆者認為需要考慮的學生和工程師的代碼能力和水準。工程師寫代碼花費的時間少，一部分原因是工程師在進行需求分析和具體設計時花費的時間比較多，使得代碼寫起來更加容易和順暢，但另一部分也不可否認，即便在同樣的需求分析和具體設計下，工程師和學生完成同樣的編碼，工程師花費的時間大機率會比學生花費的時間少，二者的代碼能力和水準的差距還是存在的。那代碼能力是從哪裡來的？筆者認為是從學生到職業程式員這個過程中通過沒完沒了的寫代碼鍛煉而來的。當然如果學生在這個過程中隻是沒完沒了的寫代碼那麼肯定是無法成為職業程式員的，但寫代碼是一個必備的過程。

此外，在圖2-3可以看到工程師在測試（自測、修改代碼、送出修改）這部分花費的時間是學生的1.6倍。為什麼工程師花費的時間如此之多？顯然是有工程師重視測試的原因，來保證程式的正确性和安全性，但考慮到工程師在編碼時花費的時間很少，那麼工程師在測試時所出現的Bug是否會比大學生的Bug更多，進而導緻在測試方面花費的時間更多？

2. goto是否應該在程式中使用

問題出自建構之法，第三版，P75

函數最好有單一的出口，為了達到這一目的，可以使用goto。隻要有助于程式邏輯的清晰展現，什麼方法都可以使用，包括goto。

在筆者大一學習C語言，第一次接觸到Goto時，就被告知Goto盡量不要在程式中使用，會讓程式的邏輯以及結構混亂、不清晰。在網絡上進行搜尋Goto關鍵詞可以很明顯的看到這一文法的不受待見程度。

盡管筆者在實際的程式設計過程中并未嘗試過Goto的使用，但在學習Mips彙編時，使用過類似效果的無條件跳轉指令J指令等，就在彙編中的體驗感來說還是很舒服的。我能在任意的地方插入跳轉指令，使得程式的運作方向和過程瞬間發生改變，并且在進行條件控制時使用無條件跳轉語句可以讓程式非常靈活。但在進行測試和調試過程中，往往會出現莫名奇妙的運作過程以及不知所措的跳轉。此外，當别人檢視我的代碼時，會很難看懂各種跳轉的邏輯，程式顯得一團糟糕。我想這或許就是為什麼不推薦在程式中使用Goto的原因。是以在讀到這句話時，有點疑惑Goto應不應該在程式中使用？

3. 結對程式設計是否合理

書中對結對程式設計的描述有好有壞。一方面結對程式設計有利于提高代碼品質，減少後面的修改和測試的時間，并且可以有效水準較低一方的程式設計能力，一方面也可能變成雙方不合，效率低下變成單人作戰模式。筆者在網上查閱了一些資料，發現對于結對程式設計的評價很有争議，有對于結對程式設計很反對的觀點，也有認為合理的進行組隊以及有效的溝通可以很好的提高開發水準。我們在課程中需要進行組隊（或許随機組隊）來完成結對程式設計，在雙方都是學生水準的情況下（當然有些厲害的大佬，不在這個範圍内，但筆者認為普通水準的學生占大多數），思想和思路會趨于同向化而導緻代碼品質和效率無法達到預期的效果。那麼進行結對程式設計是否能夠合理的提高開發效率、代碼品質以及提高個人程式設計水準？

4. 工作時是否應該帶着個人、感情驅動的因素

引用自建構之法，第三版，P51

理性地工作：軟體開發有很多個人的感情驅動的因素，但是一個成熟的團隊成員必須從事實和資料出發，按照流程，理性地工作。很多人認為自己需要靈感和激情，才能為宏大的目标奮鬥，才能成為專業人士。著名的藝術家Chuck Close說：我總覺得靈感是屬于業餘愛好者的。我們職業人士隻是每天持續工作。今天你繼續昨天的工作，明天你繼續今天的工作，最終你會有所成就。

作者在這裡引用了Chuck Close的話來證明工作不需要靈感和激情，隻需要堅持工作，最終會有所成就。但筆者思考認為：

既然是職業人員，那麼職業人員曾為這份職業付出過努力，并是以而成為職業人員。顯然，這個過程中沒有激情和靈感是很難成功的。那麼在成為職業人員之後需要隻是工作，其他什麼都不需要，那麼迄今為止所付出的努力的結果就是為了日複一日的工作？衆所周知，35歲程式員危機，他們努力工作卻被公司淘汰，那他們的最終失業的結果是Chuck Close所述的”最終你會有所成就“？
靈感是屬于業餘愛好者的。牛頓因為一顆蘋果掉落，而思考到萬有引力定律不是一種靈感嗎？音樂家、藝術家們所說的創作靈感，難道都是日複一日的工作？
筆者查閱藝術家Chuck Close的資料和作品，他屬于超級寫實主義，他的畫作以人像為主，人物毫無表情，不傳達任何特點，他本人也抹去自己的感情，不表露任何傾向。偌大的圖像，看不到一絲感情私彩，蒼白的面孔，空洞的眼神，呆滞的神态......每一個細節都被放大到畫面上。唯有人物的個性被忽略，這是他的繪畫特點。擁有這樣繪畫特點的藝術家，所述的個人觀點，或許能夠代表一些職業，但筆者認為是無法以偏概全應用到全部職業上。

5. 靈活開發過程中對需求的變化

引用自建構之法，第三版，P114

靈活開發的原則是：

靈活流程歡迎需求的變化，并利用這種變化來提高使用者的競争優勢

引用自建構之法，第三版，P116

第三步：沖刺。

......有任何需求的改變都留待沖刺後結束再讨論......

靈活開發的第三步沖刺過程中不允許需求的改變，筆者查閱發現，沖刺時間一般是一個周到一個月，在這段時間内如果遇到了會重要的需求改變，那麼是否應該停止下來進行需求更改來重新沖刺？不修改需求，仍然按照原計劃繼續進行沖刺是否違背了上述的靈活開發原則？沖刺中對于需求的處理一定要如此絕對的拒絕全部的需求改變嗎？是否可以更加靈活一些？

調研源代碼版本管理軟體

GitHub 是第一個供“用Git進行版本控制系統的軟體開發項目”使用的基于Web的代碼托管服務，是目前全球最大的開源社交程式設計及代碼托管網站。GitHub 于 2008 年 4 月 10 日正式上線，除了基本的服務以外，還提供了訂閱、讨論組、文本渲染、線上檔案編輯器、協作圖譜（報表）、代碼片段分享（Gist）等功能。

BitBucket 是 2008 年建立的源代碼托管網站，采用 Mercurial 和 Git 作為分布式版本控制系統，同時提供免費賬戶和商業計劃。2010 年被 Atlassian 收購，與 Atlassian 的其他服務(Git GUI SourceTree、HipChat、Cloud9)順利內建，主要面向慈善企業和企業使用者/其主要市場是大型企業。

GitLab 是一個利用 Ruby on Rails 開發的開源應用程式，實作一個自托管的 Git 項目倉庫，可通過 Web 界面進行通路公開的或者私人項目。

下圖是GitHub工作流圖：

下面是GitLab的開發流程：

開發接收需求，切換到develop分支，pull develop分支最新代碼，拉取特性分支feature；
每一個新功能的開發都使用獨立的feature分支。為了備份或便于團隊之間的合作，這種分支也可以被推送到中央倉庫，B和A可以同時在一個特性分支上協作。
功能開發結束并自測後，先切換到develop分支，pull最新代碼，切回功能所在的feature，把develop分支的代碼合并進來，有沖突和配合的人一起解決。
到 GitLab 上的項目首頁建立feature合并到develop的合并請求（merge request），比對和上個版本的代碼變化，指定有合并的和參與代碼稽核的同僚。（代碼稽核）
項目負責人在收到合并請求時，應該先做下代碼稽核看看有沒有明顯的嚴重的錯誤；有問題就找負責開發的人去修改，沒有就接受請求并删除對應的 feature 分支。
有問題的代碼開發者自己修改後在push到倉庫，代碼稽核頁面會同步最新修改。
負責測試的人從develop建立一個 release 分支部署到測試環境進行測試，若發現了 bug，相應的開發人員就在 release 分支上或者基于 release 分支建立一個分支進行修複。
當確定某次釋出的功能可以釋出時，負責釋出的人将 release 分支合并進 master 和 develop 并打上 tag，然後打包釋出到線上環境。

GitHub、GitLab、Bitbucket相同點：

都支援Git對源代碼進行存儲和版本控制
支援代碼審查
支援内聯編輯
支援問題跟蹤
Markdown支援
支援雙向認證
都擁有進階權限管理
允許托管靜态網頁
都具有功能豐富的API
允許Fork / Clone Repositories
可以進行第三方內建

不同點：

GitHub和Bitbucket支援導入多個不同的VSC的repos，而GitLab隻支援Git。GitHub支援導入Git、SVN、HG、TFS，而GitLab支援導入GIt，但更容易從其他服務導入GitHub、Bitbucket、Google code等。Bitbucket支援導入Git、CodePlex、Google Code、HG、SVN。

在免費計劃上，GitHub提供無限的共有代碼倉庫，但項目不能超過1GB和單個檔案不能超過100MB。BitBucket的Small teams plan允許五個成員家人也，公有私有倉庫均免費。當項目快達到1GB時，會有郵件通知。GitLab的cloud-hosted plan允許無限數量的使用者在無限數量的公共和私有項目上進行協作，并且每個存儲庫有10GB的空間限制。

調研持續內建/部署工具

GitLab CI

GitLab CI使用的是OO的第一次作業的代碼倉庫。根據參考資料需要使用Maven進行對Java代碼進行編譯和管理，是以筆者将項目結構更改為Maven結構，并添加簡單測試代碼來進行測試。運作結果截圖如下圖：

開始編譯

軟體工程-個人閱讀作業2

編譯成功

開始運作和測試

線上運作成功和測試成功

其中測試樣例為對 2*x2

進行求導，求導結果應為：4*x

GitHub Action

GitHub Action使用倉庫為我新建立的Maven 項目，代碼内容與上述GitLab Ci 的代碼相同。經過嘗試和調試最終運作成功結果如下截圖所示：

編譯結束

運作和測試成功

CI與CD體會

由于在本次作業中隻是初次使用和了解GitLab CI 和 GitHub Action，并嘗試制作了簡單的Demo，對軟體開發過程中的CI與CD并未進行嘗試和實踐，是以很難總結二者的特點和特性，以下關于二者的特點和分析部分内容是在網絡中擷取到的資訊的拼接和整合，部分是筆者淺薄的見解和分析。

特點與特性

GitLab CI是一個處理軟體開發生命周期各個階段的工具包。它在一個訓示闆内提供了各種特性，比如代碼審查、CI/CD、持續部署等等，在代碼托管在GitHub上時，可以使用GitLab CI/CD并在YAML檔案中定義建構、測試和部署腳本。對于每次送出，GitLab都允許你執行建構、運作測試和部署代碼，并允許開發人員在虛拟機、Docker容器或另一個不同的伺服器上建構作業。

GitLab CI 特點：

使用分支工具檢視、建構和管理代碼和項目資料
代碼和項目資料從單一的分布式版本控制系統設計、開發和控制，允許快速疊代和傳遞業務價值
為項目和代碼協作提供一緻的真實性和可伸縮性
允許傳遞團隊通過自動化源代碼建構、內建和驗證來完全采用CI
提供了容器掃描、應用程式的靜态安全性測試（SAST）、應用程式的動态安全性測試（DAST）以及提供穩定應用程式和許可執行的依賴項掃描
幫助自動化和縮短啟動和程式傳遞
GitLab Container Registry 是安全的 Docker 鏡像系統資料庫
GitLab 提供了一種友善的方法來更改 issue 或 merge request 的中繼資料，而無需在注釋字段中添加斜杠指令
為大多數功能提供 API，允許開發人員進行更深入的內建
通過發現開發過程中的改進領域，幫助開發人員将他們的想法投入生産
可以通過機密問題保護您的資訊安全
GitLab 中的内部項目允許促進内部存儲庫的内部 sourcing

高可用性部署。GitLab CI/CD 的安裝和配置都很簡單。它是内置于 GitLab 的免費且自托管的持續內建工具。
裡程碑設定。工具中的裡程碑設定是跟蹤問題、改進系列問題、繪制倉庫的請求的一種很好的方法。你可以輕易将項目裡程碑配置設定給任何問題，或者合并項目中不常見的請求，或者将組裡程碑配置設定給一組問題，或者合并該組中任何項目的請求。
自動伸縮的持續內建運作器。自動伸縮的 GitLab 持續內建運作器可以輕松管理和節省 90% EC2 成本。這真的非常重要，特别是對于并行測試環境。而且，對于元件級别或者項目級别的運作器，可以跨代碼庫使用。
活躍的社群支援。活躍且進步的社群是 GitLab CI/CD 的一個主要加分點。提供的所有支援都是開箱即用的，不需要在額外的插件安裝中進行修改。

GitHub Action，是GitHub提供的CI/CD方案，本質是在GitHub産生一些互動事件時（如：push，Tag，pull......），觸發一些預定的腳本，來對代碼進行單元測試、代碼檢查、編譯以及進行軟體的釋出等，并将報告輸出到合适的地方。GitHub Action的特點和GitLab的特點大同小異。

分析

傳統軟體的開發與傳遞周期都很漫長，一款普通軟體的開發從需求分析、系統設計、測試分析、系統開發、單元測試、組裝測試到傳遞調試，整個過程穩定而可靠的保證整個系統緩慢推進。每一次的傳遞、更新，都需要提供基礎的硬體、軟體的環境、軟體的代碼、軟體的文檔和手冊。傳統下的這一套流程，每次傳遞對于開發人員和測試人員都是十分痛苦的過程。如何才能讓傳遞變的更加舒服、流暢？或者說如何才能讓這一套流程更加的簡潔、友善，至少表面上的簡便？為了解決這一問題，靈活開發鼻祖 Martin Fowler 提出了持續內建與持續傳遞的概念。随着各種包管理工具的發展，對于CI需求的軟體數量也在爆發增長，如何簡單、高效、快速的進行CI和CD的需求也在不斷增加。

GitLab CI也是在需求的推動中不斷發展。GitLab在2015年的6月末釋出了GitLab v7.12版本，該版本中重構了原有的CI功能，開始支援了使用.gitlab-ci.yml使用來配置CI、内置了WebHook功能，并在同年九月釋出了釋出了擁有新界面的GitLab v8.0 ，并預設內建了 CI 功能。再随後2016年3月末，官方推出支援自動擴容的GitLab Runner v1.1版本，一年之後，GitLabv9.0的釋出使得任何一家公司都能夠再數小時到幾分鐘内使用傳統安裝或者部署的方式快速體驗完整的CI流程。在2017年9月，GitLab推出了v10.0，帶來了全新的Auto DevOps功能，開始将開發重點由CI向CD發展。到了2018年的6月，由于Kubernetes如日重點，GitLab釋出了v11.0版本進一步将Kubernetes與Auto DevOps進行內建。同時随着微服務架構與虛拟化技術的發展，對于GitLab CI/CD發展起到了很好的推動作用并提高了Jobs完成的效率。

對比

GitLab CI 與 GitHub Action的對比：

二者對比在 GitLab vs GitHub 中進行比較詳細的功能以及各種生态的對比和 GitHub Actions vs GitLab CI 中二者使用量以及在知名網站的讨論和話題的對比。

上面對比可以看出GitLab CI在使用量和功能都超過GitHub Action。筆者查詢了GitHub Action的曆史，它是在2018年10月推出的CI/CD服務，在2019年11月正式推出之前，一直是Beta版本。GitLab CI的發展時間要比GitHub Action多至少三年的時間，是以GitLab的功能比GitHub的功能更加完善也在情理之中。但GitHub在近年來的發展十分迅速，GitHub托管了大量的開源和閉源項目，在大量使用者需求以及社群的推動下，GitHub Action在飛速發展，随着功能和生态的完善，有可能在未來成為主流CI/CD工具之一。