軟件工程第1次閱讀做業

第一部分 讀後疑問

問題一

在第一章 緒論的第7頁 我看到了這樣的一段文字：

若是一架民用飛機上有需求，用戶使用它的機率是萬分之一，你還要作這個功能嗎？

個人疑問是：每個細微的需求都須要獲得知足嗎？
這裏像是玩了一個文字遊戲，由於只提到了需求使用的機率是百萬分之一，可是並無作其餘的任何條件約束。我按照我最真實的想法，選擇了直接忽略掉這個需求，但以後才知道這個百萬分之一是飛機的安全方面的訴求，那麼它的確是有必要去作的。也許是寫在緒論這裏爲了言簡意賅，因此說的比較不嚴謹，我認爲大多數使用機率極低的功能都是能夠砍掉的，由於面面俱到是一種臃腫的實現方式，咱們應該爲用戶提供簡明方便的使用方法。好比咱們經常使用的office辦公軟件，也許它也能夠包含許多百萬分之一律率使用到的功能，那麼它的界面和下拉菜單對於用戶來講仍是友好的嗎？因此我認爲商業化的軟件反而要勇於刪減本身的功能，從而提供良好的用戶體驗。
其實本書在後面的章節對於相似的問題也給出了很好的解決方案。在書中的第8章 需求分析中已經有提到，對於需求要考慮他們的優先級，要着重實現那些殺手功能，而且參照在166頁提到的功能的象限劃分，對於一個軟件的不一樣功能，咱們能夠採用維持、抵消、優化、差別化和不作五種不一樣的方式來應對。對於那些基本用不到的功能而且不是必要需求的殺手功能，我仍是秉承本身的觀點，大可不作。

問題二

在第三章 軟件工程師的成長 的 3.2思惟誤區 49頁 我看到了這樣的一段文字：

過早優化是一切罪惡的根源。

個人疑問是：是否能夠在寫軟件的某個模塊的時候進行適度的優化呢？
其實在以前的程序編寫時也遇到過相似的問題，好比一個類中定義了不少的屬性和方法，而且這些屬性和方法在其餘的地方也獲得了調用，可是若是在總體寫完後想要對這個類內部的一些方法進行優化，有時候會增補或者刪掉一些屬性，或者可能改變某些方法調用的參數、返回值或者是它的功能，那麼在其餘調用的地方就要進行相應的修改，這樣可能會形成很大的工程量而且容易引起新的BUG。若是我自己的軟件工程水平不高，沒有在寫程序前高屋建瓴的想好全部的佈局，那麼在優化的時候遇到這樣的問題就很麻煩，因此我以前會寫完一個模塊後嘗試進行一些優化，而且感受效果也不錯。因此我以爲這句話說的太絕對了，應該是 對於某些極致優化的過度執著纔是一切罪惡的根源。

問題三

在讀完第六章 敏捷流程 和 第九章 項目經理 以後我有這樣一個疑問：
既然敏捷已經成爲了一種風潮，而且在敏捷的體系中你們集思廣益，不須要PM來制定什麼計劃，那麼PM這個職位還有存在的必要嗎？PM會最終被淘汰掉嗎？但我又始終以爲一個敏捷的團隊也能夠擁有一個PM來起到燈塔做用，傳統的體系與敏捷的體系能結合嗎？

問題四

在第十一章 軟件的設計與實現 中提到了構建這個概念，而且在235頁有這樣的一段話：

在咱們的全球調查中，咱們發現成功的公司中有94%天天或者至少每週完成構建，而不成功的公司絕大多數每個月甚至更少的去作構建``````

個人疑問是：構建具體指的是什麼？是說每日對於要作的軟件的一個功能的規劃嗎？由於這本書的名字就是《構建之法》，我理解的構建就是文章對於軟件的結構以及團隊組成、合做等一整套的方法。但這些都是宏觀上的，那麼每日要作的構建到底是幹什麼，怎麼幹。後文雖然有一個對話形式的解讀，可是尚未弄清楚。

問題五

在第十六章 IT行業的創新 中，有這樣一段話：

