軟工第二次閱讀作業

項目	内容
這個作業屬于哪個課程	2021春季計算機學院軟體工程(羅傑 任健)
這個作業的要求在哪裡	個人閱讀作業#2要求
我在這個課程的目标是	提高工程能力，成為一名真正的軟體開發者
這個作業在哪個具體方面幫助我實作目标	了解真正的軟體工程，學習版本控制與內建部署工具

閱讀提問

1、單元測試中作者自己測試最好嗎，單元測試使用随機數真的沒有意義嗎？

在《建構之法》第二章第一節中有這麼一段話：

單元測試必須由最熟悉代碼的人（程式的作者）來寫。代碼的作者最了解代碼的目的、特點和實作的局限性。

如果某個随機數導緻程式出錯，但是下一次運作又不能重複這一錯誤，則于事無補。我們還是要用随機數等辦法“增加測試的真實性”，但不是在單元測試中。單元測試不能解決所有問題，不必期望它會發現所有的缺陷。

作者認為單元測試需要由最熟悉代碼的作者本人來編寫。

在我自己寫完代碼的時候，我一般有兩種狀态，一種是十分不安，因為我在寫的過程中用了一些自己不熟悉的算法資料結構或者我意識到一些地方好像需要對一些特殊值進行特殊處理，但是我在第一遍編寫的時候沒有進行這樣的操作；第二種狀态就是覺得程式應該沒有什麼大問題，一種比較自信的狀态。對第一種狀态，由作者本人來編寫單元測試非常合适，理由也正是作者所說的那樣，作者是最了解代碼的特點和實作的局限性的人。但事實上對于編寫較為簡單的代碼的基本單元，後一種狀态可能更多一點，前面的狀态可能更是由于功能的過于複雜或者內建度過高帶來的。而對第二種狀态，開發者往往很難自己找出漏洞， 開發者已經具有了思維定勢，并且對于簡單的基本功能已經胸有成竹，這個時候我覺得應該需要專業的軟體測試人員來輔助進行測試，他人往往能想到很多自己想不到的地方，這樣更能夠找到bug。

不過真實情況下無論你設計多少測試用例，無論你的測試方案多麼完美，都不可能完全100%的發現所有BUG，是以往往軟體測試的目的是用最少的資源，做最多測試檢查，尋找一個平衡點保證程式的正确性。而大量使用專業軟體測試人員會大量增加成本，是以如何有一個低成本的方法呢？我覺得就是随機數。

作者因為下次運作無法重複錯誤就否定随機數在單元測試中的作用。但是我覺得随機數測試程式所産生的錯誤資料完全可以記錄下來增加到單元測試資料庫中，進而保證可以複現與回歸測試。

當然也有一種可能性是随機數的成本還是略高？單元測試的目的是快速的對一個基本的功能單元進行快速的基本測試。并不要求盡量找出所有bug，隻需要保證基本的簡單的功能正常執行即可，是以可能單元測試的目标就是簡單測試所有路徑，在單元測試的上層有更複雜的，內建度更高的內建測試，這一部分是需要重點測試的。

2、結對程式設計是否太理想化了

在結對程式設計模式下，一對程式員肩并肩、平等地、互補地進行開發工作。他們并排坐在一台電腦前，面對同一個顯示器，使用同一個鍵盤、同一個滑鼠一起工作。他們一起分析，一起設計，一起寫測試用例，一起編碼，一起做單元測試，一起做內建測試，一起寫文檔等 .

結對程式設計看上去是個很美好的東西，兩個人一起，角色不斷互換，一起思考，一起解決問題。但是在實際的操作中，每個人都有自己獨特的節奏，獨特的風格，例如有人傾向于提前設計好整體架構乃至所有細節，而另一個人更傾向于直接去莽，在寫代碼的過程中不斷改進，這樣一起工作的話是不是會出很多問題？面對同一個問題，兩人可能會有不同的解決的方式，而這兩種方式并無優劣之分，隻是各有特點，此時會不會因為風格差異問題導緻合作出現問題？還有在"領航員"複審代碼的時候，"駕駛員"會不會要不斷的被打斷工作節奏，不斷的解釋等等。

3、對于“小強”的處理

小強地獄（Bug Hell）。如果開發人員的小強（Bug）數量超過一規定值，則此君被送入“小強地獄”，在地獄中，他唯一能做的就是修複小強，直到小強數量低于此門檻值。

