軟件工程第一次閱讀做業

軟件工程第一次閱讀做業

瀏覽《構建之法》後的一些問題

一、關於結對編程的形式

關於結對編程，書中提到：

在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤、同一個鼠標一塊兒工做。他們一塊兒分析，一塊兒設計，一塊兒寫測試用例，一塊兒編碼，一塊兒作單元測試，一塊兒作集成測試，一塊兒寫文檔等。

...

總之，若是運用得當，結對編程能夠取得更高的
投入產出比（Return of Investment）。

的確，若是以這樣的形式進行結對編程，出現bug的機率會大大下降，也有助於遵照各類編程規範。可是，這樣的方式無疑捨棄了「並行」的優點，尤爲是在進行到邏輯簡單，難度較低的部分時，出現bug的機率不高，若兩人分工同時進行，無疑能夠大大提高完成速度。個人疑問是，結對編程是否更適合在學習、培訓過程當中採用？在實際生產中結對編程真的能取的更高的投入產出比嗎？

二、關於第六章中敏捷流程對於需求變化的歡迎

第六章中，對於敏捷開發的原則，提到：

1. 敏捷流程歡迎需求的變化，並利用這種變化來提升用戶的競爭優點

需求的變化一直是乙方最爲頭疼的問題之一。我理解敏捷流程中經過快速迭代的方法來適應需求變化的原理，可是，對於那些已經定好、實現完成的需求的變化，仍然須要推翻本來的設計與實現，再進行更改。對於這類已經確認過、且實現完成的需求的更改，我認爲多少是有些不合理的。那麼在實際生產中，對於這種需求變化，也應無條件接受嗎？或者說對於需求變化的歡迎的極限應該在哪裏？

三、關於創新的問題

第16章中，部分人對創新想法的反饋中，有：

沒有人須要這些方案

在實際中根本行不通

大衆不會理解這個創新

在一個創新想法，尤爲是一個顛覆性的創新、跨度較大的創新想法出現時，在當時的場景下經常出現「找不到應用場景」、「短期內不知道有什麼用」的狀況出現，某種程度上也符合上述書中列舉的理由。那麼對於這樣「短時間內不知道能有什麼用」的創新想法，應如何客觀的評價其前景？應投入多大的時間、精力在其中？

四、創新者大可能是非專業領域人士

一樣在第16章，書中提到

這個想法看起來沒什麼錯，咱們不就是爲了成爲某個領域的專家，纔來上學，拿學位，但願拿到學位以後成爲專家，而後再開始這個領域的創新？可是統計數據代表，70%的創新者說，他們最成功的創新，是在他們的拿手領域以外發現的。

那麼做爲計算機專業的學生，未來必然是「領域內」人士之一，那麼如何避免造成如同「領域專家」的固化思惟，致使本身的創新思惟收到限制呢？

五、如何下降理解偏差的問題

全書中多處提到，在團隊合做中應多交流、多溝通，才能提到合做效率。這一點我很是贊同。可是在團隊中的成員們相互溝通的過程當中，對於一個問題，即便達成了共識，也經常由於每人的思惟方式不一樣，致使雙方心中的答案並不一致。書中提到的儘可能面對面交流確實相比文字、語音交流的效果更好，但也不能避免這一問題的出現。那麼有什麼好方法能儘可能下降理解偏差，確保你們達成」共贊成見「時，每一個人腦中的理解都是相同的呢？

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

「軟件」一詞最先來源於John Tukey與1958年發佈的論文The Teaching of Concrete Mathematics中。所以，認爲是John Tukey發明了軟件一詞。

「軟件工程」由女科學Margaret Hamilton在爲阿波羅11號研製軟件的過程當中發明，目的是將軟件工程與硬件或其餘工程學類作出區分。

主流項目管理軟件的使用人數、優缺點

根據網上資料，幾款主流項目管理軟件使用人數從多到少的排名爲

一、GitHub

二、SourceForge

三、Bitbucket

四、GitLab

五、Assembla

在網上搜索了相關的信息如博客，知乎後，總結相關項目管理軟件的優缺點以下：

• Microsoft TFS
  • 優勢：方便小團隊對於需求、進度的掌握，集成了項目管理、版本控制、BUG追蹤等功能，且與VS完美接合。
  • 缺點：搭建複雜，硬件需求高
• GitHub
  • 優勢：功能極其齊全，方便交流合做
  • 缺點：學習成本較高，須要經過較長時間的學習、熟悉後才能流暢使用各類命令
• Trac
  • 優勢：擴充性好，權限體系完備，較爲靈活
  • 缺點：不支持多項目，漢化不完整，中文支持較差
• Bugzilla
  • 優勢：免費，且有中文支持
  • 缺點：只能管理缺陷，功能較少
• Apple XCode
  • 優勢：自動建立分類圖表，撤回、重作、保存等經常使用功能使用方便，不須要命令、代碼
  • 缺點：在版本更新後，部分插件可能失效，致使諸多問題。
• Mercurial
  • 優勢：有revset，拓展性好，部署較爲簡單
  • 缺點：強制向下兼容