[2017BUAA軟工]第一次博客做業

1、一些疑問

　　看書看得比較慢，暫時只思考了如下幾個問題，有些自問自答，不知道符合不符合要求……

 

【1】

　　第一章中書上提到了這樣一個例子：

　　「若是一架民用飛機上有需求，用戶使用它的機率是百萬分之一，你還要作這個功能麼？」

　　對此我有個問題：若是這個功能和飛機的安全性能無關，那麼還須要實現這個功能嗎？

　　我一開始的想法是，是否實現這個功能是要根據價值指望（被使用的機率*它的重要性）來決定，對於安全功能，即使它被使用的機率很小，可是它的重要性很高，所以價值指望也就很高。可是後來我考慮到，實現一個功能須要一系列代價，包括開發精力、對運行速度的影響、對穩定性的影響等等……若是飛機的安全保障須要花費龐大的人力和財力（比目前的還要再高很多），這個功能真的還會被應用嗎？

　　我大概想了一下，若是被應用了，多是如下這個路線：

　　機票價格上升→大衆負擔不起→客戶減小→公司破產……

　　這可能有點誇張，可是我正想用此表達個人疑問：開發成本和產品安全性之間應該如何抉擇？我認爲在這種狀況下，產品安全性的地位不是絕對的，只要不虛假宣傳，買不買機票是乘客說得算的。若是乘客認爲不值得花費更高的金額去換取百萬分之一的安全，他有權利選擇價格更低的機票。因此最好的辦法或許是造出兩種飛機（就好像經濟艙和商務艙），讓乘客決定哪種更適合本身。實際上如今不少軟件也分爲「社區版」和「專業版」，後者比前者功能更強大也更穩定，可是要貴得多，不知道這和上面的例子有沒有關係呢……？

 

【2】

　　第二章中提到了用「單元測試」去檢測代碼的正確性，對此我有個疑問：單元測試的正確性應該如何保證？是否還須要寫一個單元測試去檢測單元測試呢？

　　我查了資料[1]，博文做者提到了「TEST FIRST」的觀點，這一點在《構建之法》中也有說起。在開發以前先設計測試代碼的的好處是，測試代碼能夠更加靈活、清晰，在不受到開發代碼制約的同時，也爲後面的開發明確了思路。與此同時，做者還強調測試應該針對需求進行，不該該涉及別的類，這卻是省了些工夫，但我我的感觸不是很深，以前總感受測試代碼越詳細越保險，不知道做者的想法是否有可取之處。總的來講，做者的觀點是對於開發人員，測試要針對需求，更加細緻的測試是測試人員乾的事情。那麼也就是說OO還有此次軟工我的做業的測試是爲未來從事測試方面的工做打下基礎？仍是說這也是開發人員應該掌握的技能呢？

 

【3】

　　程序的可擴展性與運行速度應當如何取捨？就拿這一次做業來講，我是採用了在模板上變換的作法來生成數獨，這樣的優勢是很快，可是缺點是生成的數獨具備很大的共通性，算不上實用。若是後期老師又要求生成一億個數獨甚至更多，這種套路恐怕難以適用。

 

【4】

　　第四章書上特地提到了「只要有助於程序邏輯的清晰體現，什麼方法均可以使用，包括goto」。可是已經有人證實過goto語句的沒必要要性，並且自從大一開始學習c語言以來，老師、學長一再強調不要使用goto，會形成代碼可讀性降低，這一點和書上所寫的不是矛盾的嗎？

　　後來去了一些論壇看了看，發現使用goto的人好像也很多，畢竟存在即合理，可是使用goto的人都遵循着一個原則——不影響程序的順序性，也就是說goto只能用於向下跳轉，不能向上跳轉。通常狀況下，goto語句多被用於跳出多層循環，這一點我也在此次數獨做業中進行了嘗試，感受仍是很方便的。

　　可是讓我不太明白的是，goto這種不被推薦的用法，有時候也能找到它的「用武之地」，那麼若是團隊明確規定「不容許使用goto語句」，這是否是一個合理的作法呢？這讓我想到了不少團隊都對一些代碼規範進行嚴格的規定，好比大括號必定要換行，必定要用四個Space代替Tab等等……這些代碼風格常常能成爲論壇中的「引戰帖」，能夠看出各有優劣，那麼強硬地要求使用某一種代碼風格有沒有必要呢？

 

