軟件工程第一次閱讀做業

項目	內容
本做業屬於北航軟件工程課程	博客園班級連接
做業要求請點擊連接查看	做業要求
我在這門課程的目標是	成爲一個具備必定經驗的軟件開發人員
這個做業在哪一個具體方面幫助我實現目標	讓我對本身目前的情況有一個更加清醒的認識

1. 快速閱讀完教材仍然不懂的問題

1. 第4章 兩人合做 4.3.4 如何處理C++中的類

1. 類型繼承

   1）僅在必要時，才使用類型繼承

   2）用const標註只讀的參數

   3）用const標註不改變數據的參數

個人疑惑點主要是在第1條原則。在上上學期的面向對象課程中，咱們學到了類的繼承是一個很實用的方法，它能夠幫助咱們減小代碼之間的重複，而且體現出設計的層次感。但《構建之法》的意思彷佛是在說，要儘可能避免使用類型繼承。在實際的工程中，類型繼承是被提倡使用的嗎？

2. 第4章 兩人合做 4.5.3 不間斷地複審

結對編程中駕駛員和領航員的角色要常常互換，避免長時間緊張工做致使觀察力和判斷力降低。

前文中做者提到，結對編程能夠類比於現實中的一些搭檔關係：越野賽車（駕駛、領航員）、駕駛飛機（駕駛、副駕駛）。可是在這些領域中，搭檔的職務每每是固定的，這是由於兩我的每每在不一樣的崗位上有不一樣的經驗，讓在某一個崗位具備更豐富經驗的人去擔任這一職務，比兩我的交換崗位、在本身不熟悉的領域工做，要合適的多。所以，結對編程中駕駛員和領航員常常角色互換，是不是一個合理的選擇？

3. 第12章 用戶體驗 12.1.3 軟件服務始終都要記住用戶的選擇

我贊成第一印象很重要，可是當用戶已是第N次使用你的產品時，你的UI可否爲這些用戶提供方便呢？

軟件開發、尤爲是面向大量用戶的軟件開發，一個很困難的問題就是如何定義「方便」以及「好用」這種很主觀的概念。以最近微信發佈的7.0.0版本爲例，整個微信的界面底色由黑色變成了白色，這一改動在用戶的評論當中譭譽參半，一部分人（好比我）認爲這個版本的審美比以前的不知高到哪裏去了，而另外一部分用戶則認爲新版微信亮得晃眼睛。做爲PM、開發人員、UI設計師，該怎麼權衡不一樣用戶對於同一套UI的相反評價？

4. 第13章 軟件測試 13.3.2 測試工做中的文檔 2. 測試用例

一個軟件有不少可能的輸入和環境參數，咱們沒有能力窮舉全部的可能，也沒有必要。咱們能夠運用不一樣的設計測試用例的方法，有效地生成測試用例。

我在作軟件測試的時候，遇到的最困難的問題是如何處理有反作用的方法。這裏的「有反作用」表明該方法與外界有交互，好比從控制檯讀入一行字符串，又或者是鏈接一個數據庫。若是我想對這些方法進行測試，就須要模擬出一整個環境，這在緊張的快速開發中是難以作到的。所以，在設計單元測試用例時，我每每會選擇跳過這些有反作用的方法，只測試那些純函數。但軟件的Bug每每是在這些與系統有交互的地方產生的。因此我想知道，該如何爲這些方法設計完備的測試用例，尤爲是當方法的反作用很複雜、環境難以模擬的時候？

5. 第14章 質量保障 14.1.2 軟件工程的質量

軟件開發過程當中的可見性（ Visibility）

咱們看這個項目開發過程當中的場景：

領導：進度如何？

答：可能快了。

問：能看看演示嗎？

答：嗯，不知道。可能到了項目的最後一天才能看......

上面的對話不能說明軟件的功能如何（也許最後發現功能很是驚豔），項目的可見性是很是差的。不可是小規模、業餘項目會出現這樣的狀況，大規模的專業團隊也是如此。

