軟件工程第1次閱讀做業

軟件工程第1次閱讀做業

---

項目	內容
這個做業屬於哪一個課程	2019春季計算機學院軟件工程(羅傑)（北京航空航天大學）
這個做業的要求在哪裏	第一次閱讀！
我在這個課程的目標是	學習軟件工程方法與相關工具，提高本身的工程能力，鍛鍊本身與他人協同開發以及開發較大項目的能力
這個做業在哪一個具體方面幫助我實現目標	經過快速閱讀書本瞭解了軟工的概念與經常使用的方法論

《構建之法》中的問題

1. 第3章 軟件工程師的成長 P49

過早擴大化/泛化…… 有些軟件原本是解決一個特定環境下的具體問題，有的程序員一想，咱們能不能作一個平臺，處理全部相似的問題，這樣多好啊！這樣的前景的確很美妙，程序員的確須要這樣的凌雲壯志，可是要了解必要性、難度和時機。

我在閱讀了以上部分後，認爲的確從一開始就考慮泛化地編寫程序的確難度較大，我不理解的部分是泛化的「必要性、難度和時機」具體應該如何肯定？特別是在時機方面，我認爲泛化的出現主要源於需求的增長，每每須要對原有的方法進行抽象，那麼是當需求來臨時才進行抽象仍是在需求到來前某個「合適的時機」就天然向泛化的方向進發呢？

2. 第4章 結對編程 P69

4.3.2 goto ……只要有助於程序邏輯的清晰體現，什麼方法均可以使用，包括goto

以往學習的過程當中老師都極力阻止咱們使用goto，雖然我在知乎上查找了一番關於goto的問題後（知乎問題）我認爲goto僅適合用於跳出多重循環，但正如某些答主所說多重循環有可能在設計上自己有改進的方案。所以我仍然對這裏說可使用goto持有懷疑的態度。

3. 第4章 結對編程 P81

結對編程中駕駛員和領航員的角色要常常互換，避免長時間緊張工做而致使觀察力和判斷力降低。

首先這一部分的內容的確與我想象的結對編程有所不一樣，在閱讀這部分以前我認爲結對編程就是在兩我的肯定編程的規範和計劃後並行地進行工做，每隔一段時間後進行復核，相似於「兩個駕駛員」的感受。而書中介紹的結對編程其實是一我的編碼另外一我的進行指導。個人問題是，如何解決結對時兩人水平差距較大的問題？例如當我和某個大佬結對編程，大佬很快就能完成他的工做，而當輪到我時雖然有大佬指導，也極可能出現速度減慢質量變差的狀況，可能出現大佬看我寫代碼甚至比他本身寫還要累的狀況。當兩人差距過大時應當如何工做以縮小差距帶來的影響？
本段話中駕駛員和領航員的比喻讓我想起了前一陣的電影《飛馳人生》，我認爲劇中的兩個主人公實際上有點相似於我所說的水平差距較大的狀況（在單純的駕駛水平上）。大部分領航員可能對路況很是熟悉，但從駕駛車輛自己上講領航員的駕駛水平可能比車手要差不少。所以此處對於領航員和駕駛員的比喻是否也有些不妥？

4. 第6章 敏捷流程 P11六、117

若是你的團隊很弱，那麼強行把敏捷（或者其餘高級方法）套在上面也沒有用，也許還會拔苗助長。

雖然我相信班上必定有一些大佬接觸過較大的項目，但大部分同窗應該都是處於初步接觸多人開發的階段。在組隊時從平均水平來講大機率會成爲一個相對來講較弱的團隊。這一點在我閱讀第5章中關於主治醫師模式時也有思考。

在一些學校的軟工課上，這一模式每每退化爲「一個學生幹活，其他學生跟着打醬油」

這種狀況的出現我認爲是由於同窗們的水平和對待課程的態度有所差別。個人問題是，對於咱們剛學習軟工的同窗們而言，在面對敏捷開發方法方面如何起步，有哪些好的實踐能夠均衡這種模式致使的問題？

5. 第12章 用戶體驗 P260

犧牲質量去追求用戶體驗麼，用戶能接受麼？（GE公司的例子）

我在讀完這一部分後感受這裏的例子僅僅是說明有些時候犧牲質量追求用戶體驗是值得的。個人問題是如何權衡產品質量和用戶體驗的關係呢？有沒有某些質量要求大於用戶體驗的狀況？

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

"software"一詞源於美國統計學家John W.Tukey，他在1958年1月9日的「具體數學教學」-美國數學月刊中發表了這一術語。須要注意的是Tukey將當時的"computer"稱爲「計算器」。彼時，"computer"這個詞一般指的是人，而且"computer"這個詞在機器上的使用剛剛開始流行使用。

"software engineering"的說法由Anthony Oettinger創造，在1968年被用做世界上第一個軟件工程會議的標題，由NATO （北約） 贊助和推進。

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

首先咱們應當明確版本控制軟件和源代碼託管服務的區別。前者指的是Git、Mercurial這類版本控制軟件自己，然後者則指的是GitHub這樣的服務。GitHub提供的服務基於Git，而咱們也能夠本身搭建Git服務器。

熱門程度

對於版本控制軟件而言，我使用Google Trends查找了五個較爲熱門的版本控制軟件，分別是Git、CVS、SVN、Mercurial和Microsoft TFS。

（協做版本系統指CVS）
圖中能夠看出Git是當今最爲熱門的版本控制軟件。CVS是最先熱門的版本控制軟件，但在2008年後此軟件就再也沒有更新過。SVN以後熱門過一段時間但隨着Git的興起而逐步沒落。同時我還查找了Trac、Bugzilla等相對小衆的軟件，但他們相比於以上五個來講搜索量小的可憐。

對於源代碼託管服務，我從Wikipedia中找到了Comparison of source-code-hosting facilities，按使用人數排序以下

名稱	用戶數	項目數
GitHub	31,000,000	100,000,000
Bitbucket	5,000,000	Unknown
Launchpad	3,965,288	40,881
SourceForge	3,700,000	500,000
GitLab	100,000	546,000
GNU Savannah	93,346	3,848
OSDN	54,826	6,294
Ourproject.org	6,353	1,846

優缺點

• Git
  • 優勢
    • 速度很快
    • 建立repo很是簡單
    • 方便與GitHub對接（GitHub是最熱門的源代碼託管服務）
  • 缺點
    • 在Windows上體驗不佳
    • 不能切換分支的一部分（不能checkout單個文件）
• Mercurial
  • 優勢
    • 相對簡單的學習曲線
    • 良好的Windows支持
    • 更加安全
  • 缺點
    • 功能不如Git強大
    • 擴展性差，插件只能用Python寫，而且使用插件時容易帶來問題
    • 回溯功能較弱
• Trac
  • 優勢
    • 優秀的項目管理機制
    • 輕量靈活，能夠與多種VCS集成
  • 缺點
    • 功能較弱，使用量較小
• Bugzilla
  • 優勢
    • 最爲知名的Bug跟蹤系統
    • 使用簡單，對沒有相關係統瞭解的人也很友好
  • 缺點
    • 僅僅在Bug管理方面較強，而其餘功能上較弱

（SVN和CVS相對古老，在此再也不贅述）
Git pros and cons
Mercurial pros and cons
Mercurial for Git users
Trac - Wikipedia
Bugzilla