初啓（軟件工程第一次閱讀做業）

1. 快速看完整部教材，列出你仍然不懂的5到10個問題，發佈在你的我的博客上。

2.1.2 「單元測試必須由最熟悉代碼的人（程序的做者）來寫

      並不認同這裏這個「必須」。在我自身實習的經驗中，通常都會採用開發和測試分離的模式，即你們在構思設計的時候約定好公共的接口模式，而後並行開始開發和測試程序的構建，你們公共的部分就是統一的接口，測試人員不須要知道內部的實現細節，並且根據接口來構造一系列的強覆蓋邏輯，保證接口對正常功能和異常功能都能正確處理。這樣作一提升了效率，二是測試不會被開發的設計思路所束縛，徹底從一個外部的角度來思考，這樣設計測試樣例通常會更全面。
 　  不過寫到此處想到另外一個問題：徹底不瞭解內部細節，那可能會出現覆蓋不到接口內部分邏輯的狀況，有可能有隱藏的分支並無覆蓋到，留下了隱患。還有就是接口內部一些可能產生的反作用也不能及時發現，這的確也是存在的問題。

10.3 規格說明書

     關於規格說明書我有一個一直以來的疑問，就是規格說明書-註釋-代碼之間的聯繫和配合，嚴格來講，他們之間有不少重複的內容，好的代碼風格自己就有必定的說明做用，註釋是程序員最好的助手，文檔又是真正開發不可或缺的一部分，如何構建一種最合適的模式，使得每一個層次都有合理的功能而有不冗餘呢。

16.1.5 迷思之五: 要成爲領域的專家，才能創新

      在目前的環境下，僅僅成爲領域的專家，彷佛並不太足夠了。在各行各業都高度專業化的今天，各個行業領域之間的壁壘也愈來愈重，不少領域的專家每每會不知不覺地侷限於本身的領域，因此說，領域專家只是一個創新的必要條件。那麼在如今的環境下，交叉學科彷佛正在成爲新興的創新爆發點，借鑑其餘學科的思路的觀點，結合本領域的知識，將會產生更多的可能。深度學習中的不少優秀設計即是來源於神經科學，好比神經元的基本模型，還有生物學，好比借鑑人的視網膜細胞來組織新的卷積層，結合大腦的計算模式來構建新的高度並行化的神經網絡芯片。

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

軟件： 這個詞是在1958年，由John Tukey在其論文"The Teaching of Concrete Mathematics"中提出的

Tukey's 1958 paper "The Teaching of Concrete Mathematics"^[10] contained the earliest known usage of the term "software" 

軟件工程： 這個詞是在1969 年（阿波羅 11 號期間），由Margaret Hamiltion提出的

 

Ｑ：你是在這段期間發明了「軟件工程」一詞嗎？

Ａ：軟件在這個計劃的初期還被看成初初學步的孩子通常對待，徹底不像其餘工程學科；例如像硬件工程那樣的受到重視，並且在你們的眼光中他就像是藝術、魔術通常，而不是一門科學。

我一直以來堅信這項發明流着藝術與科學的血液，雖然當時不多人是這麼想。所以，我致力於爲軟件以及那些發明者爭取應有的正統性與尊重，因此我開始使用「軟件工程」這樣的字眼來將之與硬件還有其餘工程學類作出區別。

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

1. 豐田的一萬多個全局變量的故事。28萬行代碼中有1萬多個全局變量，簡直就是bug培養基。
   其中還有人專門作過測試。
   軟件設計的基本要求是模塊儘可能簡單化，由於這樣能夠一來更易於閱讀二來更易於維護，但豐田的工程師顯然沒有遵循這原則。Barr使用一種工具自動根據代碼的可能分支數量評估函數的複雜度，結果是豐田的軟件中至少有67條函數複雜度超過50，意味着運行這個函數可能出現超過50種不一樣的執行結果，屬於「非可測」級別。由於爲了測試這50個不一樣的結果，必須準備至少50條不一樣的測試用例以及相應的文檔，在生產環境中是根本不現實的。而在這67條函數中還有12條複雜度超過100，達到「非可維護」級別，意味着一旦發現缺陷（Bug）也沒法修復，由於實在太複雜，修復缺陷的過程當中會產生新的缺陷。其中最複雜的一條函數有超過1300行代碼，146個可能執行路徑——正好用於根據各傳感器數值計算節氣門開關角度。
   

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

下表是2018年源代碼託管軟件的用戶數和項目數，出自https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities#Popularity

從中能夠看到通常最熟悉的git(github,gitlab)仍是佔據了最主要的部分，下面是幾大主流軟件的優缺點對比。

Git

優勢：

• 免費且開源。
• Git支持分支功能（branch）。若是開發一個新的產品功能，能夠創建一個分支，對這個分支的進行修改，而不至於會影響到主支上的代碼。或者是fork。
• 可拿Git作備份系統，或者同步多臺機器的文檔，很方便。
• 支持離線工做，有本地倉庫和遠程倉庫。本地提交能夠稍後提交到服務器上，不用和集中的代碼管理服務器交互。 只有最終完成的版本才須要向一箇中心的集中的代碼管理服務器提交。
• Git 提交都是原子的，且是整個項目範圍的。
• Git 中的每一個工做樹都包含一個具備完整項目歷史的倉庫，還原和版本回退很是方便。
• P.S. 推廣一下本身寫的git簡易教程 https://github.com/OO-guide-2019/git-guide

缺點：

