軟件工程第一次閱讀做業

項目	內容
做業所屬課程	BUAA_SE_2019_LJ
做業要求	第一次閱讀！

1. 看完教材《構建之法》，列出仍然不懂的問題。

1. 如何在團隊中創建相互信任的關係？

   MSF提倡自下而上的計劃，每一個人有充分的權力估計並決定本身的任務須要多長時間。

     這句話來自書中7.2.3節。「充分受權給團隊和成員」意味着團隊成員之間是相互信任的，只有在信任的基礎上才能給團隊成員充分的受權。不過即便沒有信任，也是能夠對這個原則生搬硬套的，可是這就將信任流於形式了。首先，信任是雙向的，第二，團隊成員應該是值得被信任的。在一個新組建的團隊中，團隊成員尚且不能相互認識，如何快速地創建起真正的信任呢？

2. 在軟件開發中，如何應用建模方法？

     這個問題來自11.2節的「圖形建模和分析方法」。這一節介紹了多種圖形建模的方法，我也在以前的課程中使用過ERD、DFD、UML，但結果是，就是書中所說的，有了模型，殊不知道下一步該作什麼，或者，模型與後續的工做脫節，模型沒有可以給以後的實現予以足夠的指導。最後，畫圖的目的就是爲了畫圖。出現這個問題，我以爲可能有這樣的緣由，模型與最終實現抽象層次不一樣，對於那些實現中的複雜細節，不知道應該如何體如今模型中，在模型中應該體現多少，或者說，在設計模型的時候，應該體現哪個層次。那麼，如何才能將建模方法融入軟件的設計和實現中，避免爲了建模而建模呢？

3. 如何進行量化的績效管理？

     17.6節介紹了衡量我的在團隊中的績效的方法，例如根據工做量，bug數量，隊友評估等等。每一種方法都有必定的合理之處，但又存在着明顯的不足。

   純粹強調外接的驅動因素（金錢的報酬或懲罰）僅僅對體力勞動或有明確規則的活動有效（獎金約定，結果越好），但對於須要創造性思惟的活動，即便是簡單的認知能力的活動，更多獎金反而起到相反的效果。

     若是認爲軟件工程師的工做是「須要創造性思惟的活動」，按照書中的觀點，咱們在進行績效管理的時候就須要注意內部的驅動因素。如今的問題是，課程評分中有一項團隊貢獻分，須要在團隊成員中分配，咱們不得不面對如何量化我的績效的問題。那麼是否存在一種量化績效的方法，能給出每一個人貢獻的比例呢？

     下面給出個人愚見。既然內部驅動因素影響着團隊成員的工做效率，不妨從內部驅動因素入手。關注「自主性」，書中解釋說「由本身決定工做的部份內容」，我認爲在績效評比的時候也發揮自主性，每一個人主張本身的貢獻比例，給出本身作了什麼，對團隊的貢獻在哪裏，有多大，分析爲何是這個比例。而後團隊成員在一塊兒討論，每一個成員分別對其他每一個人的主張發表意見，最終討論得出一致結論，肯定每一個人貢獻的比例。若是這種方式可以施行的話，應該比計算代碼行數或bug數會好不少。

4. 爲何每日構建很重要？

   咱們的軟件構建，就和腳手架同樣，天天都要立着，倒下了就麻煩了。

     這句話來自11.5.2每日構建一節。這個比喻很形象，也符合直觀，不過我還未能給出具體的論據來支持這個觀點。

5. 若是錯誤的狀況不少，怎麼進行錯誤處理？

     書中4.3.3節錯誤處理說到，「若是你認爲某事可能會發生，這時就要寫代碼來處理可能發生的錯誤狀況」，若是錯誤的狀況不少，要照顧每一種可能的錯誤，就須要編寫冗長的代碼來進行錯誤處理，這一過程就比較機械和繁瑣。好比編譯器在進行錯誤處理時，錯誤的狀況無窮無盡，即便要分出每一種錯誤的類別都是很花時間而且容易遺漏的。這種狀況下，我常常懷疑，是否有必要處理每一種可能的錯誤，有沒有一種好的方法可以幫助分析各類可能的錯誤狀況而無遺漏？

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

• 「軟件」是由John Tukey於1958年在其論文"The Teaching of Concrete Mathematics"中提出來的。
• 「軟件工程」一詞是由Margaret Hamilton創造的。在1968年北約科學委員會召開的會議上正式使用。

3. 【附加題】：你們知道了軟件和軟件工程的起源，請問軟件工程發展的過程當中有什麼你以爲有趣的冷知識和故事？

"It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter."

- Nathaniel Borenstein

Explanation

查看解釋

  Borenstein說，沒有哪一個通過職業道德培訓的程序員會寫出DestroyBagdad過程，基本的職業道德告訴他們，應該寫一個DestroyCity過程，而將Bagdad做爲一個參數。
  這段話的幽默之處在於，讀者會認爲程序員的受到的道德(ethics)教育與其餘人相同，好比「不要殺人」，「作一個好人」之類的，然而，Borenstein說的是程序員的職業道德，具體地說，就是編碼時的一系列規範(coding ethics)，用於在軟件工程中寫出高質量的代碼。
  這段話有必定的誤導性，但又不徹底是，這就是其幽默所在。要理解這段話，須要琢磨ethics一詞的含義，翻譯成中文後，因爲找不到合適的詞，反倒喪失了幾分幽默。

4. 上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麼優缺點？ （提示：搜索一下Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode）?

1. Microsoft TFS: 測試管理和軟件生命週期管理工具

   優勢：

   • 與Visual Studio等微軟產品集成得很好，易於使用
   • 容易訪問，能夠從客戶端、瀏覽器和Visual Studio訪問
   • 源代碼管理方面：方便的簽入/簽出
   • 項目管理方面：易於管理bug

   缺點：

   • 網頁的用戶界面和用戶體驗比較糟糕

2. GitHub: 提供代碼管理，軟件協做開發的平臺，用戶數31,000,000

   優勢：

   • 漂亮的UI
   • 能夠與不少開發工具集成
   • 使用Git便於代碼管理
   • 方便代碼複審等多人協做

3. Git

   優勢：功能強大，很好地處理分支，適合大型項目使用

   缺點：難於理解，對初學者不友好

4. Mercurial

   優勢：比Git易於使用

   缺點：比Git功能弱，沒有部分簽出功能，不適合大型項目

5. BitBucket：用戶數5,000,000

   優勢：

   • 倉庫和項目的管理簡單易使用
   • 有方便的可視化工具顯示分支
   • 與Atlassian產品集成得很好

   缺點：

   • 相比GitHub，缺乏第三方工具的集成
   • 搜索方式不如GitHub豐富

6. BugZilla

   優勢：缺陷報告能夠處處，支持多項目的缺陷跟蹤。

   缺點：不支持自定義界面