個人閱讀作業 2

專案

內容這個作業屬於哪個課程

2021春季軟體工程（羅傑 任健）

這個作業的要求在**

個人閱讀作業#2

我在這個課程的目標是

學習軟體工程基礎知識以及培養軟體開發能力和專案組織能力

這個作業在哪個具體方面幫助我實現目標

對軟體開發流程有基本的了解； 學習用ci/id進行專案的整合與部屬

p1 閱讀提問

q1 單元測試必須由作者本人來寫嗎？

**的作者最了解**的目的、特點和實現的侷限性。所以,寫單元測試沒有比作者更適合的

人選了。

——《構建之法》p25

誠然，我在這方面與作者的觀點一致，既然程式設計師有責任編寫功能**，同時也有責任為自己的**編寫單元測試，但是作者的說法似乎欠缺了一點，單元測試應該不僅僅由作者本人來寫。

單元測試的目的是檢測被測**在特定條件下的行為是否正確，是為了證明這段**的行為和我們期望的一致。不過這裡的「期望」究竟是指誰的期望呢？顯而易見的是，程式設計師編寫這段**的目的是為了交付任務，也就是去滿足他人所提出的要求，所以這裡的「期望」理所當然的應該是需求者的「期望」。可是程式設計師在設計的時候，可能會由於考慮的不太周全而導致自己所認為的「期望」與需求者的「期望」有所偏差。那麼在進行單元測試的時候，程式設計師所提供的測試樣例也僅僅只能用來測試該單元與自己的期望一致，也就是只能測試到自己考慮到的部分，而其它特殊的情況或者一些邊界條件其實並沒有覆蓋到，顯然這樣的單元測試是不符合要求的。因此除了由本人進行測試外，還應當有更加了解需求方的測試人員去進行一些額外的測試，從而彌補**作者所沒有考慮到的部分。

q2 單元測試理應覆蓋**所有路徑嗎？

單元測試應該覆蓋所有**路徑

單元測試應覆蓋所測單元的所有**路徑,包括錯誤處理路徑。為了保證**覆蓋率,單元測

試必須測試公開的和私有的函式/方法。

——《構建之法》p27

q3 scrum方法中靠時間驅動衝刺階段真的很高明嗎？

衝刺階段是時間驅動的(time- boxed),時間一到就結束。這個特點看似不起眼,但其實它有

效地斷了各種延期想法的後路,很高明。

——《構建之法》 p117

對於有些任務，完整的實現與還差一小部分便能完成（從**量的角度上考慮，而不是功能性），其結果所能提供的功能有可能是截然不同的，甚至可能由於就只差一點點部分，而導致整個系統無法使用。倘若有一部分人的工作在規定的時間內未能完成，這會對下一次任務的分配或者計畫的安排產生較為嚴重的影響。因此我認為衝刺階段的結束的標誌應當不止有時間，還應該包括此次任務的完成程度。如果某乙個人負責的關鍵部分還差一小部分完成，應當讓其衝刺直至這部分完成。雖然這樣做不如作者所說的「時間驅動能夠有效的斷了各種延期想法的後路」，但是給未來帶來的幫助是巨大的。

q4 pm與開發和測試人員所負責的任務應當獨立麼？

pm做開發和測試之外地所有事情

——《構建之法》 p194

有些時候美好的設想往往會與實際的成果有所出入，乙個軟體框架的設計也不僅僅只依靠一本規格說明書而決定。倘若pm與開發測試人員只是單純的各司其職，勢必會存在資訊不平等的地方。比如當前的框架雖然能滿足現有的需求，但是否能具有更好的可拓展性？就算具有拓展性也是否能夠更好的針對未來應有的需求？對於這些問題的解決需要開發人員對使用者需求以及市場情況具有更加深刻的了解；同樣的pm所設計的規格說明是否更加有利於實現？不同形式的說明是否會對軟體的開發過程產生較嚴重的影響？由於pm與開發人員的資訊不平，才會導致雙方在施展工作時產生這些問題。因此pm需要參與到巨集觀層面的軟體框架設計，同樣開發人員的leader也要參與到客戶需求的分析以及產品的調研，從而讓軟體變得更加可用與有用。

q5 創新人士的關鍵特點真的是「屢敗屢戰」麼？