個人覺得是不是對于每個bug，都應該在出現的時候分析一下，如果這個bug的修複不需要變動整個架構，是小問題，就可以記錄下來之後修改，優先完成項目，如果是大問題就需要立即修改？而不是僅僅靠數目就去修bug？

4、複審相關問題

複審者必須逐一提供回報意見。注意，複審者有權提出很多看似吹毛求疵的問題，複審者不必親自調查每一件事，開發者有義務給出詳盡的回答。

我覺得複審者還是需要盡量調查完全之後再提出一些問題，否則是不是很容易打擾到開發者？一些小問題可能隻要再浏覽一遍代碼就可以很容易的明白，如果因為這些小事就頻繁打擾開發者，會不會影響開發者的工作效率？

5、創新相關

但是在實際中，你會發現很多成功的企業進入了一個創新者的困境（Innovator'sDilemma）。當成功的企業步入中年，它們當年發迹的市場成熟了，當年賴以成功的創新技術成了主流的成熟技術，又叫“維持性的技術”，在成熟的市場和維持性的技術環境中，技術的創新并不是影響企業成敗的主要因素。然而，颠覆性的創新會帶來産品和市場的巨大風險，這些企業中的流程、價值觀和文化會排斥颠覆性的創新。那些沒有成功包袱的小公司反而能把颠覆性的創新帶到市場，挑戰成熟企業的霸主地位。

小公司确實能将創新帶到市場，但我覺得創新的主體更可能是大公司，并且小公司很難通過創新去挑戰成熟企業的霸主地位。大公司體量大家業也大，我覺得比較容易分出一小部分資源做出創新的嘗試。并且新的市場如果有小的公司先去試水，發現效果不錯，大公司也很容易通過其龐大的資源以及市場碾壓小公司，進而将小公司的創新變成自己的“創新”。

源代碼版本管理軟體

這三者有許多相同的基礎特點：拉取請求、代碼審查、内聯編輯、問題跟蹤、Markdown支援、雙向認證、進階權限管理、托管的靜态網頁、功能豐富的API、Fork / Clone Repositories等等。

• GitHub
  • 他可以作為一個版本控制系統和協作工具，用它來釋出工作。利用GitHub，你可以将項目存檔，與其他人分享交流，并讓其他開發者幫助你一起完成這個項目。優點在于 ，他支援多人共同完成一個項目，是以你們可以在同一頁面對話交流。建立自己的項目，并備份，代碼不需要儲存在本地或者伺服器，GitHub做得非常理想。你可以通過Github評論，送出錯誤。在GitHub頁面，你可以直接開始，而不需要設定主機或者DNS。
• GitLab
  • GitLab服務也是基于Git版本控制開發的。盡管GitLab功能與其主要競争對手GitHub類似，但仍有一些主要特點。GitLab有幾種不同的形式，如适用于企業的GitLab SAAS，以及使用者的個性化解決方案GitLab Community Edition。Gitlab免費使用者可以擁有無限數量的私有存儲庫。當然為了滿足客戶要求，GitLab也有企業版，在其基本功能之上增加了一些額外的功能，進而改善了與線上工具，工作流和伺服器管理等的互動。錯誤跟蹤和基于Web的代碼編輯。與LDAP(輕量級目錄通路協定)內建，允許在Internet上定位和通路各種資源。GitLab EE支援多種LDAP服務群組同步。支援Git導入.
• BitBucket
  • BitBucket服務也非常類似于GitHub，但是它的大部分功能也略有不同。BitBucket最适合小型開發團隊，随着團隊的成長，BitBucket提供了與GitHub和GitLab相比更溫和的定價條件。BitBucket還為團隊提供了靈活的部署模式。BitBucket內建Jira工具。BitBucket和Jira在整個開發階段都做了整合，通過內建的錯誤跟蹤元件，JIRA自動更新有關檢測到的問題的資訊。
  • 其主要的缺點在于不開源和系統不穩定。

持續內建/部署工具

Gitlab-CI

使用oo的pre2task0代碼，重新寫成maven工程的形式。代碼庫

• 簡單的測試代碼

• 線上編譯測試結果

Github Action

與前面使用幾乎相同的代碼，代碼庫

• 運作結果

使用CI/CD工具後的感受

​ CI/CD可以及時的在push之後進行建構與單元測試，友善及時發現代碼中的bug。

​ 相比github，gitlab的優勢是gitlab可以支援父子管道同時運作，配置可以劃分成更小的子管道，而github沒有管道編排，導緻管道運作時間更長。

​ 但是github提供了一個開源市場，可以輕松地找到第三方工具/插件建構的模闆。