軟件工程_第一次閱讀做業

項目	內容
此做業屬於北航軟件工程課程	班級博客連接
做業要求見右方連接	做業要求
我在這門課程的目標是	培養專業的軟件開發能力
這個做業在哪一個具體方面幫助我實現目標	反思本身的大學生活和學習，對本身有一個更加清晰的認識

1、快速閱讀完《構建之法》以後的一些小問題

一、書2.1章節——單元測試 中：

最好是在設計的時候就寫好單元測試，這樣單元測試就能體現API的語義，……

​ 提早寫好單元測試應該能夠算做提早作好規劃設計的一項具體要求，正如大二下OO課程中要提早寫好規格同樣；

​ 然而對於編程經驗並非特別豐富的大部分人來講，這個過程每每困難重重，由於實際的編碼和提早的設計會存在不小的差別；

​ 那麼，如何解決這樣的問題，是不是經驗不夠的緣由？或是設計的不合理？或是有什麼其餘的訣竅呢？

二、書3.2章節——軟件工程師的思惟誤區 中：

分析麻痹：一種極端狀況是想弄清楚全部細節、全部依賴關係以後再動手，心理上過於悲觀，……

不分主次，想解決全部依賴問題：……

過早優化：……

過早擴大化/泛化：……

這些思惟誤區是確實是咱們常常遇到的問題，有時候每每是陷入其中不知所措時才知道本身陷入了誤區，可是下一次可能仍是會「不禁自主」地陷進去……

書中這一章節具體地闡述了這樣地問題，可是並無說明應該如何避免或是當發生這樣地問題時怎樣解決；在實踐中，咱們應該如何在這些極端中尋找一個合適的平衡點？

三、書4.3章節——代碼設計規範 中：

關於函數，最重要的原則：只作一件事，而且要作好。

這是一種我一直在追求的編碼規範（雖然在稍大一點的項目中一直作得很差）…

常規的作法，就是按照本身的設計不斷地把大函數細化；

可是實踐中經常有一些函數代碼和功能不夠簡練，卻沒法再進行分離細化，遇到這種狀況應該怎麼作？

尋求其餘的函數設計？

或者能夠容許項目中少數函數出現這樣的狀況？

四、書4.4章節——代碼複審 中：

代碼複審的形式

……

團隊複審……全體人員都要到會

這種當面開會的形式有助於更好的實時交流，可是是否會影響到審查的效率？尤爲是一個問題須要冷靜思考的時候。是否能夠將工做分爲多個階段，好比先進行各自思考審查，而後分兩次討論，一次初步彙總，方便你們提出各自的問題，第二次進行最終彙總。

代碼複審的目的在於：

……

書中列舉了6條代碼複審的目的，除了代碼規範的審查外，這一部分工做與單元測試是否有重合的地方？可否進行更高效的改進？

五、書12.1——用戶體驗的要素 中：

程序員則以爲本身開發的功能必須有幾個高級選項，才顯得有水平。

這樣的心理可能確實是存在的，固然實際並不可取，由於是否實現某一個功能應該看用戶的需求，可是對於某一些軟件中的「高級功能」，的確有必定需求；

可是也帶來一些反作用：

一、需求不是很明顯，可是卻須要耗費大量的時間；

二、部分「高級功能」不免會存在用戶使用困難的狀況，這在某些時候反而影響用戶體驗；

針對第一點，開發時應該如何拿捏這樣的度？

針對第二點，或許能夠經過添加使用說明這樣的方式解決一些用戶使用的困難，可是仍然帶來了一些不便利的因素，可否有更簡單易行的方案（佔在用戶的角度）？

2、「軟件」 和 「軟件工程」 這些詞彙是如何出現的？

• 「軟件」一詞最先是由John Turkey在1958年發表的「The Teaching of Concrete Mathematics」這篇文章中提出的。
• 「軟件工程」一詞最先是在美國阿波羅11號研製期間由科學家Margaret Hamilton提出。

3、關於軟件工程的軼事

• 馬化騰的軼事

  QQ最初誕生時就很受歡迎，用戶幾何級瘋狂增加，但從商業上說，QQ在至關長時間內，帶給騰訊和馬化騰的，只是麻煩，主要的麻煩就是這玩意兒費錢卻不掙錢，由於採起免費模式，QQ用戶的增加不但沒能爲其帶來收入，並且還不斷加劇其運營負擔。

  當時的市場也尚未意識到用戶的商業價值，馬化騰他們也沒有意識，能夠去找風投融資，既不能本身掙錢，也無人看好與投資，QQ沒幹多久，馬化騰他們手裏那點老本就快花光了，嚴峻時刻，落魄到連服務器託管費用都負擔不起，開工沒多久，馬化騰和其餘幾個創始人，天天睜開眼睛，就要爲錢操心。

4、簡述目前流行的源程序版本管理軟件和項目管理軟件的優缺點

• 從維基百科中能夠查詢到目前主要的版本控制軟件的使用狀況：

• 對比幾個主流版本控制軟件的優缺點以下：

軟件	優勢	缺點
GIT	一、快速且靈活，不一樣分支不一樣版本之間能夠靈活的切換； 二、工做時本地與服務器相互分離，不易發生衝突致使出錯； 三、比較適合分佈式的開發。	使用有必定難度，若要熟練使用須要對其有充分的瞭解，故不易上手。
Microsoft TFS	一、適合小團隊開發； 二、使用者能比較高效的掌握項目進度、BUG追蹤等狀況。	速度相對較慢，對於硬件有必定的要求。
Trac	1.有較好的擴展性； 二、有較好的靈活性； 三、有着完備的權限體系。	核心功能較少，還須要一系列複雜的插件；
Mercurial	一、擴展性較好； 二、使用方便，上手簡單；	功能不夠齊全；分支管理不方便。