從以前開始，成功人士都會以「我只不過是更勤奮」、「我只不過是更加堅持不懈」等口吻來宣揚自己的成功經驗，雖然這種」雞湯「式的發言確實能夠調動起大家的情緒，給大家一種」只要你付出的更多，你也能做到「的錯覺，從而獲得大多數人的認可，但是這樣做真的有用麼？真的只用憑著一腔熱血埋頭苦幹就能獲得相應的成功麼？如果是這樣的話，那烈日炎炎下的播種的農民，揮灑著汗水的建築工人，哪乙個不比我們有著更加強烈的意志力？為什麼他們就不能獲得相應的名氣，冠以」成功人士「的頭銜呢？（這裡扯遠了）

因此書中所說的」創新人士的關鍵特點是屢敗屢戰「這句話是不準確的。這些創新人士是如何分析失敗的？通過何種途徑準確的蒐集到了失敗的資訊以及從哪些角度分析了失敗的原因？獲取並分析了失敗的原因後，他們又從哪些角度改善了自己的想法？

上面只是針對於有過失敗經驗的團隊來說。那麼沒有失敗過，出道即巔峰的團隊呢？他們在做每乙個專案前怎樣做到了縝密的分析？上海公尺哈遊公司從第一步遊戲《fly me 2 the moon》到《崩壞學園2》,到《崩壞三》,再到《原神》一步步走向成功與聞名，但是他們真的有不斷地經歷過失敗，不斷地」屢敗屢戰「麼？他們的每一代遊戲無論是畫面還是技術（除了策劃）的成長都是有目共睹的，但是透過光輝的表象，他們內部所處理的細節，所考究到的地方，一定是數不勝數。對於這一類成功典型，不是」屢敗屢戰「造就了他們的成功，而是在失敗前，他們就已經做了足夠多的準備去規避失敗。

所以僅僅用」屢敗屢戰「去涵蓋創新人士、成功人士所付出的努力，顯然是不負責任的。創新人士的」成功「特點應當滲透到了每一處，而這才是我們應當學習的。

p2 調研源**版本管理軟體

github、bitbucket、gitlab 都是基於git做版本控制的**託管平台，都具有如「拉取請求」、「**審查」、「內聯編輯」、「問題跟蹤」、「雙向認證」、「第三方整合」等特點，同時他們也各自具有獨特的特色。

git通過非線性開發歷史的視覺化工具和導航工具的幫助，支援流暢的版本合併和分割，有很多令人稱道的功能，如「快速搜尋」、「社群交流」、「專案共享」等特點，但github所有的服務並不是免費的，同時具有檔案大小限制。

gitlab完全免費，使用者可以擁有無限數量的私有儲存庫 ，同時也有適用於企業的gitlab saas，以及使用者的個性化解決方案gitlab community edition。不過介面相對較慢，也會有儲存庫常見的技術問題等。

bitbucket最適合小型開發團隊，隨著團隊的成長，bitbucket提供了與github和gitlab相比更溫和的定價條件。bitbucket還為團隊提供了靈活的部署模式。 但系統比較不穩定，而且專案不開源。

p3 調研持續整合/部署工具

3.1 gitlab ci實踐

build與test結果如下：

專案build輸出如下：

3.2 github acitions實踐

3.3 比較與總結

gitlab ci/id和github actions都提供了持續整合、持續部署的功能，使得整合新**時許多流程都採用自動化的方式實現，不需要讓程式設計師過多的關注這些部分，從而提公升了工作的效率。gitlab ci/id的語法更為清晰簡潔，而github action的語法比較繁瑣。不過github action支援許多開源的外掛程式，因此更適合靈活應對一些常見的任務。

個人閱讀作業2

在 no silver bullet 中，作者提到兩種軟體開發的困難 1.本質性 軟體本身在概念 conceptual 建構上存先天的困難 亦即如何從抽象性問題，發展出具體概念上的解決方案。2.附屬性 將概念上的構思施行於電腦上，所遭遇到的困難。而造成本質性困難的原因是 1.複雜性 complexi...

個人閱讀作業2

乙個學期的軟體工程課程即將結束，從一次個人作業，一次結對作業和兩個階段軟體的開發中，我學到了很多東西。個人作業讓我明白了程式設計師最需要具備的一項技能就是自學能力。從對語言的不熟悉，到能寫出乙個小型的程式，非常考驗我們的自學能力。結對作業重在讓我們有乙個團隊合作的意識，給接下來的團隊專案打下基礎。同...

個人閱讀作業

問題 1.對於高健壯性的 應該先斷言再進行錯誤處理 大全 p193。為什麼不直接用錯誤處理呢？先斷言再進行錯誤處理和直接進行錯誤處理的效果不是一樣的麼？2.完全填充分配到的所有記憶體，這樣可以讓你檢查到記憶體分配錯誤。完全填充已分配到的所有檔案和流，這樣可以讓你排查出檔案格式錯誤。大全 p206 什...