軟體工程第一次閱讀作業

專案

內容本作業屬於北航軟體工程課程

班級鏈結

作業要求鏈結檢視

作業要求

我在這門課程的目標是

成為乙個具有一定經驗的軟體開發人員

這個作業在哪個具體方面幫助我實現目標

讓我對自己目前的狀況有乙個更加清醒的認識

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

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

型別繼承

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

2）用const標註唯讀的引數

3）用const標註不改變資料的引數

我的疑惑點主要是在第1條原則。在上上學期的物件導向課程中，我們學到了類的繼承是乙個很實用的方法，它可以幫助我們減少**之間的重複，並且體現出設計的層次感。但《構建之法》的意思似乎是在說，要盡量避免使用型別繼承。在實際的工程中，型別繼承是被提倡使用的嗎？

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

結對程式設計中駕駛員和領航員的角色要經常互換，避免長時間緊張工作導致觀察力和判斷力下降。

前文中作者提到，結對程式設計可以模擬於現實中的一些搭檔關係：越野賽車（駕駛、領航員）、駕駛飛機（駕駛、副駕駛）。但是在這些領域中，搭檔的職務往往是固定的，這是因為兩個人往往在不同的崗位上有不同的經驗，讓在某乙個崗位具有更豐富經驗的人去擔任這一職務，比兩個人交換崗位、在自己不熟悉的領域工作，要合適的多。因此，結對程式設計中駕駛員和領航員經常角色互換，是否是乙個合理的選擇？

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

我同意第一印象很重要，但是當使用者已經是第n次使用你的產品時，你的ui能否為這些使用者提供方便呢？

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

乙個軟體有很多可能的輸入和環境引數，我們沒有能力窮舉所有的可能，也沒有必要。我們可以運用不同的設計測試用例的方法，有效地生成測試用例。

我在做軟體測試的時候，遇到的最困難的問題是如何處理有***的方法。這裡的「有***」代表該方法與外界有互動，比如從控制台讀入一行字串，又或者是連線乙個資料庫。如果我想對這些方法進行測試，就需要模擬出一整個環境，這在緊張的快速開發中是難以做到的。因此，在設計單元測試用例時，我往往會選擇跳過這些有***的方法，只測試那些純函式。但軟體的bug往往是在這些與系統有互動的地方產生的。所以我想知道，該如何為這些方法設計完備的測試用例，尤其是當方法的***很複雜、環境難以模擬的時候？

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

軟體開發過程中的可見性（ visibility）

我們看這個專案開發過程中的場景：

領導：進度如何？

答：可能快了。

問：能看看演示嗎？

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

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

上面的場景是我在專案開發中經常遇到的實際問題。很多時候，我編寫的軟體是偏後台的，甚至只是乙個命令列互動程式，不像web開發和gui開發那樣具有非常好的可見性。還有一些情況是，我的軟體是高度模組化的，只有當最後乙個模組完成的那一刻才能夠組合在一起，在此之前無法單獨展示。把專案做成可展示的形式需要花費大量的時間，尤其是編寫使用者互動介面更是一件費時費力的事情。而專案展示要求的是美觀和易用，這就給專案的可見性帶來了更多的壓力，因為許多開發人員都不願意去寫介面，更不願意去給乙個單獨的模組寫gui，有這時間的話他們寧可去完善功能。但是專案的展示又是非常重要的，專案的投資者往往會很看重開發過程中的展示。在實際的工程開發中，該如何做好專案的可見性？

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

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. 流程無法定製

軟體工程第一次閱讀作業

軟體工程第一次閱讀作業

軟體工程第一次閱讀作業

軟體工程第一次閱讀作業

相關推薦