軟件工程第一次閱讀做業

1、看完《構建之法》,我仍然不懂的問題

1.第二章 我的技術和流程

關於單元測試,我注意到這樣一句話git

單元測試必須由最熟悉代碼的人(程序的做者)來寫。數據庫

單元測試是爲了確保程序基本模塊的正確性,但是因爲程序是本身寫的,那麼頗有可能做者只測試了本身考慮過的數據,而對一些邊緣數據或者異常數據測試不到,那麼是否能夠向他人徵集測試數據?或者由他人根據模塊的功能編寫單元測試是否可行?編程

2.第三章 軟件工程師的成長

關於軟件工程師的思惟誤區中,我注意到這樣一句話後端

這個毛病早就被概括爲「過早的優化是一切罪惡的根源」。服務器

我在模塊化編程時,習慣性先進行簡單的優化,若是等到最後程序完成時再進行優化,我認爲可能就會有不少能夠進行優化的地方被忽略掉而只進行重點優化,就算一一找出能夠優化的地方也會更加耗費時間,因此在編程時就進行基礎的優化是否會更好一些?分佈式

3.第四章 兩人合做

關於如何結對編程,我注意到其中第3條模塊化

駕駛員和領航員不斷輪換角色,不要連續工做超過一小時,每工做一小時休息15分鐘。領航員要控制時間。單元測試

我對於駕駛員和領航員不斷輪換角色感到了疑惑,根據個人編程經驗,不斷換工做會影響本身的編程思路,下降工做效率,此外我認爲每一個人有本身擅長的工做,揚長避短才能提升效率。此外不要連續工做超過一小時是否太過絕對?我在編程時有時編到興起,幾乎會忘了時間,感覺不到疲勞,若是在這期間忽然打斷,感受就像靈感忽然被抹去,因此休息時間是否能夠更加靈活的自由把控?學習

4.第十四章 質量保障

關於分工的問題,我注意到一句話測試

分工以後,每一個角色爲了本身的績效而優化,會出現局部最優而全局未必最優的狀況。

在第三章中寫到過早的優化是一切罪惡的根源,是否這也是其中的一個緣由呢?若是是,那麼在分工後,每一個角色應該在什麼時候進行優化?

5.第十六章 IT行業的創新

關於贏者通吃

這個遊戲規定第一名獲得所有的分數,第二名(無論多接近)到倒數第二名都是0分,最後一名還要倒扣分。軟件行業就是一個贏者通吃的環境,最後一名還要把本身的身家倒貼進去。

若是軟件行業是贏者通吃的環境,那麼是否意味着例如美團外賣餓了麼外賣這樣的競爭軟件只會有一者生存下去?但綜合來看,它們的功能不徹底一致,因此若是它們一直共存下去了,是否意味着贏者通吃的軟件環境有一個前提——軟件的功能徹底一致?因此只要有本身獨特的賣點和受衆是否就不會被通吃?

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

  • 「軟件」是由John Tukey1958年在其論文"The Teaching of Concrete Mathematics"中提出來的。
  • 「軟件工程」一詞是由Margaret Hamilton創造的。在1968年北大西洋公約組織在前聯邦德國開會提出的。

3、軟件工程發展的過程當中有趣的冷知識和故事

不少人都知道,Linus在1991年建立了開源的Linux,今後,Linux系統不斷髮展,已經成爲最大的服務器系統軟件了。
Linus雖然建立了Linux,但Linux的壯大是靠全世界熱心的志願者參與的,這麼多人在世界各地爲Linux編寫代碼,那Linux的代碼是如何管理的呢?
事實是,在2002年之前,世界各地的志願者把源代碼文件經過diff的方式發給Linus,而後由Linus本人經過手工方式合併代碼!
你也許會想,爲何Linus不把Linux代碼放到版本控制系統裏呢?不是有CVS、SVN這些免費的版本控制系統嗎?由於Linus堅決地反對CVS和SVN,這些集中式的版本控制系統不但速度慢,並且必須聯網才能使用。有一些商用的版本控制系統,雖然比CVS、SVN好用,但那是付費的,和Linux的開源精神不符。
不過,到了2002年,Linux系統已經發展了十年了,代碼庫之大讓Linus很難繼續經過手工方式管理了,社區的弟兄們也對這種方式表達了強烈不滿,因而Linus選擇了一個商業的版本控制系統BitKeeper,BitKeeper的東家BitMover公司出於人道主義精神,受權Linux社區無償使用這個版本控制系統。
安定團結的大好局面在2005年就被打破了,緣由是Linux社區牛人彙集,難免沾染了一些梁山好漢的江湖習氣。開發Samba的Andrew試圖破解BitKeeper的協議(這麼幹的其實也不僅他一個),被BitMover公司發現了(監控工做作得不錯!),因而BitMover公司怒了,要收回Linux社區的無償使用權。
Linus能夠向BitMover公司道個歉,保證之後嚴格管教弟兄們,嗯,這是不可能的。實際狀況是這樣的:
Linus花了兩週時間本身用C寫了一個分佈式版本控制系統,這就是Git!一個月以內,Linux系統的源碼已經由Git管理了!牛是怎麼定義的呢?你們能夠體會一下。
Git迅速成爲最流行的分佈式版本控制系統,尤爲是2008年,GitHub網站上線了,它爲開源項目免費提供Git存儲,無數開源項目開始遷移至GitHub,包括jQuery,PHP,Ruby等等。
歷史就是這麼偶然,若是不是當年BitMover公司威脅Linux社區,可能如今咱們就沒有免費而超級好用的Git了。

4、目前流行的源程序版本管理軟件和項目管理軟件都有哪些, 各有什麼優缺點

版本管理軟件 優勢 缺點
Git 1.適合分佈式開發,強調個體。2.公共服務器壓力和數據量都不會太大。3.速度快、靈活。4.任意兩個開發者之間能夠很容易的解決衝突。5.離線工做。 1.學習週期相對而言比較長。2.不符合常規思惟。3.代碼保密性差,一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。
Mercurial 1.學習門檻較低。總體上看,須要掌握的命令要比git少不少。2.能夠一鍵徹底恢復到歷史版本的某一個切面。3.封裝好。相比git,不多暴露一些實現內的細節。 1.分支管理不靈活。Mercurial的branch管理和Git相比不是很方便。2.沒有命名空間。
Trac 1.有良好的擴充性。2.Trac的權限體系是比較完備的設計。3.很是靈活,能夠爲所欲爲的定製,能夠和TortoiseSVN集成。 1.不支持多項目。2.需求和缺陷沒有分離。3.核心功能不多,不安裝插件基本上無法用。
Bugzilla 1. 檢索功能強大2. 強大的後端數據庫支持3. 極富多樣的配置設定 1. 安裝須要Perl和配置MySQL數據庫,過程比較繁瑣2. 修改配置文件很麻煩3. 流程沒法定製

用戶量排名

1.Github:約31,000,000用戶量 2.SourceForge:約3,700,000用戶量 3.Bitbucket:約5,000,000用戶量 4.GitLab: 約100,000用戶量

相關文章
相關標籤/搜索