上面的場景是我在項目開發中常常遇到的實際問題。不少時候，我編寫的軟件是偏後臺的，甚至只是一個命令行交互程序，不像Web開發和GUI開發那樣具備很是好的可見性。還有一些狀況是，個人軟件是高度模塊化的，只有當最後一個模塊完成的那一刻纔可以組合在一塊兒，在此以前沒法單獨展現。把項目作成可展現的形式須要花費大量的時間，尤爲是編寫用戶交互界面更是一件費時費力的事情。而項目展現要求的是美觀和易用，這就給項目的可見性帶來了更多的壓力，由於許多開發人員都不肯意去寫界面，更不肯意去給一個單獨的模塊寫GUI，有這時間的話他們寧肯去完善功能。可是項目的展現又是很是重要的，項目的投資者每每會很看重開發過程當中的展現。在實際的工程開發中，該如何作好項目的可見性？

2. 「軟件」和「軟件工程」這些詞彙是如何出現的？

• 化學家和統計學家約翰·圖基（John W. Tukey）在1958年撰寫一篇科學文章時，首次使用「軟件」這一術語。據報道，他早在1953年就已經提出這個詞，用來標記計算機程序（即「軟件）與使用這些程序的計算機（或「硬件」）之間的區別。
• 1968年NATO會議上首次提出「軟件工程」（Software Engineering）的概念，提出把軟件開發從「藝術」和「個體行爲」向「工程」和「羣體協同工做」轉化。其基本思想是應用計算機科學理論和技術以及工程管理原則和方法，按照預算和進度，實現滿用戶要求的軟件產品的定義、開發、發佈和維護的工程。今後也誕生了一門新的學科——軟件工程。

3. 軟件工程發展的過程當中，出現的有趣的冷知識和故事

歷史上出現的有關軟件工程有趣故事並很少，我只能在此寫一個前不久發生的事情，即」產品經理和程序員打架「事件。該事件於此連接中有詳細描述，下圖是事情通過的精華加工版。

這讓我想起一則笑話：

- 」爲何計算機領域沒有民科？「

- 」固然有，否則你覺得產品經理是哪兒來的。「

這隻玩笑，但產品經理是軟件工程中一個重要的崗位，產品經理提出的需求每每很大程度上影響了軟件產品的最終質量。所以，在軟件工程中，一個團隊裏產品經理和技術人員的溝通就顯得尤爲重要，這也是我在軟件工程課程中應該注意的事情。

4. 目前流行的源程序版本管理軟件和項目管理軟件及其優缺點

現有的版本控制軟件以下圖所示。

流行的版本控制軟件的用戶數以下圖所示。

Git、Mercurial、Trac和Bugzilla的優缺點以下表所示。

軟件名	優勢	缺點
Git	1. 適合分佈式開發，強調個體 2. 公共服務器壓力和數據量都不會太大 3. 速度快、靈活 4. 任意兩個開發者之間均可以很容易地解決衝突 5. 離線工做	1. 學習週期較長 2. 不符合常規思惟 3. 代碼歷史保密性差，一旦開發者把整個庫克隆到本地，就能夠徹底查看到全部的歷史版本信息
Mercurial	1. 更簡潔好用的命令行指令 2. 上手簡單 3. 完善的GUI支持 4. 易於擴展	1.Mercurial的分支模型十分複雜，每一種分支方法都有不少缺點和不便之處 2. Mercurial改寫歷史很麻煩 3. 沒有命名空間
Trac	1. 很是靈活，能夠爲所欲爲地定製 2. 能夠和SVN集成 3. Trac的權限體系是比較完備的設計	1. 不支持多項目 2. 中文化不完整 3. 核心功能不多，不安裝插件基本沒法使用
Bugzilla	1. 檢索功能強大 2. 強大的後端數據庫支持 3. 根富多樣的配置設定	1. 安裝須要Perl和配置MySQL數據庫，過程比較繁瑣2. 修改配置文件很麻煩3. 流程沒法定製