【5】

　　第五章開頭，做者強調了「團隊」與「非團隊」的區別——「團隊目標一致，互相依賴合做，共同完成任務；而非團隊成員則彼此獨立，甚至能夠隨時脫離隊伍」。非團隊給個人感受就是聘用者和受聘者的關係，leader給受聘者發放薪水，受聘者給leader打工，一分錢一分貨。我因而在想，若是按照這種定義來看，豈不是企業中就不存在團隊了？

　　可是仔細想了想，我以爲也不必定。衡量一夥人是否是一個團隊不能只看薪水，而是他們在關心什麼。團隊的成員關心團隊是否可以取得成功，而非團隊的成員只關心還有沒有工資能夠拿。也就是說，即使拿了工資，偶爾也能關心一下項目進展，那麼這也能夠做爲一個團隊。

　　那麼個人問題是，做爲一個由「僱員」組成的團隊，成員爲何會願意關心團隊的情況呢？在軟工課上，之因此每一名成員都努力爲團隊作貢獻，是由於團隊的期末答辯拿到了高分，每名成員均可以收穫不錯的成績。在創業初期的團隊中，可能每名成員不只可能吃不上飯，還須要付出至關大的努力。那麼是什麼維繫着這個團隊呢？大概是若是創業成功了，每名成員都將獲得巨大的利益，這份利益徹底對得起他們的付出。

　　個人理解是，團隊之因此是團隊，是由於團隊的成功能夠爲每個成員帶來好處，若是一個吝嗇的leader不肯意將隊伍的成果分享給每一名成員，而僅僅用工資打發他們，那麼我想成員也不必再關心這個隊伍的進展了。實際上，不少企業都會根據當年的業績發放「年終獎」，這就是將團隊利益共享的一個很好的方式。

　　因此我在想，是否是一個非團隊，若是可以實現利益的共同化，它就能夠變成一個團隊呢？

 

 

---

 

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

　　1958年，Tukey發表了一篇題爲「The Teaching of Concrete Mathematics」的論文，這是所知的「software」一詞最先的用法。[2]

　　「software engineering」是Apollo計劃中，Hamilton在MIT提出的，她想要給予軟件「合法性」，就像其它工程學科同樣。[3]

 

 

---

 

3、軟件工程發展的趣事和冷知識

　　「I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git.」

　　Git這個名字是Linus Torvalds在編寫第一個版本的時候起的，他將這個工具自誇爲「the stupid content tracker」（傻瓜內容跟蹤器）。我從Git的官方wiki找到了關於這個名字的多種解釋，用本身的渣英語翻譯一下：

1. 三個隨機的、可發音的字母，而且它沒有被做爲任何UNIX的指令，它是被誤讀的「get」這件事變得可有可無；
2. 辣雞、卑鄙、簡陋，字典裏的粗話隨你挑；（該詞在英國俚語貌似是髒話OTZ）
3. 是「global information tracker」（全局信息跟蹤器）的簡寫：若是你心情不錯，而且它正常地運行着，天使們在歌唱，一縷陽光灑進房間；
4. 是「g*dd*mn idiotic truckload of sh*t」的簡寫：若是它崩了……

 

 

---

 

4、上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麼優缺點？

　　其它的不太瞭解，Github在2013年用戶數量突破了300萬[4]，並且根據2016年GitHub的Octoverse報告顯示，在過去一年中，來自中國的新用戶註冊增加最快，同比增加了97%，其次是印尼（90%）、印度（76%）、俄羅斯、巴西和日本。[5]

 

[GIT]

優勢：

　　1.分支能力特別強大，體驗特別好。加上支持離線提交，分佈式推送拉取，使得代碼層面的協做至關流暢；[6]

　　2.GIT的分支模型很全面很好用，能夠自由地修改歷史，方便多個版本庫的交流。

缺點：

　　1.概念過於複雜；

　　2.命令行語法設計得比較隨意且不一致；

　　3.命令行幫助提示晦澀難懂；

　　4.缺少良好的封裝；

　　5.對代碼的維護者友好，但卻犧牲了共享者的使用體驗；

