| 項目 | 内容 |
|---|---|
| 本作業屬于北航軟體工程課程 | 部落格園班級連結 |
| 作業要求請點選連結檢視 | 作業要求 |
| 我在這門課程的目标是 | 成為一個具有一定經驗的軟體開發人員 |
| 這個作業在哪個具體方面幫助我實作目标 | 讓我對自己目前的狀況有一個更加清醒的認識 |
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能否為這些使用者提供友善呢？
軟體開發、尤其是面向大量使用者的軟體開發，一個很困難的問題就是如何定義“友善”以及“好用”這種很主觀的概念。以最近微信釋出的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. 流程無法定制 |