| 項目 | 内容 |
|---|---|
| 課程 | 軟體工程 |
| 作業要求 | 個人部落格作業 |
| 我的課程目标 | 開發“足夠好”的軟體 |
| 這個作業對我實作目标的幫助 | 閱讀《建構之法》，在大量實踐之前對軟體工程有宏觀了解 |
1.快速看完整部教材，列出你仍然不懂的5到10個問題，釋出在你的個人部落格上
問題1 第一章 概論 提到一個軟體企業有很多賺錢方式
- 有的交錢買斷
- 有的“先試用再交錢”，有些軟體也提供試用版、免費版和正式版，還有的類似期刊訂閱，每年交錢
- 有的不但免費，連源代碼也一并奉送，但是要求獲得源代碼的開發人員遵守某種協定
- 有的送硬體，但是軟體要收錢
- 有的送軟體，但是硬體要收錢
- 也有“免費用，但是要看我提供的廣告”
- 還有“免費用，程式也不是我寫的，如果有問題，給我錢，我就來提供咨詢……”
世面上很少有軟體是免費并且開源的，因為開源意味着軟體的開發與實作不再是秘密，将使軟體失去盈利的資本。那麼釋出開源軟體的企業希望從中擷取什麼利益呢？
我查到著名的開源軟體如下
| 軟體 | 說明 |
|---|---|
| Linux | Linux 是一款開源的作業系統，它的核心由多名極客共同維護。Linux 是開源軟體的經典之作、代表之作、巅峰之作。 |
| Apache | 世界使用排名第一的 Web 伺服器軟體。 |
| MySQL | 世界上最流行的關系型資料庫，适合中小型網站。 |
| Firefox | 火狐浏覽器。在 Chrome 推出之前，Firefox 幾乎是最快速的浏覽器，直到現在也是 Web 開發人員的調試利器。 |
| OpenOffice | 套跨平台的辦公軟體套件，類似 Microsoft Office。 |
| GCC | C語言/C++編譯器。 |
| Java、PHP、Python | 開源的程式設計語言。 |
與其相對的是私有/專屬軟體，如很多來自微軟和蘋果的軟體，很多使用者對他們的收費軟體甚至産生了依賴。支撐開源軟體的僅僅是極客的信念嗎？
問題二 第二章 好的單元測試的标準 一節，提到
單元測試必須由最熟悉代碼的人（程式的作者）來寫。代碼的作者最了解代碼的目的、特點和實作的局限性。是以，寫單元測試沒有比作者更适合的人選了。
我部分認同這個觀點，但還有一些疑惑，就是一個“寫出bug的人”是否是寫“找出bug的單元測試”的最佳人選。代碼作者對自己的代碼有很大盲區，在編造單元測試時可能仍然沒有意識到代碼中的問題，而不能篩查出bug。
通過上下文的内容，我推測單元測試隻是篩查bug的第一步，用于測試代碼的基本功能。另外一些作者找不出來的bug，留給同伴複審代碼的時候進一步找出。原文如下，
下面是驗證單元測試好壞的一系列标準：單元測試應該在最基本的功能/參數上驗證程式的正确性。單元測試應該測試程式中最基本的單元—如在C++/C#/Java中的類，在此基礎上，可以測試一些系統中最基本的功能點（這些功能點由幾個基本類組成）。
問題三 第二章 好的單元測試的标準 一節，又提到
問：如果用随機數以增加測試的真實性，好麼？
答：一般情況下不好，如果某個随機數導緻程式出錯，但是下一次運作又不能重複這一錯誤，則于事無補。我們還是要用随機數等辦法“增加測試的真實性”，但不是在單元測試中。單元測試不能解決所有問題，不必期望它會發現所有的缺陷。
根據面向對象這門課的經驗，寫一個複雜程式并送出評測（比如表達式運算），由于評測機是黑箱測試，會出現很多頑固的bug很難人為地找出來。一般會構造複雜的測試集，甚至用評測機随機生成很長的測試樣例。
我認為一個軟體在頒布給使用者使用前，也存在着很難發現的bug，如果直接推向市場廣大使用者會逐漸發現問題。根據教材，單元測試不能使用随機數，那麼很難偵測這樣的bug。我推測單元測試跟我剛才說的測試方式就是兩個都要經曆的不同的測試階段吧。
另外我覺得不用擔心随機數導緻程式出錯的無法複現，用日志記錄下出錯的樣例就可以了。那多線程程式确實有無法複現的問題，怎麼單元測試呢？
問題四 第十五章 設計變更 一節，提到了重構
重寫或重構
小飛：我們的某某子產品真是太爛了，我覺得必須重寫，而且現在又有了新的技術叫“我佩服”（WPF）[或插入任一最近時髦的技術]，它能做很酷的效果，為什麼不呢？
二柱：我們先要看看，原來爛到什麼程度，現在是否能完成功能？你所說的問題有多嚴重？是功能不能實作？或者界面有問題？或者不能擴充（例如：不能支援更多使用者）？
大栓：另外，是重構，還是重寫？重構——在盡量保持原有界面的基礎上優化部分代碼。重寫——重新實作原有功能，同時，要厘清是全部重寫原有功能，還是偷偷加上許多新的功能（Feature Sneak）？
重構的時機讓我有一點困惑。我面臨過重構的情況一般是，要求程式實作的功能增加了，原來的代碼架構很難優美地加上這個功能，是以要重新組織代碼。但重構的工作量很大，不改變代碼架構硬加上新功能也可以。有時我把握不好該重構還是将就。
我認為遇到重構是因為原來的程式沒有為拓展功能預留合适的接口，但有時未來需求是未知的，貌似預留前瞻性的接口不隻是技術，還要靠運氣。有什麼無論如何拓展都通用的預留接口的原則，以減少重構次數？
問題五 第一章 談到軟體的複雜性，
軟體可以說是人類創造的最複雜的系統類型。大型軟體（作業系統、辦公軟體、搜尋引擎）有超過百萬行的源代碼，上萬個不同的檔案。而軟體工程師通常一次隻能看到30—80行源代碼（相當于顯示器的一屏），他們的智力、記憶力和常人差不多。軟體的各個子產品之間有各種顯性或隐性的依賴關系，随着系統的成長和子產品的增多，這些關系的數量往往以幾何級數的速度增長。
閱讀百萬行級的代碼是很耗時的，參與研發的程式員都要通讀百萬行代碼嗎？超大型軟體是否也依靠分層結構，解決某個問題的程式員隻要讀完對應層次的代碼，其他層級對其是相對透明的呢？
2.請問 “軟體” 和 “軟體工程” 這些詞彙是如何出現的 - 何時、何地、何人？
In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics"[10][11] 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.[12] This led many to credit Tukey with coining the term, particularly in obituaries published that same year,[3] although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim.[13] 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.[14]
--Wikipedia
- John Tukey在1958年發表的論文"The Teaching of Concrete Mathematics"提出“software”一詞，大家普遍認為是這篇論文首次提出這個術語，但他本人沒有做出聲明。
- Paul Niquette 聲稱他在1953年10月首次提出這個術語，但是沒有找到支援檔案。
- Richard R. Carhart在1953年8月的科研備忘錄中也提出這個術語，被認為是發表物中最早出現的。
Margaret Hamilton在二十世紀六十年代，主持阿波羅登月任務的軟體程式計劃的時候提出“軟體工程”一詞。
軟體在阿波羅計劃的初期完全不像其他工程學科，例如像硬體工程那樣的受到重視，而且在大家的眼光中他像是藝術，而不是一門科學。Hamilton緻力于為軟體以及那些發明者争取應有的正統性與尊重，是以她開始使用“軟體工程”這樣的字眼來将之與硬體還有其他工程學類做出差別。
3.知道了軟體和軟體工程的起源，請問軟體工程發展的過程中有什麼你覺得有趣的冷知識和故事？
網際網路的成功，可從“Internet”這個術語的大、小寫分化窺知一二。最初，網際網路一詞代表那些使用IP協定架設而成的網絡，而今天，它已引申泛指各種類型的網絡，不再局限于IP網絡。于是以小寫的網際網路（internet，開頭的“i”是小寫字母）為任何分離的實體網絡之集合，這些網絡以一組通用的協定相連，形成邏輯上的單一網絡。而大寫的網際網路（Internet，開頭的“I”是大寫字母）專指前身為ARPA網，後使用IP協定将各種實體網絡連接配接成此單一邏輯網絡。大寫的網際網路是小寫網際網路的其中一種形式，反過來卻不然。
2002年起，有學者開始提議将“internet”一詞用小寫表示，理由是網際網路已經成為人類生活的一部分，失去了專有的意義；2016年，美聯社認為“網際網路”已和“電話”一樣成為一件一般的事物，不具有專屬商标的意義，于是開始在其格式手冊中規定“internet”和“web”一詞全部小寫，紐約時報也随後跟進，但同時亦有媒體提出不同意見。
4.上網調查一下目前流行的源程式版本管理軟體和項目管理軟體都有哪些， 各有什麼優缺點？
版本管理軟體分類
Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode
Microsoft TFS
優點：
- 任務版上能将需求、項目進度一覽無餘，對于小團隊而言，比甘特圖更有用內建了項目管理、版本控制、BUG 跟蹤。
- 能有效實作 SCRUM能與 VS 無縫接合。
缺點：
- 搭建、維護tfs比較複雜，硬體要求也比較高。
- 整個系統是用 asp 實作的，用浏覽器通路相當慢。
git
- 适合分布式開發，強調個體。
- 公共伺服器壓力和資料量都不會太大。
- 速度快、靈活。
- 任意兩個開發者之間可以很容易的解決沖突。
- 離線工作。
- 資料少（起碼中文資料很少）。
- 學習周期相對而言比較長。
- 不符合正常思維。
- 代碼保密性差，一旦開發者把整個庫克隆下來就可以完全公開所有代碼和版本資訊。
Mercurial（hg）
- 學習門檻較低。整體上看，hg需要掌握的指令要比git少很多。
- 可以一鍵完全恢複到曆史版本的某一個切面。
- 封裝好。相比git，hg很少暴露一些實作内的細節。
- 分支管理不靈活。Mercurial的branch管理和Git相比不是很友善。大型團隊不願使用。
GitHub
- 免費且開源。
- Git支援分支功能（branch）。
- 支援離線工作。本地送出可以稍後送出到伺服器上，不用和集中的代碼管理伺服器互動。 隻有最終完成的版本才需要向一個中心的集中的代碼管理伺服器送出。
- Git 送出都是原子的，且是整個項目範圍的，而不像 CVS 中一樣是對每個檔案的。
- 簡易的初始化。對于随便寫兩行代碼就要放到代碼管理工具裡的人來說，再合适不過。
- 學習成本大。由淺入深的過度很漫長，需要大量時間的投入。
- Git版本庫需要頻繁的手動維護。
bitbucket
- 送出大檔案速度很快。
- 私人項目免費。
- 不限容量。
- 不開源。
- 系統不穩定。
Trac
- 有良好的擴充性。
- 權限體系是比較完備的。
- 非常靈活，可以随心所欲的定制，可以和TortoiseSVN內建。
- 不支援多項目。
- 需求和缺陷沒有分離。
- 用 wiki 來替代 Word 等工具編寫文檔對于産品策劃來說門檻太高了。
- 中文化不完整，美術人員接觸起來困難重重。
BUGZILLA
- 不收費。
- 現在有中文版支援。
- 隻能管理缺陷。
Apple XCode
- 可以自動建立分類圖表。
- 自動提供撤消、重做和儲存功能，無需編寫任何編碼。
- 更新版本後，某個插件可能會失效。
5.嘗試使用一些版本管理工具
Git
Mercurial
使用感想
建立倉庫，送出更改等基本指令是相似的，但-option有差別；
Mercurial的指令更少；
Mercurial的分支管理相比Git不太友善。