軟件工程第1次做業

時間 2019-11-18

標籤軟件工程简体版

原文原文鏈接

項目	內容
做業所屬課程	軟件工程班級博客
做業要求請點擊連接查看	做業要求
我在這個課程的目標	學習如何用工程化方法構建和維護軟件
這個做業在哪一個具體方面幫助我實現目標	經過閱讀《構建之法》，認識瞭解軟件工程

一.閱讀教材後的問題

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

我看了這一段文字數據庫

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

有這個問題：什麼是過早的優化？什麼是合理的優化？若是全局過於大，又是否要去了解徹底局後，再決定是否優化以及怎麼優化？後端

2.第4章兩人合做

我看了這一段文字服務器

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

有這個問題：在這裏使用駕駛員和領航員用做類比是否不恰當？其次，是否專精一個崗位比常常交換好？我查了資料，賽車中的駕駛員，是負責快速按照指令完成駕駛動做的，領航員則要負責觀察道路，給出車速和擋位的建議，以及駕駛指令。能夠說二者須要的能力是有區別的，很難交換。在結對編程中，常常互換，會不會致使思路打斷，或者產生衝突等等，下降效率。編輯器

3.第4章兩人合做

我看了這一段文字分佈式

如何正確地給予反饋。1.最外層：行爲和後果。2.中間層：習慣和動機。3.最內層：本質和固有屬性。學習

有這個問題：在書上例舉的例子中，選擇最外層的方式的效果是最差的，而選擇最內層的方式的效果是最好的。那麼是否每次選擇的結果，就必定是這樣呢？我發現書上儘管是在講如何正確地給予反饋，可是舉的例子都是在指出不足，那表達感謝又該如何正確地給予反饋呢？我想到了一個例子，想表達別人代碼寫的好。最外層：你此次的代碼寫的很好，我相信咱們會取得好的成績。中間層：你一直都習慣不斷的完善代碼，很富有責任感，想把本身的部分作好，使得整個項目更好。有你在這個團隊，我感到很高興。最內層：你是一個精益求精，一絲不苟的人，作什麼事都很認真，很努力，果真你此次寫的代碼，依然很好。所以個人疑惑是，如何正確地給予反饋，是否還要考慮情感因素，來選擇最內層或是最外層。優化

4.第16章 IT行業創新

我看了這一段文字插件

這些故事的另外一個引伸是——他們都是獨立工做，沒有一個阿基米德團隊或者「牛之隊」在背後支持。

有這個問題：伽利略的自由落體定律和開普勒的行星運動規律算不算「牛之隊」在背後支持？我查了資料，儘管這些科學家和牛頓並無直接共事，但他們和牛頓都有共同的目標——解釋天體運動問題。他們爲牛頓提出他劃時代的理論，提供了堅實的理論基礎，我認爲這屬於一種有共同目標的團隊的背後支持。同時開普勒定律的提出，也不是獨立工做的結果。在開普勒與第谷共事十個月後，開普勒利用第谷留下的大量的寶貴的資料，最終提出了開普勒定律，這也是共同合做的寶貴成果。

5.第16章 IT行業創新

我看了這一段文字

近代以來，不多能有人獨立推出前無古人的發明創造。

有這個問題：這是屬於人的問題，仍是屬於時代或社會發展問題？我查了資料，我以爲有三方面緣由，一.科技黑箱的出現，科技知識和其餘要素被集成於某種框架之中，並不須要知曉裏面運用的技術，只要能執行操做知足需求就好。二.隨着科學技術的不斷產生、分化、延伸，一我的須要花不少時間，去掌握一門特定方向的有侷限性的技術，但發明創造經常須要多門技術的協做。三.現在的社會，很是講究節奏和效率，團隊協做帶來的在進度方面推動的優點被大大致現，也就讓人很難去選擇獨立發明創造。由此我獲得了另外一個疑惑，隨着人類社會的發展，獨立推出發明創造是否是將愈來愈難？

二.請問「軟件」和「軟件工程」這些詞彙是如何出現的

「軟件」一詞是由John Tukey在他1958年的論文《具體數學教學》中提出的。
「軟件工程」一詞是Margaret Hamilton在1969年先後，在阿波羅計劃期間發明創造出來的。

三.軟件工程發展的過程當中有什麼你以爲有趣的冷知識和故事

1975年，艾倫和蓋茨給Altair 8800計算機寫了個BASIC解釋器賣給MITS，他們很快完成了解釋器，甚至包括本身的IO系統和編輯器，一共只須要4k內存。不過最後他們發現還須要一個引導程序將這些東西從外存整進去。 Paul Allen在飛機航班上完成了這項工做。這是1975年，沒有筆記本。他用的是紙筆。寫的是8080機器碼。
來源：知乎

四.目前流行的源程序版本管理軟件和項目管理軟件及其優缺點

軟件	優勢	缺點
Git	適合分佈式開發，強調個體。公共服務器壓力和數據量都不會太大。速度快、靈活。任意兩個開發者之間均可以很容易地解決衝突。離線工做。	學習週期較長。不符合常規思惟。代碼歷史保密性差，一旦開發者把整個庫克隆到本地，就能夠徹底查看到全部的歷史版本信息。
Mercurial	更簡潔好用的命令行指令。上手簡單。完善的GUI支持。易於擴展。	Mercurial的分支模型十分複雜，每一種分支方法都有不少缺點和不便之處。Mercurial改寫歷史很麻煩。沒有命名空間。
Trac	很是靈活，能夠爲所欲爲地定製。能夠和SVN集成。 Trac的權限體系是比較完備的設計。	不支持多項目。中文化不完整。核心功能不多，不安裝插件基本沒法使用。
Bugzilla	檢索功能強大。強大的後端數據庫支持。根富多樣的配置設定。	安裝須要Perl和配置MySQL數據庫，過程比較繁瑣。修改配置文件很麻煩。流程沒法定製。