| 專案 | 內容 |
|---|---|
| 所屬課程 | 2019春季計算機學院軟體工程(任健)（北京航空航天大學） |
| 作業要求 | 這裡 |
| 課程目標 | 提升自己的程式設計水平，拿一個合適的分數 |
| 這個作業在哪個具體方面幫助我實現目標 | 對軟體工程有一個簡單的瞭解，查了很多資料 |
1. 快速看完整部教材，列出你仍然不懂的5到10個問題。
我覺得這本書寫的十分好，內容由易到難，循序漸進，十分適合對這方面還沒有什麼太多瞭解的初學者使用。我在第一遍快速閱讀本書時覺得沒有什麼太大的疑問，大部分內容都言之有理，書籍質量十分高。但是題目要求列出至少5個不懂的問題，因此我又比較仔細地讀了一遍全書，提出了這些問題：
1. 關於結對程式設計和程式碼複審
書中這樣提到了這樣一段話：
既然程式碼複審能發現這麼多問題，有這麼好的效果，如果我們每時每刻都處在程式碼複審的狀態，那不是很好麼？事實上，極限程式設計（Extreme Pro-gramming）正是這一思想的體現—為什麼不把一些卓有成效的開發方法用到極致（Extreme），讓我們無時不刻地使用它們？
書中說結對程式設計是一種進化到極致的程式碼複審，相當於無時無刻不在程式碼複審。眾所周知程式碼複審能找到許多問題，可是無時無刻的程式碼複審真的效率更高嗎？我覺得結對程式設計還要面對兩個人思路不同，理解速度不同，寫程式碼速度和思考的速度不同等問題。比如邏輯簡單，難度低，出bug概率低或者之前寫過類似的功能的部分，多人並行的效率是否更高呢？我覺得一個程式核心程式碼使用結對程式設計，非核心部分分開編寫並測試效率是不是更高呢？
2. 軟體開發流程（5.3章）
我之前曾經上過外系的一門選修課：系統工程概論。我認為軟體開發也是一門系統工程，比如系統工程中常見的五個階段以及經典的V字模型：結構分解與定義，結構綜合與驗證與軟體開發過程也有相通之處。我比較好奇系統工程的方法和書中的軟體開發流程的關係，以及敏捷開發是否是比系統工程方法更先進。
3. 目標人群與大膽做減法
書中在第12章中提出要找準目標人群，同時也說大家平時都說要向某某大師或某某產品學習，把最重要的功能做好交給使用者，把那些無關緊要的功能藏起來，做減法…但是做減法適應更多人群可能也會失去原來目標人群的興趣，例如減去了原來很有意思的功能。在經濟管理中我們瞭解到了有一種需求是興奮需求，能極大的刺激人們的購買慾望，可是在這裡它無疑是最容易被做減法砍掉的。那麼我們應該如何確定到底該減什麼？
4. 關於創新（16章）
書中這樣提到了創新：但是統計資料表明，70%的創新者說，他們最成功的創新，是在他們的拿手領域之外發現的。蒂姆·伯納斯-李是一個物理學家，他在1989年3月提出了一個想法，想利用超文字（HyperText）實現方便的資訊共享和更新。他的老闆看了之後，說"Vague, but exciting."這裡有兩個問題，一是如何保證自己的創新被採納。如果創新者的創新是在他們的拿手領域之外發現的，那麼該如何說服那些領域內大佬聽取自己的創新？第二個問題是舉例不妥。蒂姆·伯納斯-李實際上在開發超文字之前是一個軟體工程師。根據 維基百科 畢業後，伯納斯-李在多塞特郡普爾的Plessey電信公司擔任工程師。1978年，他加入多塞特郡芬當的D. G. Nash公司，替印表機編寫了排版軟體. 雖然他是物理學士學位，但是看上去他畢業以後就轉行了，並且在上學期間自己組裝了電腦。 而且他加入CERN是作為獨立承包商而不是一個物理學士畢業生。
5. 關於團隊（17章）
在17章中講了團隊合作的幾個階段，比如假團隊什麼的。那麼在實際遇到了假團隊時應該主動走人或者撕破臉嗎？會不會錯失磨合成真團隊的機會，或者讓自己在他人口中的名聲變差？還是說應該撐下去等著呢？這個期限又是多少？
2. 請問 “軟體” 和 “軟體工程” 這些詞彙是如何出現的 - 何時、何地、何人？
Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.
The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.
根據 維基百科 的內容，軟體這個單詞早在上世紀五十年代就已經出現。Richard R. Carhart 或 John Tukey 被認為是最早提出該概念的人。
而根據 這篇部落格 中的內容，
你是在這段期間發明了“軟體工程”一詞嗎？
Ａ：軟體在這個計劃的初期還被當作初初學步的孩子一般對待，完全不像其他工程學科；例如像硬體工程那樣的受到重視，而且在大家的眼光中他就像是藝術、魔術一般，而不是一門科學。
我一直以來堅信這項發明流著藝術與科學的血液，雖然當時很少人是這麼想。因此，我致力於為軟體以及那些發明者爭取應有的正統性與尊重，所以我開始使用“軟體工程”這樣的字眼來將之與硬體還有其他工程學類做出區別。
當我第一次使用這樣的語詞時，大家都覺得有些好笑，甚至有很長一段時間被當作笑話。他們常笑我極端的想法。但最終，軟體學科確實得到了應有的尊重！
Margaret Hamilton 被認為是軟體工程一詞的發明者，她1969年左右開發阿波羅11號程式時發明了該詞。
然而，根據 維基百科 中的內容，軟體工程這個詞可能還有其他許多發明者。
The origins of the term "software engineering" have been attributed to various sources. The term "software engineering" appeared in a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION and was used more formally in the August 1966 issue of Communications of the ACM (Volume 9, number 8) “letter to the ACM membership” by the ACM President Anthony A. Oettinger;, it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering. Margaret Hamilton is the person who came up with the idea of naming the discipline, “software engineering”, as a way of giving it legitimacy. At the time there was perceived to be a "software crisis".The 40th International Conference on Software Engineering (ICSE 2018) celebrates 50 years of "Software Engineering" with the Plenary Sessions' keynotes of Frederick Brooks and Margaret Hamilton.
我更傾向於這些詞彙是一個群體在交流時自發形成的共識，是一個群體的共同產物，而沒有一個特定的創造者。
3. 【附加題】：大家知道了軟體和軟體工程的起源，請問軟體工程發展的過程中有什麼你覺得有趣的冷知識和故事？
我想到了Ken Thompson 在UNIX和編譯器插入後門的故事了。我講故事的水平比較低，因此就直接引用別人講的故事了。
Ken爺爺有段佳話：裝了UNIX的PDP-11最早被安裝在Bell Lab裡供大家日常使用。很快大家就發現Ken爺爺總能進入他們的帳戶，獲得最高許可權。Bell Lab裡的科學家都心比天高，當然被搞得鬱悶無比。於是有高手怒了，跳出來分析了UNIX程式碼，找到後門，修改程式碼，然後重新編譯了整個UNIX。就在大家都以為“這個世界清淨了”的時候，他們發現Ken爺爺還是輕而易舉地拿到他們的帳戶許可權，百思不解後，只好繼續鬱悶。誰知道這一鬱悶，就鬱悶了14年，直到Ken爺爺獲得圖靈獎之後，發表自己獲獎感言時道出個其中緣由。原來，程式碼裡的確有後門，但後門不在Unix程式碼裡，而在編譯Unix程式碼的C編譯器裡。每次C編譯器編譯UNIX的程式碼，就自動生成後門程式碼。而整個Bell Lab的人，都是用Ken爺爺的C編譯器。
參考來源： Ken Thompson的故事 , The Ken Thompson Hack
4. 上網調查一下目前流行的源程式版本管理軟體和專案管理軟體都有哪些， 各有什麼優缺點？
目前流行的源程式版本管理軟體有 Git, SVN, Microsoft TFS, Mercurial, Trac 等。由於我沒有使用過Git以外的工具，下面的內容優缺點的部分主要是對網上資料的整理和總結。
使用人數估計
我找到了StackOverflow公佈的 2017 和 2018 年的調查資料，其中包括了對於所使用的版本管理工具的調查。我沒有找到原始資料，因此以截圖的形式給出。
由圖中可見無論是否是專業開發者，Git的使用者遙遙領先並不斷增加，而其他版本管理工具都比較少。可見Git確實有其出眾之處。
優缺點
在 維基百科:版本控制軟體比較 中列舉了詳細的各種版本控制軟體比較，包括支援功能，維護狀態，使用者介面，歷史與使用者等等，然而有些過於專業了。
Git
一個常見的版本控制軟體
優點主要有：
- 分支切換快，分支都在本地儲存，適合小實驗。
- 支援廣泛，被大量現代IDE支援，使用起來方便。
- git更加分散式，容災好。
缺點有：
- 保密性不夠好，容易不小心洩露程式中的賬號，密碼，開發機路徑等，而刪除這些敏感資訊時要把每個commit都檢查一遍。
- 分散式同樣導致了敏感資訊一旦被clone，就會在某處留下備份。
SVN
優點：
- 對中文支援好，操作簡單，使用沒有難度，美工人員，產品人員，測試人員，實施人員都可輕鬆上手。
- 使用介面統一，功能完善，操作方便。
- 有嚴格的許可權管理
缺點：
- 不適合程式碼管理（適合專案管理）
- 使用中心伺服器，容災較差。
Microsoft TFS
優點：
- TFS是一個應用軟體生命週期管理（ALM）軟體，是一個軟體研發平臺產品，其功能覆蓋了軟體研發過程中的所有環節（包括原始碼管理）和所有角色
- 比SVN更加易用
- 支援程式碼評審，bug追蹤等複雜功能
- 支援Git等，有擴充套件性
缺點：
搭建複雜，硬體需求較高
Mercurial
優點：- 更輕鬆的管理。
- 採用分散式系統，更健壯。
對網路的依賴性更低。
缺點：
- Mercurial倉庫中尚不支援Pack操作，當倉庫中小檔案非常多的時候，分散儲存會導致空間浪費
- 以Revlog方式儲存的changelog，子版本與父母版本之間是通過Revlog欄位p1和p2進行連結的，有被篡改的風險。
- Mercurial一開始的設計是不支援分支操作的，如果需要分支，就需要重新克隆Mercurial倉庫。
Trac
優點：
- 非常靈活
缺點
- 功能較弱
題目中還提到了Github， Bitbucket， Bugzilla， Rational， Apple XCode等。其中Github和Bitbucket是網路原始碼託管服務，區別是更加註重於公開倉庫與私有倉庫，Bugzilla是用於軟體缺陷的追蹤管理網路程式。Rational 好像是一個IBM開發的專有軟體，考慮到IBM軟體如SPSS的模式，這應該是一個專業性很強的平臺。Apple XCode好像是一個IDE，支援主流版本管理系統。
參考資料：SVN和Git 介紹,區別,優缺點,適用範圍總結,比較TFS與SVN，你必須知道的10點區別,管理軟體的優缺點,Mercurial與TortoiseHg簡介,分散式版本控制系統Mercurial介紹與使用小記,CVS，GIT，Mercurial和SVN比較,分散式版本管理工具的內涵【二】Mercurial篇