【軟件工程】第一次閱讀做業

項目	內容
這個做業屬於哪一個課程	軟件工程（羅傑）
這個做業的要求在哪裏	第一次閱讀做業
本次做業要完成的目標	閱讀《構建之法》，快速瞭解軟件工程的相關知識和過程並提出疑問

讀完《構建之法》產生的疑問

1.第一章第7頁

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

1. 根本不考慮
2. 若是沒時間實現這個功能，就算了
3. 作了，可是不用告訴用戶
4. 作了，並且不厭其煩的告訴用戶如何使用

我看了上述這段文字，有這個問題：書上針對這個例子給出的答案傾向是4，但我認爲這個地方這麼說是不太穩當的，而且邏輯不夠嚴謹的。

這是個關於需求的問題，因而我翻到了書的第八章——需求分析。在第八章我看到了需求分析的定位和優先級的描述（書本第163頁），裏面提到了功能的四個象限（殺手功能、外圍功能、必要需求、輔助需求），也就是說在軟件工程的需求分析過程當中咱們須要根據項目自己的特色和狀況將需求進行劃分，本例子若是從安全性上考量那麼這個百萬分之一使用率的需求必然是要作的（固然也並不必定是那麼必然，還要考慮到該產業中其餘公司所作到的程度或是其餘因素）但是若是這個百萬分之一的需求不是像安全性這樣的需求呢？又會如何選擇呢？。

針對這個問題，我認爲這裏至少應該給出兩個答案，一個是書本上那個，另外一個是相反的狀況的，也就是這個需求並非像安全性這麼重要的需求，讓同窗們也能從商業性上進行考量，從而讓同窗們知道需求的肯定並非單一的，而是須要綜合來看的，而且我以爲這樣可以啓發同窗們更加全面的思考問題。

以上是個人問題和觀點，歡迎討論。

2.敏捷開發流程的疑問（P121）

書上P121頁的表格列出了敏捷開發方法的使用範圍，其中的客觀因素中有這兩點：

1. 人員經驗：有資深程序員帶隊；
2. 需求變化：常常變化；

結合本課程的學習內容和對書本的思考，我有如下疑問：

• 敏捷開發方法須要有資深程序員帶隊，但是咱們團隊中大多都是小白（初級中的初級程序員），將如何更真實的體會到敏捷之道呢？其次咱們在課程後期的團隊項目中要如何保證需求的不斷變化呢？若是這兩點不能很好的知足是否可以達到本課程學習的目標呢？

3.TDD（測試驅動開發）

在看敏捷開發流程的時候，注意到了書上提到的一種敏捷開發的工程實踐方法——TDD（測試驅動開發），這裏想問一下：測試驅動開發將設計放在了什麼位置（或是地位）？TDD在實踐的時候先編寫測試用例是嚴格遵照的嗎？TDD實踐過程當中是小步前進，這個小步的大小該如何肯定？

有人認爲在實踐中也能夠先實現功能代碼，而後再補寫測試用例，可是必須在實現完成後立刻補寫測試（深度解讀 - TDD）。我認爲既然TDD的中心思想是測試驅動，那是否就應該嚴格保證測試用例的先行呢。

因爲實踐太少，並不能很好的把握理解這些方法。

4.風險管理（第九章）

「沒有風險，就是最大的風險」

第九章結尾的這句話，我對於本身的理解不太肯定，下面是個人理解：

在項目中可能會遇到各類各樣的風險，不少狀況下PM都是在儘量的減小這些風險的存在，可是這些風險有時候也表明了一些機遇。這裏的「沒有風險」其實並非真正的不存在風險，我認爲有兩層意思：

1. 項目人員沒有風險意識，因此纔會說沒有風險，這種沒有意識到風險的風險纔是一個項目中最大的風險。
2. 對於已知的風險，咱們是能夠去應對的，可是對於未知的風險（也就是沒有風險的狀態），咱們是沒法作準備的，因此這纔是最大的風險。

5.結對編程（第四章）

看完書上對結對編程的介紹，我發現其實在以前的編程實踐中本身有踐行過這種方案的，如今也是十分認同這種方式。書上給的結對編程的方式是領航員和駕駛員模型，在網上查看的結對編程和書上的觀點也基本一致，這裏我想問的是：