• 學習成本大。由淺入深的過分很漫長，須要大量時間的投入。(有合適的教程其實很快）
• Git版本庫須要頻繁的手動維護。

SVN

優勢：

• 對目錄的組織的管理更加方便。SVN不光對文件作版本跟蹤，也會對目錄作版本跟蹤。所以能夠根據項目的須要，對目錄結構隨時進行修改，能夠把現有的目錄移動到新的地方。
• 保證提交操做的完整性。SVN對提交操做的處理方式相似數據庫的事務處理，要麼所有成功，要麼所有無效，保證了原子性。
• SVN容許一個文件有任意多的可命名屬性，功能十分徹底。

缺點：

• 不能離線工做。全部的版本信息都放在服務器上。若是脫離了服務器，開發者基本上能夠說是沒法工做的。
• 提交、更新、瀏覽歷史的速度慢。耗費CPU資源。
• 代碼不能及時提交。強迫使用者即時處理衝突，而後才能提交。
• 不能恢復到歷史版本。SVN記錄了單個文件的歷史版本，但沒有記錄全局版本，不能恢復到上次的狀態。這一點是很致命的。

Microsoft TFS

優勢：

• 任務版上能將需求、項目進度盡收眼底，集成了項目管理、版本控制、BUG 跟蹤。
• 能有效實現 SCRUM，能與 VS 無縫接合。

缺點：

• 搭建、維護tfs比較複雜，硬件要求也比較高。
• 整個系統是用 asp 實現的，用瀏覽器訪問較慢。

Mercurial

優勢：

• 學習門檻較低。總體上看，hg須要掌握的命令要比git少不少。
• 能夠一鍵徹底恢復到某一個歷史版本。
• 封裝好。相比git，hg不多暴露一些實現內的細節。
• 照顧 svn 的遷移用戶。hg 的不少命令是遷移自 svn 命令的，習慣 svn 命令的團隊，幾乎能夠零成本的切換到 hg。
• hg的版本庫不須要維護。

缺點：

• 分支管理不靈活。Mercurial的branch管理和Git相比不是很方便。不適合大型團隊使用。

5.關於版本控制軟件的我的理解

目的：版本控制軟件的目的主要是兩點，版本記錄控制，團隊協做

從使用者角度來看，一款好的版本控制軟件須要知足以下的需求：

•  簡單易學易上手，這一點須要創建在軟件自己指令的設計，與操做系統shell命令的結合，詳細但又不囉嗦的教程，以及面向真正開發需求的實踐練習。就拿git來講，不少入門者以爲痛苦的一個重要因素就是其對基本shell命令本就不太熟悉，對於命令行式開發和運維相關熟練度遠遠不夠，而同時目前的教程更像是一部工具說明書，即以各個命令自己爲基本單元，而不是git工做的整個流程，因此就會帶來一種割裂感，此外，沒有真正意義上的對於整個git協同開發的練習，單單看教程記憶天然不能熟練掌握（因此也就有那麼多人吐槽git學起來難）
• 支持強大的版本控制操做，對我的來講，主要的需求有兩點，一是不一樣版本路線的開發，即多個branch的開發，每一個branch負責一種設計思路，二是可以方便的回退到某個版本，換句話說就是強大的存檔讀檔功能，而對團隊來講，協做就是最重要的點，以git爲例，在團隊開發時以fork爲主，每一個人的修改要想整合進來必須通過pull request，這樣的機制就使得每一個人能夠各司其職，減小了形成衝突的可能性。就算是在一個分支中出現了merge時的衝突，git也提供了良好的衝突處理機制，更有git rebase這種高級操做，使得處理起來很是方便。
• 支持網頁查看，對於閱讀源代碼和配置文件，不必定須要笨重地每次都clone到本地倉庫一份，像github和gitlab提供的網頁界面閱讀代碼，使得這個過程變的很是輕便。
• 對於大文件的管理，在開發大型項目的時候，咱們可能會生成一些幾十甚至幾百MB級別以上的文件，那麼像基本的github就不支持這樣的大文件傳輸，但有的時候咱們確實須要將其託管在遠程倉庫進行管理，這時，像git-lfs這樣的工具即可以提供很是溫馨的體驗（強烈推薦）

從版本控制軟件設計者來看，其須要考慮的因素以下：

• 對功能的封裝，解耦合（抱歉我是git吹），考慮一個項目內，可能有正在編輯的文件，可能有已經編輯好的文件，可能有遠程服務器上的文件，若是一視同仁，其實會很是混亂，可是像git這樣的設計，工做區，暫存區，本地倉庫，遠程倉庫，將複雜的事情解耦成爲幾個不一樣的階段，就很是清楚。
• 面向安全的封裝，對於內部的具體實現，是否暴露給用戶，這一點須要考慮，暴露給用戶的話能夠支持更多的開發者，可是也帶來了必定程度上的安全風險
• CPU等本地硬件資源的消耗和傳輸速度保證，好比你們均可以發現，git clone/pull/push都是使用多線程來操做的，如何利用好本地硬件資源且不帶來過分的負擔，也須要認真考慮
• 本地和服務器的關係，通常來講咱們但願本地能夠直接工做，斷網時也能夠本地版本控制，另外一方面，服務器上也能夠進行修改，不依賴本地。不過如今網絡傳輸基本不會出現什麼問題。
• 圖形化界面，多是由於基本使用命令行的緣故，因此git的GUI十分醜陋。。。
• 數據的分析和統計，在github和gitlab有不少對於項目開發狀況的可視化數據統計，這對於一個團隊的開發也是很棒的信息。