[2019BUAA软件工程]第1次阅读作业
[2019BUAA軟件工程]第1次閱讀作業
| 作業連接 | [2019BUAA軟件工程]第1次閱讀作業 |
讀《構建之法》的疑惑
個人開發流程（Personal Software Process）自身的時間開銷？各個階段邊界的界定？（書 2.3節）
??在開發過程中按照任務清單對個人每個階段所耗時間進行較準確的記錄是一件不容易的事，因此其本身就會帶來一定的時間開銷。其困難主要體現在各個階段邊界的確定上。在書5.3節有：
- 各個步驟之間是分離的，但在軟件生產過程中的各個步驟不能這樣嚴格分離出來。
- 回溯修改很難甚至不可能，但事軟件生產的過程需要時時回溯。
??在開發過程中，開發者常會在各個階段間回溯（就我而言是這樣的）。這導致處于每個階段的時間是十分離散的。若是每次回溯都做一次記錄而且還是要求工程師自己收集，其帶來的時間開銷顯然是不小的。如何才能有效率地在普遍存在回溯的開發流程中記錄各個階段的耗時呢？
優化與泛化的時機。（書 3.2）
??本章節提出了幾個軟件工程師的思想誤區，其中有過早優化和過早泛化。優化和泛化是編寫一個優秀的軟件應當有的步驟。并且兩者都會涉及代碼的重構。就如同修復Bug一樣，越晚的重構也會帶來更多的工作量和難度。在此過程中仍可能出現新的Bug，因而還要進行一系列的測試。其中泛化帶來的重構可能設計更多的代碼。但過早優化和泛化又會帶來書中所講的糾結于局部忽視全局的問題。那么在軟件開發的過程進行優化和泛化的最好時機是什么時候？
結對編程兩人的分工以及輪轉效率問題。（書 4.5節）
??在書中對于結對編程有以下的描述：
??在結對編程模式下，一對程序員肩并肩、平等地、互補地進行開發工作。他們并排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤、同一個鼠標一起工作。他們一起分析，一起設計，一起寫測試用例，一起編碼，一起做單元測試，一起做集成測試，一起寫文檔等等。
??在書中對于結對編程兩角色的任務有以下的描述：
- 駕駛員：寫設計文檔，進行編碼和單元測試等XP開發流程。
- 領航員：審閱駕駛員文檔；監督駕駛員開發流程的執行；考慮單元測試的覆蓋率；思考是否需要和如何重構；幫助駕駛員解決具體的技術問題；設計TDD中的測試用例。
- 駕駛員和領航員不斷輪換角色，不要連續工作超過一小時，工作一小時休息15分鐘。領航員控制時間。
敏捷開發中的任務規劃與推進問題。（書 6章）
??在書中，作者簡述了Scrum方法論：
- 找出完成產品需要做的事情；
- 決定當前的沖刺需要解決的事情；
- 沖刺。
- 部分成員比較懶惰，趕緊選了比較簡單任務，把難的里給別人。結果別人也不樂意做剩下的任務，最后導致有任務遲遲不解決，沖刺停滯。
- 成員都比較勤勞，但都下意識先選了簡單的，把較難的放到后面再做。但任務間的內在聯系往往要求某些較難的任務優先完成。最后導致一部分簡單的任務需要等待，延誤了工期。
團隊開發中個人效績的評定（書 17.6節）。
??在團隊項目中，對每個成員的效績進行相對正確客觀的評定是相當重要的。在此之前筆者曾參加過團隊項目并且擔任過一次團隊的組長。最終提交作業時老師總會要求附加一個成員工作比例的說明文件。如何將成員的工作具體到一個比例往往是個令人頭疼的事。經過查詢，在博客中博主提出了：個人績效=0.3*工作時間+0.3*任務量+0.4*任務難度的方法。個人認為這種方法將返工所帶來的浪費計入了效績的積極項，明顯是有失妥當的。在博客中博主提出了：個人效績=工作時間*0.5+任務量*任務難度*0.5-返工率（bug數目） 的方法。這種方法雖然考慮了返工帶來的浪費，但無法衡量個人的工作效率。比如其他條件不變的情況下，僅增加工作時間就能能加效績？這令人難以信服。
??歸結起來，在進行個人效績的評定時有兩大角度：過程和結果。對于結果的評定已經有目標與關鍵成果法（OKR），能夠進行比較準確的評定。但如何才能將工作中的過程更準確地加入至個人效績考量中？而或是不管過程只論成果呢？
??一般兩人合作時，每個人的任務是按照工作為粒度進行分工的，比如成員A負責XXX部分的開發（包括測試），成員B負責YYY部分的開發（包括測試）。每個成員都能夠用比較大塊的時間專注于項目某一部分的開發和測試。就我而言，這種大塊、連續的時間是十分必要的，因為每次開始編程時往往需要一段前期預熱來進入狀態（按照復雜度的不同耗費不同時間）。而結對編程則是按照時間粒度進行分工的，進而這種連續的時間被打斷了——駕駛員剛剛找到手感進入狀態就換人。除此之外，在項目中也有一些不適合被打斷的工作。按照書中的駕駛員領航員的例子，貌似現實中的拉力賽沒有駕駛員和領航員在比賽中途停車換位的情況。因此，我對于結對編程所帶來的效率的提高有一定的疑惑。
??在Scrum中工作被細分成多個任務，并使用燃盡圖或看板來管理。整個過程全由團隊成員根據自身情況認領。每個成員的能動性成為項目推進的必要條件。但在現實中，這往往會演變成出人意料的狀態。除了能夠按照理想狀態進行的情況，我列舉出了一下兩種極易產生的人們不愿意見到的情況：
Scrum是靠每個成員的能動性推動的，而Scrum大師的任務僅是在人員間傳遞信息。除此之外，是否應當有某個有一定權力的人來確保沖刺的動力，以及保證任務完成順序符合內在要求？比如PM（雖然書在這部分沒提及PM的作用）？
軟件與軟件工程歷史調研
軟件 = 程序 + 軟件工程
程序？軟件？（來自于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）這個概念，研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。
簡析目前流行的源程序版本管理軟件和項目管理軟件
版本/項目管理軟件使用人數調研
| 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
參考文章：
轉載于:https://www.cnblogs.com/Cookize/p/10463094.html
總結
以上是生活随笔為你收集整理的[2019BUAA软件工程]第1次阅读作业的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HTML5与JavaScript
- 下一篇： 【LeetCode】414. 第三大的数