1. 結對編程必定要兩我的保持這樣的方式工做，直到項目完成嗎？是否能夠在大多數關鍵代碼上實行這種方式，而在簡單的部分採用分開編碼，從而提升編碼效率，這裏分開編碼只是意味着不一樣的電腦，還要會保證及時的面對面交流的。

請問「軟件」和「軟件工程」這些詞彙的起源

• 「軟件」一詞最先在工程背景下是由Richard R.Carhart在蘭德公司研究備忘錄中於1953年8月出版的。
• 「軟件工程」一詞第一次出如今1965年6月出版的計算機和自動化公司提供的服務清單中。瑪格麗特·漢密爾頓（Margaret Hamilton）提出了將該學科命名爲「軟件工程」的想法，以此做爲賦予其合法性的一種方式。

軟件工程發展過程當中的冷知識

• 埃達·洛夫萊斯原姓拜倫（Byron），是一位英國數學家兼做家，表明做是她爲查爾斯·巴貝奇的分析機——機械式通用計算機——所寫的做品。她是第一位主張計算機不僅能夠用來算數的人，也發表了第一段分析機用的算法。所以，埃達被公認爲史上第一位認識計算機徹底潛能的人，也是史上第一位計算機程序員.

目前流行的源程序版本管理軟件和項目管理軟件

幾大流行版本管理項目的使用人數排名

• 1.GitHub: 大約31,000,000名用戶
• 2.Launchpad: 大約3,965,288名用戶
• 3.Bitbucket: 大約5,000,000名用戶
• 4.SourceForge: 大約3,700,000名用戶
• 5.GitLab: 大約100,000名用戶

各項目管理軟件的優缺點

• GitHub

  優勢

  1. 能夠做爲版本控制系統和協做工具，用它來發布工做。
  2. 利用GitHub，能夠將項目存檔，與他人分享交流，支持多人共同完成一個項目。
  3. 建立本身的項目，並備份，代碼不須要保存在本地或者服務器。
  4. 能夠跟蹤錯誤，Bugs能夠公開，能夠經過GitHub評論，提交錯誤。
  5. 分支能力特別強大，體驗特別好。加上支持離線提交，分佈式推送拉取，使得代碼層面的協做至關流暢。

  缺點

  1. 適合代碼追蹤，卻不是最好的設計跟蹤工具。
  2. 須要較大的學習成本，不斷實踐。

• Microsoft TFS

  優勢

  1. 共享代碼，跟蹤工做，針對專業團隊的開發人員工具的集成服務器套件。
  2. 與現有IDE或編輯器集成，是跨功能團隊能夠在全部大小的軟件項目上高效工做。
  3. 版本控制，使用無限制專用存儲庫對代碼進行存儲並協做編寫代碼，管理權限和策略以保護你的存儲庫。
  4. 經過積壓工做 (backlog) 和可自定義的看板捕獲和跟蹤工做狀況，並肯定工做優先級。 經過直接連接到代碼和生成的工做項目，確保透明性和可跟蹤性。
  5. 經過持續集成 (CI) 版本在早期發現質量問題。 使用發佈管理自動化跟蹤你的全部部署。 使用咱們普遍的測試工具組來維護較高的質量。 經過重複使用代碼和模塊更快地交付程序包管理。

  缺點

  1. 搭建、維護TFS比較複雜，硬件要求也比較高。

• Trac

  優勢

  1. Trac作一個SCM配置管理平臺，意味着它有良好的擴充性。
  2. Trac的權限體系是比較完備的設計。
  3. 很是靈活，能夠爲所欲爲的定製，能夠和TortoiseSVN集成。

  缺點

  1. 不支持多項目， 需求和缺陷沒有分離。
  2. 核心功能不多，不安裝插件基本上無法用。

• Bugzilla

  優勢

  1. 優化的數據庫結構可提升性能和可擴展性。
  2. 出色的安全性以保護機密性。
  3. 高級查詢工具，能夠記住您的搜索。
  4. 可編輯的用戶檔案和全面的電子郵件偏好。

  缺點

  1. 安裝過程比較繁瑣，修改配置文件比較麻煩。
  2. 中文支持還不夠好。

參考資料

[1]https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities

[2]http://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29

[3]http://en.wikipedia.org/wiki/John_Tukey