[2019BUAA軟件工程]第1次閱讀做業

時間 2019-12-13

標籤 2019buaa buaa 軟件工程閱讀简体版

原文原文鏈接

[2019BUAA軟件工程]第1次閱讀做業

Tips	Link
做業鏈接	[2019BUAA軟件工程]第1次閱讀做業

讀《構建之法》的疑惑

我的開發流程（Personal Software Process）自身的時間開銷？各個階段邊界的界定？（書 2.3節）html

在開發過程當中按照任務清單對我的每一個階段所耗時間進行較準確的記錄是一件不容易的事，所以其自己就會帶來必定的時間開銷。其困難主要體如今各個階段邊界的肯定上。在書5.3節有：git
- 各個步驟之間是分離的，但在軟件生產過程當中的各個步驟不能這樣嚴格分離出來。
- 回溯修改很難甚至不可能，但事軟件生產的過程須要時時回溯。
在開發過程當中，開發者常會在各個階段間回溯（就我而言是這樣的）。這致使處於每一個階段的時間是十分離散的。如果每次回溯都作一次記錄並且仍是要求工程師本身收集，其帶來的時間開銷顯然是不小的。如何才能有效率地在廣泛存在回溯的開發流程中記錄各個階段的耗時呢？程序員
優化與泛化的時機。（書 3.2）github

本章節提出了幾個軟件工程師的思想誤區，其中有過早優化和過早泛化。優化和泛化是編寫一個優秀的軟件應當有的步驟。而且二者都會涉及代碼的重構。就如同修復Bug同樣，越晚的重構也會帶來更多的工做量和難度。在此過程當中仍可能出現新的Bug，於是還要進行一系列的測試。其中泛化帶來的重構可能設計更多的代碼。但過早優化和泛化又會帶來書中所講的糾結於局部忽視全局的問題。那麼在軟件開發的過程進行優化和泛化的最好時機是何時？算法
結對編程兩人的分工以及輪轉效率問題。（書 4.5節）數據庫

在書中對於結對編程有如下的描述：編程

在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤、同一個鼠標一塊兒工做。他們一塊兒分析，一塊兒設計，一塊兒寫測試用例，一塊兒編碼，一塊兒作單元測試，一塊兒作集成測試，一塊兒寫文檔等等。服務器

在書中對於結對編程兩角色的任務有如下的描述：網絡
1. 駕駛員：寫設計文檔，進行編碼和單元測試等XP開發流程。
2. 領航員：審閱駕駛員文檔；監督駕駛員開發流程的執行；考慮單元測試的覆蓋率；思考是否須要和如何重構；幫助駕駛員解決具體的技術問題；設計TDD中的測試用例。
3. 駕駛員和領航員不斷輪換角色，不要連續工做超過一小時，工做一小時休息15分鐘。領航員控制時間。
通常兩人合做時，每一個人的任務是按照工做爲粒度進行分工的，好比成員A負責XXX部分的開發（包括測試），成員B負責YYY部分的開發（包括測試）。每一個成員都可以用比較大塊的時間專一於項目某一部分的開發和測試。就我而言，這種大塊、連續的時間是十分必要的，由於每次開始編程時每每須要一段前期預熱來進入狀態（按照複雜度的不一樣耗費不一樣時間）。而結對編程則是按照時間粒度進行分工的，進而這種連續的時間被打斷了——駕駛員剛剛找到手感進入狀態就換人。除此以外，在項目中也有一些不適合被打斷的工做。按照書中的駕駛員領航員的例子，貌似現實中的拉力賽沒有駕駛員和領航員在比賽中途停車換位的狀況。所以，我對於結對編程所帶來的效率的提升有必定的疑惑。electron
敏捷開發中的任務規劃與推動問題。（書 6章）