創新的人士的關鍵特色不是喜歡冒險，也不是躲避風險，而是從錯誤中回覆並繼續努力，就像文言文說的「屢敗屢戰」。

個人疑問是：風險究竟要不要躲避？由於不少的創新對於我的或者團隊而言都是極大的風險，好比資金、時間、或者其餘機遇。如何評估本身所謂的「創新」是真正的創新，而不是徒勞無功的嘗試呢？

第二部分 「軟件」 和 「軟件工程」 這些詞彙是如何出現的

軟件

-什麼時候：1935年
-何地：美國
-何人：Alan Mathison Turing
「軟件」一詞是圖靈的一篇題目爲「omputable numbers with an application to the Entscheidungsproblem (decision problem)」的論文中提出的

軟件工程

-什麼時候：1968年
-何地：美國
-何人：Margaret Hamilton
「軟件工程」一詞是Margaret Hamilton在阿波羅計劃期間發明創造出來的

第三部分 軟件工程發展過程當中有趣的冷知識和故事

在2012年夏季奧林匹克運動會開幕典禮上，伯納斯-李得到了「萬維網發明者」的美譽。他本人也參與了開幕典禮，在一臺 NeXT 計算機前工做。他在 Twitter 上發表消息說：「這是給全部人的」，體育館內的 LCD 光管隨即顯示出文字來。

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

Microsoft TFS

-優勢：是一個工做流協做的引擎，它容許一個團隊使用他們自定義的流程，並使用在項目歷史中實時收集起來的一個集中的數據倉庫。集成性。版本控制系統和工做項存儲器在註冊時集成在一塊兒。當註冊時，能夠將其與一個或多個工做項關聯。而且任務版上能將需求、項目進度盡收眼底，對小團體適用。
-缺點：TFS經過複雜的看似功能強大配置管理，將聯機看作是整個項目週期的常態，這在實際使用中形成極大的不便。能應用起來的團隊、公司的數量極少，多數真正用起來，也就是源代碼管理這部分，這也僅僅是佔TFS極小部分功能。

Github

-優勢：基於web，容許你使用Git的源代碼管理功能，而且上面有大量的開源程序。
-缺點：訪問速度緩慢，對於企業而言使用起來成本較高。

SVN

-優勢：SVN容許一個文件有任意都的可命名屬性，功能十分完備，而且SVN會關心全部的文件類型，不須要你來手工操做。
-缺點：要將權限控制文件保存爲svn支持的UTF-8格式，一個庫能夠有多個工做目錄但一個工做目錄只能對應一個庫雖然能夠更改庫位置可是要求很嚴格，庫中文件存放方式，看不到文件真正的內容。並且SVN速度超慢。提交、更新、瀏覽歷史的速度都很慢。

Trac

-優勢：力求不影響現有團隊的開發過程，良好的擴充性，以里程碑的方式進行項目管理。而且是一個爲軟件開發項目須要而集成了Wiki和問題跟蹤管理系統的應用平臺，是一個開源軟件應用。
-缺點：功能不是很強大，使用有很大的侷限性。

Coding

-優勢：支持設置保護分支，被保護的分支只有指定的一些成員才能夠寫（更新），其餘成員只有讀的權限。這在開發中能夠避免一些重要的分支被成員隨便修改。而在默認狀況下，項目內的全部成員都有對項目的全部分支的所有權限，包括讀、寫、刪除等等。
-缺點：產品的改進也很是少，基本已經落後。

Bugzilla

-優勢：是一個開源的缺陷跟蹤系統，它能夠管理軟件開發中缺陷的提交，修復，關閉等整個生命週期。而且具備強大的檢索功能， 用戶可配置的經過Email公佈Bug變動。
-缺點：是專門爲UNIX定製開發的，不是全部的操做系統均可以使用。

Mercurial

-優勢：Mercurial 是一種輕量級分佈式版本控制系統，採用 Python 語言實現，易於學習和使用，擴展性強。而且它管理起來很輕鬆。
-缺點：不是很靈活。

排名

-1. github：約31,000,000用戶量 -2. SourceForge：約3,700,000用戶量 -3. Bitbucket：約5,000,000用戶量