軟件工程第一次閱讀做業

時間 2019-12-12

標籤軟件工程第一次閱讀简体版

原文原文鏈接

軟件工程第一次閱讀做業

做業介紹

項目	內容
做業所處課程	軟件工程班級博客
做業要求介紹	做業要求
我在這個課程的目標	學習系統化、規範化、量化的方法在軟件開發、操做和維護中的應用
這個做業在哪一個具體方面幫助我實現目標	讓我有機會讀了《構建之法》這樣一本好書，讓我對軟件工程有了必定的認識

做業正文

第一部分：快速看完整部教材，列出你仍然不懂的5到10個問題。

一）出處：第4章兩人合做 P69

函數最好有單一的出口，爲了達到這一目的，可使用goto。html

我對書中的這一句話有一點疑問，由於以前老師在教咱們語言的時候明確指出儘可能不要使用goto之類的跳轉指令。固然，若是一個函數很是複雜使用goto統一返回值可能會使結構更清晰，可是我認爲若是函數比較簡單的話仍是不要使用goto比較好。git

二）出處：第4章兩人合做 P79

在結對編程中，由於有隨時的複審和交流，程序各方面的質量取決於一對程序員中各方面水平較高的那一位。程序員

我不是對這句話有異議，而是有一些由這句話所引起的思考。在本書介紹結對編程的章節中，彷佛沒有明確指出對結對的兩我的的水平的要求。然而我認爲，並非任意的兩我的都適合結對，若是兩我的水平相差太多，那麼結對將失去本來的魅力。就像上面引用的語句所說，結對編程的成品質量由水平較高的那我的決定，那麼若是兩我的水平差別較大，以致於其中一位幾乎對另外一位有全方位的水平碾壓，那麼不論這個高水平者處於駕駛員仍是領航員的位置，整個編程的過程將會幾乎由他一人執掌，他將不間斷地把本身的想法灌輸給另外一我的，而另外一我的就成了徹底的「助手」或者「學生」。能夠想見，在本課程的結對做業中，這種現象將會發生。這樣的狀況顯然是不合理的，所以我認爲結對編程對兩名程序員的要求是水平差別不能太大，兩人必須都具有幫助對方的能力。github

三）出處：第11章軟件設計與實現 P225

「一圖勝千言」，人們常常用圖形類幫助他們瞭解概念，強化記憶。思惟導圖是其中的一個例子…… 思惟導圖形式靈活，適用於不少鼓勵探索、發散思惟的場合（如頭腦風暴會議），可是它的圖形元素缺少嚴格的語法和語義。數據庫

我以爲做者是想用思惟導圖和其餘更加嚴謹、更具備工程化特色的圖模型作對比，以突出它們的特色。可是對此我有個雞蛋裏挑骨頭的小意見，我認爲就如做者所說，思惟導圖是不少鼓勵探索、發散思惟的場合的選擇，而這樣的場合通常存在於設計的最初階段，所以思惟導圖必定程度上有筆記、會議記錄的意思，而其餘的圖，能夠經過思惟導圖的啓發，進行進一步設計而得出，所以我認爲把思惟導圖視爲其餘圖的前置形式更合理一點。編程

四）出處：第13章軟件測試 P288

阿超：那不必定，即便你的軟件產品功能100%符合Spec的要求，用戶也可能很是恨你的軟件。這時，就說明測試人員沒有盡到責任，由於測試人員要從用戶的角度出發來測試軟件。小程序

我以爲「從用戶的角度」這一點不該該是測試人員所關心的，它應該包含在Spec，若是測試人員進行了完整的測試，那麼即便最後用戶「可能很是恨你的軟件」，責任也不該歸咎於測試人員。瀏覽器

五）出處：第16章 IT行業的創新 P349

這一章的《迷思之六：技術是創新的關鍵》小節舉了「銥星計劃」做爲反例來講明技術的創新不必定是創新的關鍵，創新還有許多其餘方面。我贊成書中的說法，可是我認爲把「銥星計劃」做爲反例有些不妥。雖然銥星計劃是技術創新的表明，可是其失敗不能說明技術的失敗，由於銥星計劃的失敗主要是對自身產品定位的不許確以及對市場的錯誤估計形成的。若是其一開始就把產品定位成極限條件下的戶外通信設施，並制定合理的銷售計劃，可能其實際銷售狀況就不會與其銷售計劃有現在咱們見到這樣大的落差，而「銥星計劃」甚至可能會成爲技術創新成功的典範。服務器

第二部分：請問「軟件」和「軟件工程」這些詞彙是如何出現的 - 什麼時候、何地、何人？