在書中，做者簡述了Scrum方法論：
1. 找出完成產品須要作的事情；
2. 決定當前的衝刺須要解決的事情；
3. 衝刺。
在Scrum中工做被細分紅多個任務，並使用燃盡圖或看板來管理。整個過程全由團隊成員根據自身狀況認領。每一個成員的能動性成爲項目推動的必要條件。但在現實中，這每每會演變成出人意料的狀態。除了可以按照理想狀態進行的狀況，我列舉出了一下兩種極易產生的人們不肯意見到的狀況：
1. 部分紅員比較懶惰，趕忙選了比較簡單任務，把難的裏給別人。結果別人也不樂意作剩下的任務，最後致使有任務遲遲不解決，衝刺停滯。
2. 成員都比較勤勞，但都下意識先選了簡單的，把較難的放到後面再作。但任務間的內在聯繫每每要求某些較難的任務優先完成。最後致使一部分簡單的任務須要等待，延誤了工期。
Scrum是靠每一個成員的能動性推進的，而Scrum大師的任務僅是在人員間傳遞信息。除此以外，是否應當有某個有必定權力的人來確保衝刺的動力，以及保證任務完成順序符合內在要求？好比PM（雖然書在這部分沒說起PM的做用）？
團隊開發中我的效績的評定（書 17.6節）。

在團隊項目中，對每一個成員的效績進行相對正確客觀的評定是至關重要的。在此以前筆者曾參加過團隊項目而且擔任過一次團隊的組長。最終提交做業時老師總會要求附加一個成員工做比例的說明文件。如何將成員的工做具體到一個比例每每是個使人頭疼的事。通過查詢，在博客中博主提出了：我的績效=0.3*工做時間+0.3*任務量+0.4*任務難度的方法。我的認爲這種方法將返工所帶來的浪費計入了效績的積極項，明顯是有失穩當的。在博客中博主提出了：我的效績=工做時間*0.5+任務量*任務難度*0.5-返工率（bug數目） 的方法。這種方法雖然考慮了返工帶來的浪費，但沒法衡量我的的工做效率。好比其餘條件不變的狀況下，僅增長工做時間就能能加效績？這使人難以信服。

歸結起來，在進行我的效績的評定時有兩大角度：過程和結果。對於結果的評定已經有目標與關鍵成果法（OKR），可以進行比較準確的評定。但如何才能將工做中的過程更準確地加入至我的效績考量中？而或是無論過程只論成果呢？

軟件與軟件工程歷史調研

軟件 = 程序 + 軟件工程

程序？軟件？（來自於Cambridge Dictionary的解釋）
- Program:
  
  a series of instructions that can be put into a computer in order to make it perform an operation
- Software:
  
  the instructions that control what a computer does
程序的由來：

Ada Lovelace是第一位主張計算機不僅能夠用來算數的人，發表了第一段分析機用的算法，被公認爲史上第一位認識計算機徹底潛能的人，也是史上第一位計算機程序員。同時，爲記念Ada Lovelace而命名的Ada語言是一種表現能力很強的通用程序設計語言。它是美國國防部爲克服軟件開發危機，耗費巨資，歷時近20年研製成功的。它被譽爲第四代計算機語言的最成功表明。
軟件的由來：

按照詞義上的解釋，軟件和程序的含義相近，可是軟件的概念比程序更晚出現。在von Neumann architecture和Harvard architecture的提出以及程序存儲計算機（stored-program computer）出現以後，計算機可以將程序存儲並在內存中運行。計算機的底層硬件逐漸與程序應用分離，軟件的概念逐漸產生。根據維基百科對於軟件發展的描述有：

The very first time a stored-program computer held a piece of software in an electronic memory, and executed it successfully, was 11am, 21 June 1948, at the University of Manchester, on the Manchester Baby computer. It was written by Tom Kilburn, and calculated the highest factor of the integer 2^18 = 262,144.

在《構建之法》一書中對軟件的定義爲：軟件 = 程序 + 軟件工程。如此說來，從開發的角度來看真正意義上的軟件應當是在軟件工程的提出時誕生的。

軟件工程——軟件危機的產物

出現背景：

20世紀下半葉出現的軟件危機，軟件開發在預算、開發時間、成品質量、需求知足度、項目管理、代碼維護等方面出現巨大問題。據維基百科描述：

硬件成長率每一年大約30％，軟件每一年只勉強以4～7％速度在成長，信息系統的交付日期一再延後，許多待開發的軟件系統沒法如期開始。1960年代軟件開發成本佔總成本20％如下；1970年代軟件成本已達總成本80％以上，軟件維護費用在軟件成本中高達65％。1986年公佈的數據，全部驗收的外包軟件中，居然只有4％可用，其他96％倒是不堪一用。大部分的企業自行開發的信息系統中，有四分之三也是功敗垂成。所以軟件維護成本居高不下，軟件產品質量低落是最主要的緣由。

