軟件工程第一次閱讀做業

項目	內容
這個做業屬於哪一個課程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ
這個做業的要求在哪裏	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/2625
我在這個課程的目標是	完成課程中所要求的任務，經過該課程
這個做業在哪一個具體方面幫助我實現目標	理解課程大綱，提出問題

提問

1 , 簡單地說，軟件的行爲和用戶的指望值不同，就叫Bug。例如，某聊天軟件啓動時就崩潰了，用戶指望這個聊天軟件不能崩潰。例如，某聊天軟件不支持視頻聊天，用戶指望這個聊天軟件支持視頻聊天。可是該軟件的開發人員說，這個軟件根本沒打算支持視頻聊天。這仍是一個Bug麼？是不是Bug，取決於用戶和開發者的不一樣角度，咱們看一個經典小說中的例子：

• 上述是書中對bug的定義，與本身本來的認知感受起了衝突，本來認爲bug應該屬於出錯，應該屬於客觀的內容，不禁用戶所決定，而書中對bug的描述，更加看重用戶以及使用者的見解，更具主觀性，查看了相關的定義後，程序錯誤（英語：Bug），是程序設計中的術語，是指在軟件運行中由於程序自己有錯誤而形成的功能不正常、死機、數據丟失、非正常中斷等現象。 網上的內容與本身的認知基本一致，想提問文中所說的bug是不是更加廣義的定義，或者說，從軟件工程的角度，是否bug的定義更加普遍。

2，書中將大四學生與軟件工程師進行了相應的對比，以此來講明我的開發流程PSP的特色 ，同時引出優秀軟件工程師的PSP流程的思考

• 就像書中以前所論述的，軟件行業比較複雜，不一樣的項目需求不一樣，要求也千差萬別，PSP表格的各個花費時間佔比所能最大表現出該軟件工程師哪方面的能力？或者說PSP最大的指導意義是什麼？我的理解，學生與職業比較，職業寫的代碼多，熟練，弄清楚需求以後，編碼所用時間天然就降低了。PSP表格的意義是否是不大。

3, 關於代碼行數的問題，書中提出了當代碼是在2,000行如下，程序員能夠用「寫了再改」的蠻幹方法，而且靠記憶力搞定一個程序，可是，若是你的代碼規模達到20,000行，你要用結構化編程（類，模塊，API，細節隱藏，面向對象的其餘方法，等）來保證程序不變成一團亂麻。若是代碼規模再大一個數量級，20萬，200萬呢？

• 自己沒有寫過不少行的代碼，2000行層次都沒達到，但仍是想問200萬的，這方面經驗不多，相比於普通的代碼，大工程網上資料也比較少，因此想提問關於大工程的問題，像200萬代碼規模的項目這樣，感受這樣的工程確定得靠多人合做來完成，在200萬行這種軟件的狀況下，通常是如何配合團隊進行相關開發的。

4, 代碼複審的問題，代碼複審在書中指出主要用於考慮維護等方面的內容，更多注重於代碼的質量問題

• 關於代碼質量的問題，是不是在過程當中，或者在寫以前給出相應的設計指導是否是會更加好一點。這樣形成的設計等問題在剛開始能夠容易地進行修改，代碼審查看書裏好像是安排在測試以後，這時候若是發現不合理地地方，改動起來不是很麻煩嘛

5,結對編程， 書中指出告終對編程的有不少種不適用的場景，可是結對編程也有不少獨特的好處，解決了代碼審查的不少缺點。同時最後書裏也花很大篇幅指出了須要進行有效的溝通，同時要注意溝通方式。

• 我理解結對編程的關鍵點仍是在於溝通，但溝通其實也是門很大的學問。並且溝經過程中也會出現相應的矛盾，並非全部矛盾都能獲得很好的解決方式，特別是對於模棱兩可的問題的時候。這個時候花在溝通方面的精力是否偏離告終對編程爲了提升代碼質量與效率的初衷，或者說投入產出比是否真的客觀。我的感受，相比於外國，咱們表達和處理問題更加含蓄，是否適合結對編程這種方式。

詞彙歷史

• 據查閱，軟件是1935年圖靈所提出的概念，在一篇論文中提出。
• 而軟件工程則是1968年提出，是Margaret Hamilton在阿波羅計劃期間發明創造出來的。

計算機發展過程當中的冷知識

• 目前已知的編程語言共有700多種

版本管理與項目管理軟件

使用趨勢：

• Git：
  • 優勢：使用認識廣，使用方便，學習容易
  • 缺點：有些操做比較複雜
• bitbucket：
  • 優勢：擁有免費私有庫，支持git
  • 缺點：項目很少
• Mercurial：
  • 優勢：配置方便
  • 缺點：不易於管理
• Trac：
  • 優勢：配置靈活
  • 缺點：沒法顯示中文文件