　　6.版本管理未必安全；

　　7.一些簡單的操做須要用到過多的命令。[7]

 

[TFS]

優勢：

　　1.任務版上能將需求、項目進度盡收眼底，對於小團隊而言，比甘特圖更有用；

　　2.集成了項目管理、版本控制、BUG 跟蹤，能有效實現 SCRUM；

　　3.能與VS無縫接合。

缺點：

　　1.用瀏覽器訪問至關慢；

　　2.從 IE 上訪問、填寫各類開發、測試記錄，也是很慢，不如 mantis BT 這樣基於 php 的那麼方便、迅速。[8]

 

[Mercuria]

優勢：

　　命令行簡單、容易上手。

缺點：

　　1.Mercurial 在不一樣平臺上（尤爲 Windows 與 Linux 之間）有檔名編碼的問題，若是版本庫可能使用到中文檔名，會形成跨平臺的交流障礙；

　　2.分支方式各有缺點和不便之處；

　　3.改寫歷史很麻煩，操做繁瑣，難以還原錯誤操做以前的狀態，更容易致使版本庫混亂，也更容易出錯致使丟失歷史；

　　4.Mercurial 沒有命名空間，一但和不少個版本庫交流，很容易致使本身與別人的代碼混成一團。[9]

[github]:

優勢：

　　功能設計簡潔實用上手很快，可用性好，已有不少至關質量的各種項目和優秀開發者在上面。[10]

缺點：

　　1.國內訪問速度太慢，常常出現connect time-out；

　　2.不能很好的解決GB2312/GBK，對中文不夠友好；

　　3.wiki功能太弱，直接致使文檔常常被分離到一個獨立站點。[11]

[Bitbucket]

優勢：

　　1.支持Hg，最易學易用的分佈式版本管理工具；

　　2.徹底免費的閉源項目，還支持5人之內的合做開發；

　　3.支持中文；

　　4.官方的git工具SourceTree比GitHub for windows好用。[12]

 

[Trac]

優勢：

　　Trac作一個SCM配置管理平臺，意味着它有良好的擴充性。經過WebAdmin界面中的Plugin功能，能夠很方便的安裝下載的插件，也能夠經過此功能查看已經安裝的插件，並可對其中的插件進行啓用或停用操做。[13]

 

[Bugzilla]

優勢：

　　1.強大的檢索功能，強大的後端數據庫支持, 豐富多樣的配置設定等；[14]

　　2.BugZilla的定製功能的確更強，能知足更多用戶差別化的需求。

缺點：

　　界面比較糟糕。

 

[Rational]

優勢：

　　提升了團隊生產力，在迭代的開發過程、需求管理、基於組建的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變動等方面、針對全部關鍵的開發活動爲每一個開發成員提供了必要的準則、模版和工具指導，並確保全體成員共享相同的知識基礎。它創建了簡潔和清晰的過程結構，爲開發過程提供較大的通用性。

缺點：

　　RUP只是一個開發過程，並無涵蓋軟件過程的所有內容，例如它缺乏關於軟件運行和支持等方面的內容，此外，他沒有支持多項目的開發結構，這在必定程度上下降了在開發組織內大範圍實現重用的可能性。

 

 

參考資料：

[1] http://www.xuebuyuan.com/821497.html

[2] https://en.wikipedia.org/wiki/John_Tukey

[3] https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29

[4] http://kuailiyu.cyzone.cn/article/1453.html

[5] http://digi.163.com/16/0919/06/C1A9M69J001680N8.html

[6] http://www.cnblogs.com/lwl123/p/5253184.html

[7] https://www.zhihu.com/question/20401926/answer/15034642

[8] https://www.zhihu.com/question/21943395

[9] https://www.zhihu.com/question/21905835/answer/94503278

[10] https://www.zhihu.com/question/19591651/answer/12314492

[11] https://www.zhihu.com/question/19591651/answer/12798445

[12] https://www.zhihu.com/question/20053312/answer/20005315

[13] https://baike.baidu.com/item/trac/7367196?fr=aladdin

[14] http://blog.csdn.net/qq_33336155/article/details/53321885

[13] http://blog.csdn.net/wayne_ran/article/details/1555686

[14] http://www.docin.com/p-1614947229.html