軟件工程第一次閱讀！

項目	內容
本次做業所屬課程	北航軟件工程
所屬做業	第0次做業
課程目標	儘可能作吧QAQ
做業回報	熟悉構建之法和一些奇怪的冷知識

1.快速看完整部教材，列出你仍然不懂的5到10個問題。

問題1.用戶滿意度的定義是否欠缺考慮？

1.2.4 用戶滿意度：用戶在使用時發現了軟件的不少問題，影響了用戶使用軟件的效率。

我認爲這裏的用戶滿意度不只僅和軟件是否實現用戶需求、是否高效率運做有關，還和軟件是否實現更高層面的需求有關。用戶的需求不是固定不變的，一個軟件不只僅要面對用戶的基本需求，還須要注意用戶的發展性需求，甚至能夠主動創造需求去教育用戶「這纔是大家想要的」。而書中對滿意度的描述還侷限在基本需求這塊。

問題2.靈感和激情在團隊工做中重不重要？

3.1 團隊對我的的指望： 理性地工做：軟件開發有不少我的的、感情驅動的因素，可是一個成熟的團隊成員必須從事實和數據出發，按照流程，理性地工做。

在軟件開發領域也是有不少創造性開發項目的，好比一種業內從未出現過的功能開發，一種全新的遊戲開發，我認爲事實和數據只能做爲軟件開發出發點的一部分。一方面軟件開發不是一個死板的過程，工程自身也須要成員靈感的碰撞；另外一方面團隊成員做爲人類個體，靈感和激情不只僅能夠保證工做效率，還能夠創造出問題一中「發展性需求」的實現。並且不少空白或者接近空白的領域中，事實和數據都是極其有限的，只有具備靈感和感性目標的團隊才能更有可能到達目標。

問題3：命名規則是否是有待商榷？

4.2.6 避免過多的描述。例如遊戲開發中最後出現的「大boss」，不用寫「theFinalBattleMostDangerousBossMaster」，能夠直接寫boss。

一方面即便namespace在大部分語言中都有運用，可是在項目裏面看到「boss」這樣過簡的描述也容易歧義，另外一方面對於一些無namespace概念的語言來講確切的命名更是必須的。

問題4.goto真的適合在軟件工程中使用嗎？

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

goto對程序可讀性的破壞是一個方面，另外一方面咱們也須要考慮到大部分程序員對goto是很陌生的，甚至大部分人從業至終也沒有寫過一條goto語句，用goto語句行爲自身就不存在「規範」可言。

問題5.結對編程的相互督促是否合理？

4.5.3 結對編程的過程也是一個相互的過程，每一個人的一舉一動都在別人的視線以內，全部的想法都要受到對方的評價？

我認爲結對編程的督促應該是每過一段時間同步交流一次，以時間刻度來看好比過幾分鐘交流一次或者觀察一次，事無鉅細地觀察和交流很容易讓雙方拋出不成熟的見解給對方，這既不利於軟件開發地效率，由於雙方會空耗時間在大量的突發性想法上，也不利於團隊雙方的磨合，對於對方的開發風格和實力會產生紊亂和質疑。

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

根據維基百科的介紹Richard R. Carhart最早將工程的概念引入軟件領域

The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.

--引用自維基百科

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

關於谷歌軟件大牛Jeff Dean的冷"知識"

1.The rate at which Jeff Dean produces code jumped by a factor of 40 in late 2000 when he upgraded his keyboard to USB 2.0.
在2000年後段，Jeff碼代碼的速度忽然激增了40倍，緣由是他把本身的鍵盤升級到了USB 2.0

2.gcc -O4 emails your code to Jeff Dean for a rewrite.
gcc的-O4優化選項是將你的代碼郵件給Jeff重寫一下

3.Unsatisfied with constant time, Jeff Dean created the world’s first O(1/n)algorithm.
Jeff對常量的時間複雜度並不知足，因而他創造了世界上第一個O(1/n)的算法。

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

如下圖片資料均來源於維基百科

主流的源程序版本管理軟件和項目管理軟件包括：

使用人數分佈狀況：

VCS	優勢	缺點
Git	適合分佈式開發，強調個體。公共服務器壓力和數據量都不會太大。速度快、靈活。任意兩個開發者之間能夠很容易的解決衝突。離線工做。	模式上比SVN更加複雜。代碼保密性差，開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。
SVN	對目錄的組織的管理更加方便。保證提交操做的完整性。SVN容許一個文件有任意多的可命名屬性，功能十分徹底。	不能離線工做。不能恢復到歷史版本。提交、更新、瀏覽歷史的速度慢。
Microsoft TFS	任務版上能將需求、項目進度盡收眼底。能有效實現 SCRUM，能與 VS 無縫接合。	搭建、維護tfs比較複雜，硬件要求也比較高。整個系統是用 asp 實現的，用瀏覽器訪問較慢。
Mercurial	能夠一鍵徹底恢復到歷史版本的某一個切面。hg的版本庫不須要維護。封裝好。相比git，hg不多暴露一些實現內的細節。	分支管理不靈活。Mercurial的branch管理和Git相比不是很方便。