【BUAA軟件工程】第一次閱讀做業

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

項目	內容
這個做業屬於哪一個課程？	北航軟工
這個做業的要求在哪裏？	第一次我的做業
我在這個課程的目標是？	學習高效嚴謹的軟件工程開發過程，創建團隊意識
這個做業在哪一個具體方面幫助我實現目標	熟悉並瞭解軟件工程的基本知識，創建興趣

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

1.軟件開發中的風險控制？

現代軟件開發中不免要用到一些第三方開發的開源庫，好比python，js等語言，這些庫爲咱們的開發帶來便利的同時，也爲咱們帶來了安全隱患，由於這些庫的質量是咱們沒法保證的。好比18年聖誕節發生的阿里的開源UI框架Ant Design中的彩蛋事件。那麼，在成熟的商業公司的開發中，是怎樣看待和使用這些第三方庫的？

2.單元測試的隨機性，複雜性，如何創建合適的斷言

測試已是軟件開發中必不可少的一個步驟，咱們確實是有必要對程序進行全面嚴謹的單元測試。可是以咱們本次的結對開發任務爲例，咱們提供一個找到最長單詞鏈的接口。測試的時候，難道咱們就只測試返回的長度而不去考慮整個鏈的組成麼？尤爲是咱們將測試集的單詞量級定爲10000時，如何構造一個合適的數據集？人工構造耗時耗力。

3.代碼的命名規範

書中好像對代碼的簡潔性要求比較高，例如它給出這樣的例子，」表示整年假日的列表「不用寫arraylistOfHolidays,能夠直接寫做holidays，我感受這個與個人開發經驗是不符的，按照個人寫法，應該會被命名爲holidaysList，這樣能夠看出變量的數據類型。

4.代碼的驗收測試

越長的代碼越不可能沒有bug，咱們平時幾百行的程序固然能夠作到完成全部測試並改正找到的bug，像一些商業軟件最後的驗收會不會有妥協。是必定要作到測試中的零bug，仍是對bug分類，不影響核心功能的bug若是工期緊或者代價大就不改了？

5.需求引導與變動

我以前用的一款手機APP忽然從左右滑動翻頁，換到了上下滑動自動加載。我不太習慣，用戶社區裏也有不少反對的聲音。可是幾個更新版本下來，APP並無回滾的意思。咱們在開發中遇到這種事應該怎麼決定，好比處於技術或者美觀的考慮須要改正用戶的習慣操做時，咱們應該怎麼抉擇？

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

軟件（英語：software）：第一個關於軟件的理論是艾倫圖靈在1935年發表的論文《On Computable Numbers, with an Application to the Entscheidungsproblem》。可是軟件software一詞是在1953年，Richard R.Carhart在公司的備忘錄中首次提出並使用這個詞.

軟件工程是1968年，NATO（北約）的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫「軟件危機」的對策。會議上提出了軟件工程software engineer一詞。根據後來的報導，應該是女科學家Margaret Hamilton在會議上提出了該詞。

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

我在知乎上看到過這樣一個笑話，算是跟軟件有關吧

當年麻省理工的一名系統管理員，突然收到統計系主任打來的求助電話「我們的郵件發不了500英里之外的地方，其實，是520英里更準確點」。
系統管理員內心￥！&……*&。
不過在他開始用本身的郵件測試後，發現郵件的確只能發往520英里之內，其他的收件地點一概失敗。

因而在他一片糾結中他漸漸開始發現問題，郵件服務器被人更新過操做系統（當年仍是SunOS），可是因爲操做系統的發行版每每配備了舊版軟件，因而在更新操做系統的時候郵件軟件反而被降級了（Sendmail 8 -> Sendmail 5）。
因而進一步調查發現，在更新操做系統時，管理員本身編寫的Sendmail配置文件（sendmail.cf）被保留了下來。這樣就出現了這種情況：Sendmail 5嘗試解析Sendmail 8的配置文件。

可是爲何會是500miles呢？爲何是500miles咧？

緣由是這樣的，Sendmail 5面對陌生的配置文件，凡是不理解的部分都會忽略，凡是沒設置過的配置項自動設置成0。這樣其中有一個被設置成0，這一項就是 （鏈接遠端SMTP服務器的超時時間）timeout to connect to the remote SMTP server。後來通過實驗，發現0秒的timeout會致使Sendmail在3毫秒後中斷鏈接。

因此，爲啥是500miles？
在當年，MIT的校園網是沒有那麼多router的，也就沒那麼多網絡延遲，因此鏈接一個遠端主機的時間大概就是光所需的時間。因而3毫秒, 就意味着：

558英里。也就是558英里之外的服務器，都沒法鏈接到，而558英里之內的服務器，均可以正常通訊。

噹噹噹，這就是500英里的bug啦。

來源：有哪些讓你目瞪口呆的 bug？

上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麼優缺點？請按照最近一兩年使用人數的多少， 從多到少排序並說明各自有多少用戶（估計），工具的優缺點（能夠引用相關資料並註明來源）。

在stackoverflow18年作的一次開發者調查中，有必定用戶數量的版本管理軟件有Git，Subversion，Team Foundation Version Control，Mercurial等等（除了單純的複製，備份），他們具體的排名是這樣的：

在全體開發者的範圍內排名：

在專業開發這的範圍內排名:

其實這些軟件中，我實際用過的也只有git，因此只好結合它們各自的百科和博客紙上談兵一番。

git

• 優勢

  • 適合分佈式開發，強調個體。

  • 公共服務器壓力和數據量都不會太大。
  • 速度快、靈活。
  • 任意兩個開發者之間能夠很容易的解決衝突。

  • 離線工做。

• 缺點
  • 學習週期相對而言比較長。
  • 不符合常規思惟。
  • 代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。

Subversion（SVN）

• 優勢

  • 採用集中式，易於管理，保證安全性；

  • 管理方便，邏輯明確，理念符合常規思惟；
  • 代碼的一致性高；
  • 適合人數很少的項目開發；
  • 容許一個文件有任意多的可命名屬性，會關注全部的文件類型；
  • 支持二進制文件，更容易處理大文件；

  • 支持空目錄。

• 缺點
  • 服務器壓力太大，數據庫容量暴增；
  • 必須鏈接在服務器上，不然基本不能工做、提交、對比、還原等；
  • 不適合開源開發

Team Foundation Version Control

• 優勢
  • 可視化作的很好
• 缺點
  • 中文資料太少
  • 須要藉助微軟的開發平臺

Mercurial

• 優勢
  • 輕量，易用性強
• 缺點
  • 中文博客和資料比較少