軟件工程做業 - word count

(編程和軟件工程做業系列)

實踐最簡單的項目：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]。

同窗相互之間比較估計值一、估計值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/