1995年，Standish Group研究機構以美國境內8000個軟件項目做爲調查樣本，調查結果顯示，有84％軟件計劃沒法於既定時間、經費中完成，超過30％的項目於運行中被取消，項目預算平均超出189％。
概念的提出：

1968年秋季，NATO（北約） 的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫「軟件危機」的對策。在那次會議上第一次提出了軟件工程（software engineering）這個概念，研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把通過時間考驗而證實正確的管理技術和當前可以獲得的最好的技術方法結合起來的學科。

簡析目前流行的源程序版本管理軟件和項目管理軟件

版本/項目管理軟件使用人數調研

Software	Usage	Project
GitHub	31 million users	100 million
GitLab	100,000 organizations	------
Bitbucket	6 million users	------
Bugzilla	A large number	------
Trac	list of uesrs	------

部分版本/項目管理軟件比較

Concurrent Versions System (CVS)
- 相較於SVN，CVS速度較慢。
- CVS容許任意的滾回，在任意一個已遞交的版本上，儘管着要花些時間。
- CVS不支持文件的複製和重命名。
- CVS沒有原子性提交。
- CVS只支持文檔。
Apache Subversion (SVN)
- 採用了分支管理系統，設計目標是取代CVS，針對CVS的bug和一些缺失的功能，進行了修正和補充。
- 使用統一的版本號。CVS是對每一個文件順序編排版本號，在某一時間各文件的版本號各不相同。而SVN的任何一次提交都會對全部文件增長到同一個新版本號，即便是提交並不涉及的文件。因此，各文件在某任意時間的版本號是相同的。版本號相同的文件構成軟件的一個版本。
- 採用原子提交。一次提交無論是單個仍是多個文件，都是做爲一個總體提交的。在這當中發生的意外例如傳輸中斷，不會引發數據庫的不完整和數據損壞。
- 只能設置目錄的訪問權限，沒法設置單個文件的訪問權限。
- 數據庫爲二進制格式，不方便使用其它軟件讀取數據庫的內容。
ClearCase
- RATIONAL公司開發的配置管理工具，相似於VSS，CVS的做用，可是功能比VSS，CVS強大。
- 管理體系嚴謹，可與Rational的其餘工具好比ClearQuest集成。
- 做爲商業產品，有專門的團隊提供技術支持和維護，適合大公司使用。
- 須要專門的人員的進行管理和配置，對於講求速度或經費和人手有限的項目，門檻較高。
Visual SourceSafe (VSS)
- 美國微軟公司出品的版本控制系統，簡稱VSS。
- 支持Windows系統所支持的全部文件格式。
- 兼容Check out-Modify-Check in（獨佔工做模式）與Copy-Modify-Merge（並行工做模式）。
- VSS集成於微軟公司的Visual Studio產品同時發佈，而且高度。
- VSS使用文件系統做爲存儲方式，每次版本變動時就須要大量地讀寫硬盤。
- VSS 2005之前版本僅適用於快速本地網絡，而沒法實現基於Web的快速操做。
Git
- Git採用了分佈式版本庫的做法，與CVS、SVN的集中式版本控制工具不一樣，不須要服務器端軟件，就能夠運做版本控制，使得源代碼的發佈和交流極其方便。
- Git的速度很快，這對於諸如Linux內核這樣的大項目來講天然很重要。在Git官網有統計：
- Git最爲出色的是它的合併追蹤（merge tracing）能力。
- 實際上內核開發團隊決定開始開發和使用git來做爲內核開發的版本控制系統的時候，世界上開源社羣的反對聲音很多，最大的理由是git太艱澀難懂，從git的內部工做機制來講，的確是這樣。可是隨着開發的深刻，Git的正常使用都由一些友善的命令來執行，使Git的使用體驗獲得改善。
- 做爲開源自由原教旨主義項目，git沒有對版本庫的瀏覽和修改作任何的權限限制，須要經過其餘工具才能夠達到有限的權限控制。
Team Foundation Server (TFS)
- 2005年由微軟所開發的分佈式版本控制／軟件配置管理軟件，爲Visual SourceSafe的後續版本。
- 凸顯了微軟軟件生命週期管理軟件的戰略，並突出了Visual Studio 2010 Ultimate更多的敏捷特性。
- 提供一個平臺來有效協調和支持開發過程當中各個角色，並使他們可以彼此緊密聯繫進行協做。
- 附：Git vs TFS on stack overflow