軟件（software）
- 時間：1958
- 地點：Tukey's paper "The Teaching of Concrete Mathematics"
- 人物：John Tukey
軟件工程 (software engineering)
- 時間：June 1965
- 地點：a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION
- 人物：Margaret Hamilton

第三部分：【附加題】你們知道了軟件和軟件工程的起源，請問軟件工程發展的過程當中有什麼你以爲有趣的冷知識和故事？

約摸在1985年，微軟的一個叫Steve Hazelrig的工程師在寫Mac Excel版本的打印功能，那時候激光打印機很貴，並且離辦公室也不近。他懶得常常跑到打印機那兒取打印紙檢查打印效果，就寫了一個小程序，把要輸出到打印機的圖像顯示在屏幕上，還有一個放大鏡功能能夠把局部放大以檢查每一個像素的位置及效果。這時一個PM路過看到了這個小工具，說，這麼酷的東西，爲啥不作成一個功能呢？
因此後來微軟的編輯軟件都有了「打印預覽」這一功能。然而，用戶們並無正式地要求這一功能。（引用自《構建之法》第9章）svn

第四部分：上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些，各有什麼優缺點？

Name	Users	Projects
Assembla	Unknown	526,581+
Phabricator	Unknown	Unknown
GitHub	31,000,000	100,000,000
Bitbucket	5,000,000	Unknown
Launchpad	3,965,288	40,881
SourceForge	3,700,000	500,000
GitLab	100,000	546,000
GNU Savannah	93,346	3,848
OSDN	54,826	6,294
Ourproject.org	6,353	1,846

二）工具的優缺點

資料來源：博客

GitHub

優勢

免費且開源
用於敏捷高效地處理任何或小或大的項目。
Git支持分支功能（branch）。若是你想開發一個新的產品功能，你能夠創建一個分支，對這個分支的進行修改，而不至於會影響到主支上的代碼。
可拿Git作備份系統，或者同步兩臺機器的文檔，很方便。
支持離線工做。本地提交能夠稍後提交到服務器上，不用和集中的代碼管理服務器交互。只有最終完成的版本才須要向一箇中心的集中的代碼管理服務器提交。
Git 提交都是原子的，且是整個項目範圍的，而不像 CVS 中同樣是對每一個文件的。
Git 中的每一個工做樹都包含一個具備完整項目歷史的倉庫。
簡易的初始化。對於隨便寫兩行代碼就要放到代碼管理工具裏的人來講，再合適不過。

缺點
學習成本大。由淺入深的過分很漫長，須要大量時間的投入。
Git版本庫須要頻繁的手動維護。

SVN

優勢
對目錄的組織的管理更加方便。SVN不光對文件作版本跟蹤，也會對目錄作版本跟蹤。所以能夠根據項目的須要，對目錄結構隨時進行修改，能夠把現有的目錄移動到新的地方。
保證提交操做的完整性。SVN對提交操做的處理方式相似數據庫的事務處理，要麼所有成功，要麼所有無效，保證了原子性。
SVN容許一個文件有任意多的可命名屬性，功能十分徹底。

缺點
不能離線工做。全部的版本信息都放在服務器上。若是脫離了服務器，開發者基本上能夠說是沒法工做的。
提交、更新、瀏覽歷史的速度慢。耗費CPU資源。
代碼不能及時提交。強迫使用者即時處理衝突，而後才能提交。
不能恢復到歷史版本。SVN記錄了單個文件的歷史版本，但沒有記錄全局版本，不能恢復到上次的狀態。
需手動「cleanup」。不少評論回覆這點讓他們抓狂。

Mercurial

優勢
學習門檻較低。總體上看，hg須要掌握的命令要比git少不少。
能夠一鍵徹底恢復到歷史版本的某一個切面。
封裝好。相比git，hg不多暴露一些實現內的細節。
照顧 svn 的遷移用戶。hg 的不少命令是遷移自 svn 命令的，目標實際上是爲了讓 svn 用戶更容易接受。這使得已經習慣 svn 命令的團隊，幾乎零成本的切換到 hg。
hg 的 pull 更多的時候可讓你避免建立分支。hg 比如蘋果系統，git 比如 Linux，前者在經常使用命令上更好用更易用，後者在功能上更強大更靈活。
hg的版本庫不須要維護。

缺點
分支管理不靈活。Mercurial的branch管理和Git相比不是很方便。大型團隊不肯使用。

Microsoft TFS

優勢
任務版上能將需求、項目進度盡收眼底，對於小團隊而言，比甘特圖更有用集成了項目管理、版本控制、BUG 跟蹤。
能有效實現 SCRUM能與 VS 無縫接合。

缺點
搭建、維護tfs比較複雜，硬件要求也比較高。
整個系統是用 asp 實現的，用瀏覽器訪問至關慢。