軟件工程第一次閱讀做業

1、閱讀完《構建之法》後的問題

一、第二章中提到單元門測試應該由做者負責。可某些狀況下，功能的開發者自己就忽視了一些問題，所謂盲區。在他編寫的單元測試中，即便代碼覆蓋率達到100%，也是很難發現這些問題的。

代碼的做者最瞭解代碼的目的、特色和實現的侷限性。因此，寫單元測試沒有比做者更合適的人選了

​ 我部分贊成做者的觀點，但如問題中所說，對我的可否構造出發現本身錯誤的測試用例表示懷疑。

二、在軟件工程師的成長中，經過項目的鍛鍊能夠作到對成熟的領域熟悉乃至精通，可是如何作到對於全新的功能或項目作到有思路，有大概路線？

​ 該問題來自第三章中軟件工程師的職業發展部分。讀完以後，我認爲要成爲一個高級的軟件工程師，須要的不只僅是工做經驗或技術，對於項目的總體把握和感知也是十分重要的。

三、在結對編程中，領航員的工做定位實際上有些模糊，如何避免領航員比較閒或者沒法給出良好建議？

駕駛員：寫設計文檔，進行編碼和單元測試等XP開發流程

領航員：審閱駕駛員文檔，監督駕駛員對編碼等開發流程的執行........

​ 我認爲，在結對編程中，仍是駕駛員起主要做用，領航員僅僅是輔助的做用，發現代碼或者設計中的問題。假使兩我的水平不一，好比領航員水平較高，還有可能提出大量的問題，反而耽誤開發效率。

四、相較於瀑布模型，迭代式開發對可拓展性要求更高。如何保證迭代式開發可以在最初的版本就完成一個可拓展性較高的版本？

MVP-Minimum Viable Product,最小可行產品，具體作法是：把產品最核心的功能用最小的成本實現出來，而後快速徵求用戶意見。

​ 我本身的編程經驗不足，對於如何在保持高可迭代性的基礎上開發一個demo版本並非很清楚，我認爲這也是迭代式開發的一個難點。

五、敏捷編程聚焦於最重要的任務，缺乏細緻的規劃，是否會致使在後續的版本出現bug後難以回溯修復？

​ 根據書中所介紹的敏捷編程的內容，敏捷編程須要一個高效的團隊在Scrum Master的帶領下完成最重要的任務。可是以用戶當前最重要的需求爲導向來推動項目，是否會致使項目的修補比較多？缺乏完整的項目文檔的狀況下不斷迭代是否會致使bug難以被回溯？

六、用戶的需求在實際狀況下並不穩定，甚至常常中途更改需求，如何挖掘客戶可能會產生的潛在需求並準備一些預案？

​ 閱讀了第八章需求分析以後，想到以前實習時接觸到的一個項目。客戶對於前端的要求一改再改並不斷提出新的需求，因爲以前沒有考慮到一些需求，後續功能添加變得十分繁瑣，不少代碼不得不推倒重來，深感挖掘客戶潛在需求十分重要。

2、「軟件」和「軟件工程」這些詞彙是如何出現的-什麼時候-何地-何人？

「軟件」一詞最先由John Turkey與1958年在Princeton於「The Teaching of Concrete Mathematics」這篇文章中提出

「軟件工程」一詞由Margaret Hamilton在NASA爲阿波羅登月項目工做時提出。

3、上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麼優缺點？

版本管理軟件名稱	用戶數目（估計）	優勢	缺點
Git	31,100,000	適合分佈式開發，強調個體，服務器壓力較小，快速靈活，容易解決衝突，離線工做	模式上比SVN更復雜，不符合常規思惟，代碼保密性差
Mercurial	未查證	系統簡潔，拓展性強，分支模型優秀	跨平臺兼容性差
Trac	未查證	擴充性好，權限體系完備，靈活，能夠和TortoiseSVN集成	不支持多項目，功能太少
Bugzilla	未查證	不收費，有中文版支持	只能管理缺陷

4、軟件工程冷知識與趣事

​ 第一個電腦遊戲出現於1962年，由麻省理工學院的計算機程序員Steve Russell與其團隊一同編寫，這款名爲《太空大戰》的遊戲耗費了他們近200個小時。該遊戲容許兩名玩家分別控制兩艘飛船，目標是擊中並摧毀對方飛船，而且玩家還須要躲避屏幕中表明星球的小白點。而這款遊戲並未給他們帶來任何收益。（連接：https://blog.csdn.net/l_mloveforever/article/details/83860547）