(https://github.com/awfsgdf/coyg)git
Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|
計劃 | 60 | 60 |
· 估計這個任務須要多少時間 | 60 | 60 |
開發 | 1000 | 1810 |
· 需求分析 (包括學習新技術) | 300 | 60 |
· 生成設計文檔 | 60 | 30 |
· 設計複審 (和同事審覈設計文檔) | 60 | 30 |
· 代碼規範 (爲目前的開發制定合適的規範) | 60 | 10 |
· 具體設計 | 60 | 240 |
· 具體編碼 | 1000 | 1080 |
· 代碼複審 | 60 | 60 |
· 測試(自我測試,修改代碼,提交修改) | 200 | 300 |
報告 | 220 | 180 |
· 測試報告 | 100 | 60 |
· 計算工做量 | 60 | 60 |
· 過後總結, 並提出過程改進計劃 | 60 | 60 |
合計 | 3240 | 4100 |
1.信息隱藏:類屬性私有,被調用方法共有
2.接口設計:單詞鏈計算功能獨立
3.鬆耦合:核心能夠單獨調用github
先把以a-z開頭的單詞分別存在26個向量中,把以a-z結尾的單詞分別存在26個向量中,以這52個向量來保存圖的信息,而後根據圖的信息和輸入的參數計算出能夠做爲遍歷開始的點的集合,而後依次以這個集合裏的點做爲DFS的起點,進行深度優先搜索。編程
在沒有環的圖中,因爲圖的結構比較簡單,我認爲爆搜所有路徑是一種奢侈,因而採用了相似剪枝的方法,省去了大量確定得不到最長路徑的遍歷,運行時間比較短。在有環的途中,無奈本人學藝不精,找不到更高效的方法,只能DFS爆搜,可是我發現個人爆搜過程嚴重超時,通過分析和比對,我發現個人DFS的特別之處在於它傳入的無用的參數太多了,因而我把一些變量設置爲全局變量,不在做爲參數傳入,這樣修改以後跑同一份代碼的時間居然縮短爲原來的十分之一!(從十分鐘到一分鐘)由此我瞭解到,函數傳入的參數過多確實會嚴重影響運行效率。數組
優勢:契約式設計可以使設計更加優秀;
缺點:耗時較大;函數
單元測試獲得的測試覆蓋率截圖
oop
異常處理函數 功能
void check_h_and_t(char head, char tail, bool have_head, bool have_tail); 檢查是否存在head開頭和tail結尾的單詞
void check_file(); 檢查輸入單詞文件的路徑是否正確
void check_loop(bool enable_loop, int size); 檢查輸入的單詞集合有無環是否和-r參數匹配
void check_null(char word); 檢查傳入的char word[]裏是否有空指針
void check_char(int i); 檢查傳入的單詞列表裏是否都是英文單詞
void check_void(int len); 輸入的單詞列表的單詞數量是否小於2
void check_2(); 檢查搜索到的單詞列表裏的單詞數量是否小於2
void check_same(); 檢查輸入的單詞列表中是否有重複的單詞
int find_arg(int argc, char *argv[], arg &w, arg &c, arg &h, arg &t, arg &r, char &head, char &tail); 檢查傳入的參數組合是否出錯,若是出錯,以int形式返回錯誤的類型以便分狀況報錯
十)界面模塊(若是沒有實現GUI,則能夠描述命令行模塊)的詳細設計過程。
參數的定義和做業要求一致,當參數輸入不符合邏輯時會報相應錯誤,例如-w和-c同時出現,或者-t參數錯誤等等。性能
先分開寫了一部分代碼和gui,而後在封裝測試等部分
單元測試
優勢:
1.能夠相互學習,不斷提升
2.能夠相互督促,快速完成
3.能夠一塊兒把控,提升代碼質量
缺點:
容易引發矛盾和爭執學習
我我的的優勢:
1.認真好學
2.積極交流
3.有耐心測試
我的缺點:
懶
個人結對對象優勢:
1.代碼能力強
2.很肝
3.善於思考
缺點: 急躁