實踐最簡單的項目：WC
實踐是理論的基礎和驗證標準，希望讀者貫徹“做中學”的思想，動手實現下面的項目，並和別人的成績相比較，分析產生差距的原因。
1. 實現一個簡單而完整的軟件工具（源程序特徵統計程序）。
2. 進行單元測試、迴歸測試、效能測試，在實現上述程序的過程中使用相關的工具。
3. 進行個人軟件過程（PSP）的實踐，逐步記錄自己在每個軟件工程環節花費的時間。
4. 使用源代碼管理系統 (GitHub, Coding.net, 等)； 並使用項目管理系統，練習使用其中的事件跟蹤功能（選用TFS，Bugzilla 或者Trac， 等工具，瞭解其原理）。
5. 進行最簡單的項目管理系統的定製，這個留給一部分能力較強的同學參與。（選用TFS 或別的項目管理系統，瞭解原理並實現定製。）
1 WC 項目要求
wc.exe 是一個常見的工具，它能統計文本文件的字符數、單詞數和行數。這個項目要求寫一個命令行程序，模仿已有wc.exe 的功能，並加以擴充，給出某程序設計語言源文件的字符數、
單詞數和行數。當然，我們假設讀者都已經通過之前的練習，建立了源代碼控制工具並有基本的實踐經歷。
實現一個統計程序，它能正確統計程序文件中的字符數、單詞數、行數，以及還具備其他擴展功能，並能夠快速地處理多個文件。
具體功能要求：
程序處理用戶需求的模式爲：
wc.exe [parameter] [file_name]
基本功能列表：
wc.exe -c file.c //返回文件 file.c 的字符數
wc.exe -w file.c //返回文件 file.c 的詞的數目
wc.exe -l file.c //返回文件 file.c 的行數
擴展功能：
-s 遞歸處理目錄下符合條件的文件。
-a 返回更復雜的數據（代碼行 / 空行 / 註釋行）。
-f 說明這個文件是哪一種語言的。 例如： C/Java/C++/JavaScript/Python/HTML, 如果看不出屬於任何語言， 就輸出 TXT
空行：本行全部是空格或格式控制字符，如果包括代碼，則只有不超過一個可顯示的字符，例如“{”。
代碼行：本行包括多於一個字符的代碼。
註釋行：本行不是代碼行，並且本行包括註釋。一個有趣的例子是有些程序員會在單字符後面加註釋：
} //註釋
在這種情況下，這一行屬於註釋行。
[file_name]: 文件或目錄名，可以處理一般通配符。
高級功能：
-x 參數。這個參數單獨使用。如果命令行有這個參數，則程序會顯示圖形界面，用戶可以通
過界面選取單個文件，程序就會顯示文件的字符數、行數等全部統計信息。
需求舉例：
wc.exe -s -a *.c
返回當前目錄及子目錄中所有*.c 文件的代碼行數、空行數、註釋行數。
2. 工作的細分
正如諺語所說：不能一口吃成個胖子。羅馬不是一天建成的。同樣，一個功能完備的程序也不是一蹴而就的。在這裏，我們討論如何把大任務劃分爲可操作的小任務，以及任務的次序。
讀完項目的要求後，首先請估計完成整個項目需要多少時間？把估計記下來，並且寫成PSP 的形式。其次，如何逐步分解一個項目的需求？在這個項目中，各種需求已經通過各種參數表達得比較清楚了。
基本功能
擴展功能
高級功能
詳細地瞭解了需求後，我們再估計需要的時間並記錄 [ 估計值2]。
最後，列出各類功能下面的詳細需求。
基本功能
支持 -c
支持 -w
支持 -l
擴展功能
支持 -s -f -a 參數
支持各種文件的通配符（*,?）
高級功能
基本的Windows GUI 程序操作
支持通過圖形界面選取文件
支持通過圖形界面展現文件的信息
請在這個時候把每一個詳細功能所需的時間列出來，然後再把它們相加，得到 [ 估計值 3]。
同學相互之間比較估計值1、估計值2 和估計值3，看看差距是多少，有什麼規律？對此有興趣的同學請參看本書第8 章“計劃和估計”一節。
3 如何保證質量— 迴歸測試
如何保證在加入新功能的過程中，已有的功能可繼續工作？這就要求我們有一套標準的測試來保證基本功能的正確性。
寫這樣的程序，用項目本身的源文件來做測試應該是比較酷的，但是源文件本身在不斷地變動，並不是一個很好的測試樣本，我們要建立起一系列測試文件。如下：
空文件
只有一個字符的文件
只有一個詞的文件
只有一行的文件
一個典型的 C 語言源文件
一個典型的 Java 語言源文件
一個典型的 HTML 語言源文件
一個典型的 C# 語言源文件
一個典型的 JavaScript 語言源文件
如何爲這個程序做有效的測試，有以下幾種方法，自動化程度由低到高。
1. 手動測試，手工比較。
2. 要做到不斷地測試，可以把WC 的主要功能封裝成一個類，然後測試程序調用這一個類的主要函數，得出結果並與標準作比較。
3. 更進一步，把測試文件和正確的測試結果保存在文件中，測試驅動程序只要比較測試的輸出和標準結果就能得出答案。
4. 再進一步，把自動構建腳本和構建驗證測試（Build Verification Test）結合起來。每一次構建之後，就自動運行測試，然後記錄出現的Bug。
瞭解測試的需求後，每人估計需要的時間並記錄 [估計值4]。
4 標準測試集，正確性和速度評比
既然大家的程序都寫得差不多了，那就拉出來遛遛，看看是騾子是馬。以子目錄的形式把目前所有同學的程序都集中在一個總的測試目錄下，作爲測試集合。然後大家看看各自的程序要花
多少時間才能正確並且較快地完成任務。 在這裏，同學們要記下滿足了標準測試集之後，每人實際花費的時間 [ 實際值]，並且按照本章PSP 的表格統計自己在軟件開發的各個階段所花費的時間。
5 擴展，從源代碼服務器上讀文件
請看這個文章，你能實現類似的功能麼？ https://www.ybrikman.com/writing/2018/08/12/the-10-to-1-rule-of-writing-and-programming/