[2019BUAA软件工程]第1次阅读作业
[2019BUAA軟件工程]第1次閱讀作業(yè)
| 作業(yè)連接 | [2019BUAA軟件工程]第1次閱讀作業(yè) |
讀《構(gòu)建之法》的疑惑
個(gè)人開發(fā)流程（Personal Software Process）自身的時(shí)間開銷？各個(gè)階段邊界的界定？（書 2.3節(jié)）
??在開發(fā)過程中按照任務(wù)清單對個(gè)人每個(gè)階段所耗時(shí)間進(jìn)行較準(zhǔn)確的記錄是一件不容易的事，因此其本身就會(huì)帶來一定的時(shí)間開銷。其困難主要體現(xiàn)在各個(gè)階段邊界的確定上。在書5.3節(jié)有：
- 各個(gè)步驟之間是分離的，但在軟件生產(chǎn)過程中的各個(gè)步驟不能這樣嚴(yán)格分離出來。
- 回溯修改很難甚至不可能，但事軟件生產(chǎn)的過程需要時(shí)時(shí)回溯。
??在開發(fā)過程中，開發(fā)者常會(huì)在各個(gè)階段間回溯（就我而言是這樣的）。這導(dǎo)致處于每個(gè)階段的時(shí)間是十分離散的。若是每次回溯都做一次記錄而且還是要求工程師自己收集，其帶來的時(shí)間開銷顯然是不小的。如何才能有效率地在普遍存在回溯的開發(fā)流程中記錄各個(gè)階段的耗時(shí)呢？
優(yōu)化與泛化的時(shí)機(jī)。（書 3.2）
??本章節(jié)提出了幾個(gè)軟件工程師的思想誤區(qū)，其中有過早優(yōu)化和過早泛化。優(yōu)化和泛化是編寫一個(gè)優(yōu)秀的軟件應(yīng)當(dāng)有的步驟。并且兩者都會(huì)涉及代碼的重構(gòu)。就如同修復(fù)Bug一樣，越晚的重構(gòu)也會(huì)帶來更多的工作量和難度。在此過程中仍可能出現(xiàn)新的Bug，因而還要進(jìn)行一系列的測試。其中泛化帶來的重構(gòu)可能設(shè)計(jì)更多的代碼。但過早優(yōu)化和泛化又會(huì)帶來書中所講的糾結(jié)于局部忽視全局的問題。那么在軟件開發(fā)的過程進(jìn)行優(yōu)化和泛化的最好時(shí)機(jī)是什么時(shí)候？
結(jié)對編程兩人的分工以及輪轉(zhuǎn)效率問題。（書 4.5節(jié)）
??在書中對于結(jié)對編程有以下的描述：
??在結(jié)對編程模式下，一對程序員肩并肩、平等地、互補(bǔ)地進(jìn)行開發(fā)工作。他們并排坐在一臺(tái)電腦前，面對同一個(gè)顯示器，使用同一個(gè)鍵盤、同一個(gè)鼠標(biāo)一起工作。他們一起分析，一起設(shè)計(jì)，一起寫測試用例，一起編碼，一起做單元測試，一起做集成測試，一起寫文檔等等。
??在書中對于結(jié)對編程兩角色的任務(wù)有以下的描述：
- 駕駛員：寫設(shè)計(jì)文檔，進(jìn)行編碼和單元測試等XP開發(fā)流程。
- 領(lǐng)航員：審閱駕駛員文檔；監(jiān)督駕駛員開發(fā)流程的執(zhí)行；考慮單元測試的覆蓋率；思考是否需要和如何重構(gòu)；幫助駕駛員解決具體的技術(shù)問題；設(shè)計(jì)TDD中的測試用例。
- 駕駛員和領(lǐng)航員不斷輪換角色，不要連續(xù)工作超過一小時(shí)，工作一小時(shí)休息15分鐘。領(lǐng)航員控制時(shí)間。
敏捷開發(fā)中的任務(wù)規(guī)劃與推進(jìn)問題。（書 6章）
??在書中，作者簡述了Scrum方法論：
- 找出完成產(chǎn)品需要做的事情；
- 決定當(dāng)前的沖刺需要解決的事情；
- 沖刺。
- 部分成員比較懶惰，趕緊選了比較簡單任務(wù)，把難的里給別人。結(jié)果別人也不樂意做剩下的任務(wù)，最后導(dǎo)致有任務(wù)遲遲不解決，沖刺停滯。
- 成員都比較勤勞，但都下意識(shí)先選了簡單的，把較難的放到后面再做。但任務(wù)間的內(nèi)在聯(lián)系往往要求某些較難的任務(wù)優(yōu)先完成。最后導(dǎo)致一部分簡單的任務(wù)需要等待，延誤了工期。
團(tuán)隊(duì)開發(fā)中個(gè)人效績的評定（書 17.6節(jié)）。
??在團(tuán)隊(duì)項(xiàng)目中，對每個(gè)成員的效績進(jìn)行相對正確客觀的評定是相當(dāng)重要的。在此之前筆者曾參加過團(tuán)隊(duì)項(xiàng)目并且擔(dān)任過一次團(tuán)隊(duì)的組長。最終提交作業(yè)時(shí)老師總會(huì)要求附加一個(gè)成員工作比例的說明文件。如何將成員的工作具體到一個(gè)比例往往是個(gè)令人頭疼的事。經(jīng)過查詢，在博客中博主提出了：個(gè)人績效=0.3*工作時(shí)間+0.3*任務(wù)量+0.4*任務(wù)難度的方法。個(gè)人認(rèn)為這種方法將返工所帶來的浪費(fèi)計(jì)入了效績的積極項(xiàng)，明顯是有失妥當(dāng)?shù)摹Ｔ诓┛椭胁┲魈岢隽?#xff1a;個(gè)人效績=工作時(shí)間*0.5+任務(wù)量*任務(wù)難度*0.5-返工率（bug數(shù)目） 的方法。這種方法雖然考慮了返工帶來的浪費(fèi)，但無法衡量個(gè)人的工作效率。比如其他條件不變的情況下，僅增加工作時(shí)間就能能加效績？這令人難以信服。
??歸結(jié)起來，在進(jìn)行個(gè)人效績的評定時(shí)有兩大角度：過程和結(jié)果。對于結(jié)果的評定已經(jīng)有目標(biāo)與關(guān)鍵成果法（OKR），能夠進(jìn)行比較準(zhǔn)確的評定。但如何才能將工作中的過程更準(zhǔn)確地加入至個(gè)人效績考量中？而或是不管過程只論成果呢？
??一般兩人合作時(shí)，每個(gè)人的任務(wù)是按照工作為粒度進(jìn)行分工的，比如成員A負(fù)責(zé)XXX部分的開發(fā)（包括測試），成員B負(fù)責(zé)YYY部分的開發(fā)（包括測試）。每個(gè)成員都能夠用比較大塊的時(shí)間專注于項(xiàng)目某一部分的開發(fā)和測試。就我而言，這種大塊、連續(xù)的時(shí)間是十分必要的，因?yàn)槊看伍_始編程時(shí)往往需要一段前期預(yù)熱來進(jìn)入狀態(tài)（按照復(fù)雜度的不同耗費(fèi)不同時(shí)間）。而結(jié)對編程則是按照時(shí)間粒度進(jìn)行分工的，進(jìn)而這種連續(xù)的時(shí)間被打斷了——駕駛員剛剛找到手感進(jìn)入狀態(tài)就換人。除此之外，在項(xiàng)目中也有一些不適合被打斷的工作。按照書中的駕駛員領(lǐng)航員的例子，貌似現(xiàn)實(shí)中的拉力賽沒有駕駛員和領(lǐng)航員在比賽中途停車換位的情況。因此，我對于結(jié)對編程所帶來的效率的提高有一定的疑惑。
??在Scrum中工作被細(xì)分成多個(gè)任務(wù)，并使用燃盡圖或看板來管理。整個(gè)過程全由團(tuán)隊(duì)成員根據(jù)自身情況認(rèn)領(lǐng)。每個(gè)成員的能動(dòng)性成為項(xiàng)目推進(jìn)的必要條件。但在現(xiàn)實(shí)中，這往往會(huì)演變成出人意料的狀態(tài)。除了能夠按照理想狀態(tài)進(jìn)行的情況，我列舉出了一下兩種極易產(chǎn)生的人們不愿意見到的情況：
Scrum是靠每個(gè)成員的能動(dòng)性推動(dòng)的，而Scrum大師的任務(wù)僅是在人員間傳遞信息。除此之外，是否應(yīng)當(dāng)有某個(gè)有一定權(quán)力的人來確保沖刺的動(dòng)力，以及保證任務(wù)完成順序符合內(nèi)在要求？比如PM（雖然書在這部分沒提及PM的作用）？
軟件與軟件工程歷史調(diào)研
軟件 = 程序 + 軟件工程
程序？軟件？（來自于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是第一位主張計(jì)算機(jī)不只可以用來算數(shù)的人，發(fā)表了第一段分析機(jī)用的算法，被公認(rèn)為史上第一位認(rèn)識(shí)計(jì)算機(jī)完全潛能的人，也是史上第一位計(jì)算機(jī)程序員。同時(shí)，為紀(jì)念A(yù)da Lovelace而命名的Ada語言是一種表現(xiàn)能力很強(qiáng)的通用程序設(shè)計(jì)語言。它是美國國防部為克服軟件開發(fā)危機(jī)，耗費(fèi)巨資，歷時(shí)近20年研制成功的。它被譽(yù)為第四代計(jì)算機(jī)語言的最成功代表。
軟件的由來：
??按照詞義上的解釋，軟件和程序的含義相近，但是軟件的概念比程序更晚出現(xiàn)。在von Neumann architecture和Harvard architecture的提出以及程序存儲(chǔ)計(jì)算機(jī)（stored-program computer）出現(xiàn)之后，計(jì)算機(jī)能夠?qū)⒊绦虼鎯?chǔ)并在內(nèi)存中運(yùn)行。計(jì)算機(jī)的底層硬件逐漸與程序應(yīng)用分離，軟件的概念逐漸產(chǎn)生。根據(jù)維基百科對于軟件發(fā)展的描述有：
??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.
??在《構(gòu)建之法》一書中對軟件的定義為：軟件 = 程序 + 軟件工程。如此說來，從開發(fā)的角度來看真正意義上的軟件應(yīng)當(dāng)是在軟件工程的提出時(shí)誕生的。
軟件工程——軟件危機(jī)的產(chǎn)物
出現(xiàn)背景：
??20世紀(jì)下半葉出現(xiàn)的軟件危機(jī)，軟件開發(fā)在預(yù)算、開發(fā)時(shí)間、成品質(zhì)量、需求滿足度、項(xiàng)目管理、代碼維護(hù)等方面出現(xiàn)巨大問題。據(jù)維基百科描述：
??硬件成長率每年大約30％，軟件每年只勉強(qiáng)以4～7％速度在成長，信息系統(tǒng)的交付日期一再延后，許多待開發(fā)的軟件系統(tǒng)無法如期開始。1960年代軟件開發(fā)成本占總成本20％以下；1970年代軟件成本已達(dá)總成本80％以上，軟件維護(hù)費(fèi)用在軟件成本中高達(dá)65％。1986年公布的數(shù)據(jù)，所有驗(yàn)收的外包軟件中，竟然只有4％可用，其余96％卻是不堪一用。大部分的企業(yè)自行開發(fā)的信息系統(tǒng)中，有四分之三也是功敗垂成。因此軟件維護(hù)成本居高不下，軟件產(chǎn)品質(zhì)量低落是最主要的原因。
??1995年，Standish Group研究機(jī)構(gòu)以美國境內(nèi)8000個(gè)軟件項(xiàng)目作為調(diào)查樣本，調(diào)查結(jié)果顯示，有84％軟件計(jì)劃無法于既定時(shí)間、經(jīng)費(fèi)中完成，超過30％的項(xiàng)目于運(yùn)行中被取消，項(xiàng)目預(yù)算平均超出189％。
概念的提出：
??1968年秋季，NATO（北約） 的科技委員會(huì)召集了近50名一流的編程人員、計(jì)算機(jī)科學(xué)家和工業(yè)界巨頭，討論和制定擺脫“軟件危機(jī)”的對策。在那次會(huì)議上第一次提出了軟件工程（software engineering）這個(gè)概念，研究和應(yīng)用如何以系統(tǒng)性的、規(guī)范化的、可定量的過程化方法去開發(fā)和維護(hù)軟件，以及如何把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來的學(xué)科。
簡析目前流行的源程序版本管理軟件和項(xiàng)目管理軟件
版本/項(xiàng)目管理軟件使用人數(shù)調(diào)研
| GitHub | 31 million users | 100 million |
| GitLab | 100,000 organizations | ------ |
| Bitbucket | 6 million users | ------ |
| Bugzilla | A large number | ------ |
| Trac | list of uesrs | ------ |
部分版本/項(xiàng)目管理軟件比較
Concurrent Versions System (CVS)
- 相較于SVN，CVS速度較慢。
- CVS允許任意的滾回，在任意一個(gè)已遞交的版本上，盡管著要花些時(shí)間。
- CVS不支持文件的復(fù)制和重命名。
- CVS沒有原子性提交。
- CVS只支持文檔。
Apache Subversion (SVN)
- 采用了分支管理系統(tǒng)，設(shè)計(jì)目標(biāo)是取代CVS，針對CVS的bug和一些缺失的功能，進(jìn)行了修正和補(bǔ)充。
- 使用統(tǒng)一的版本號(hào)。CVS是對每個(gè)文件順序編排版本號(hào)，在某一時(shí)間各文件的版本號(hào)各不相同。而SVN的任何一次提交都會(huì)對所有文件增加到同一個(gè)新版本號(hào)，即使是提交并不涉及的文件。所以，各文件在某任意時(shí)間的版本號(hào)是相同的。版本號(hào)相同的文件構(gòu)成軟件的一個(gè)版本。
- 采用原子提交。一次提交不管是單個(gè)還是多個(gè)文件，都是作為一個(gè)整體提交的。在這當(dāng)中發(fā)生的意外例如傳輸中斷，不會(huì)引起數(shù)據(jù)庫的不完整和數(shù)據(jù)損壞。
- 只能設(shè)置目錄的訪問權(quán)限，無法設(shè)置單個(gè)文件的訪問權(quán)限。
- 數(shù)據(jù)庫為二進(jìn)制格式，不方便使用其它軟件讀取數(shù)據(jù)庫的內(nèi)容。
ClearCase
- RATIONAL公司開發(fā)的配置管理工具，類似于VSS，CVS的作用，但是功能比VSS，CVS強(qiáng)大。
- 管理體系嚴(yán)謹(jǐn)，可與Rational的其他工具比如ClearQuest集成。
- 作為商業(yè)產(chǎn)品，有專門的團(tuán)隊(duì)提供技術(shù)支持和維護(hù)，適合大公司使用。
- 需要專門的人員的進(jìn)行管理和配置，對于講求速度或經(jīng)費(fèi)和人手有限的項(xiàng)目，門檻較高。
Visual SourceSafe (VSS)
- 美國微軟公司出品的版本控制系統(tǒng)，簡稱VSS。
- 支持Windows系統(tǒng)所支持的所有文件格式。
- 兼容Check out-Modify-Check in（獨(dú)占工作模式）與Copy-Modify-Merge（并行工作模式）。
- VSS集成于微軟公司的Visual Studio產(chǎn)品同時(shí)發(fā)布，并且高度。
- VSS使用文件系統(tǒng)作為存儲(chǔ)方式，每次版本變更時(shí)就需要大量地讀寫硬盤。
- VSS 2005以前版本僅適用于快速本地網(wǎng)絡(luò)，而無法實(shí)現(xiàn)基于Web的快速操作。
- Git
- Git采用了分布式版本庫的作法，與CVS、SVN的集中式版本控制工具不同，不需要服務(wù)器端軟件，就可以運(yùn)作版本控制，使得源代碼的發(fā)布和交流極其方便。
- Git的速度很快，這對于諸如Linux內(nèi)核這樣的大項(xiàng)目來說自然很重要。在Git官網(wǎng)有統(tǒng)計(jì)：
- Git最為出色的是它的合并追蹤（merge tracing）能力。
- 實(shí)際上內(nèi)核開發(fā)團(tuán)隊(duì)決定開始開發(fā)和使用git來作為內(nèi)核開發(fā)的版本控制系統(tǒng)的時(shí)候，世界上開源社群的反對聲音不少，最大的理由是git太艱澀難懂，從git的內(nèi)部工作機(jī)制來說，的確是這樣。但是隨著開發(fā)的深入，Git的正常使用都由一些友善的命令來執(zhí)行，使Git的使用體驗(yàn)得到改善。
- 作為開源自由原教旨主義項(xiàng)目，git沒有對版本庫的瀏覽和修改做任何的權(quán)限限制，需要通過其他工具才可以達(dá)到有限的權(quán)限控制。
Team Foundation Server (TFS)
- 2005年由微軟所開發(fā)的分布式版本控制／軟件配置管理軟件，為Visual SourceSafe的后續(xù)版本。
- 凸顯了微軟軟件生命周期管理軟件的戰(zhàn)略，并突出了Visual Studio 2010 Ultimate更多的敏捷特性。
- 提供一個(gè)平臺(tái)來有效協(xié)調(diào)和支持開發(fā)過程中各個(gè)角色，并使他們能夠彼此緊密聯(lián)系進(jìn)行協(xié)作。
- 附：Git vs TFS on stack overflow
參考文章：
轉(zhuǎn)載于:https://www.cnblogs.com/Cookize/p/10463094.html
總結(jié)
以上是生活随笔為你收集整理的[2019BUAA软件工程]第1次阅读作业的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HTML5与JavaScript
- 下一篇： 【LeetCode】414. 第三大的数