作業要求【
1.版本控制
最初並不能理解版本控制的實際作用，覺得操作上也存在著很複雜的過程，一次版本控制要花費需對時間去建倉庫上傳**等等，但是經歷過一次更改了的**找不到之後發現，尋找以及重新編譯所花的時間比版本控制要多得多。也慢慢養成了版本控制的習慣，更有助於**的儲存與修改。
2.**規範
當我們進行結對程式設計以及團隊程式設計時，會發現每個人的程式設計習慣都是不同的，這樣一來最後總和的**會出現許多不同的變數名，每個人還都要花費大量的時間去修改和統一，造成**混亂無法執行等結果，通過軟體工程我們學會了**規範，發現了這樣能給我們節省很對不必要的麻煩和重複。根據個人習慣寫出來的**無法進行統一，而根據大家的習慣制定了統一的命名規則之後，起到了事半功倍的效果。
3.單元測試
最初完全不懂如何操作單元測試，在網上找了許多才看懂如何進行單元測試，使用過後發現了單元測試的方便之處，可以讓我們快速發現哪個模組存在問題，可以直接對部分函式進行檢測，並對症下藥，使用起來十分方便。
4.站立會議
在一周每天一次的站立會議之中，我們可以進行討論昨天的進度，以及無法獨自解決，需要大家一起**的問題，在大家一起的討論下很多事情可以起到事半功倍的效果。而且，站立的確可以讓我們提高效率。
5.需求分析
乙個明確的需求分析可以幫助我們了解客戶需要的所有要求，從而確定系統應該做什麼，乙份完整的需求分析，能夠更加準確地完成好客戶需要的專案。
附加作業 軟體工程原則的應用例項分析
此作業要求 spec原則 之前在完成詞頻統計作業的時候不了解spec，沒有應用命令列引數以及重定向完成任務，而是使用了控制台輸入的方法，這導致我在四個功能的實現中都只拿到了0分。如果我當初能遵循spec現在也許就不需要寫這篇部落格了。版本控制 在完成四則運算作業的過程中有一次使用git時由於操作失誤...
軟體工程原則的應用例項分析
此作業要求參見 1.效能分析 在詞頻統計的作業中，我首次接觸到了效能分析這個概念。從前提到優化，也只能憑藉自己對 的了解大概 一下耗時最多的是什麼函式，這種做法既不專業，也顯得低能。在 構建之法 中，提到了兩種分析方法 抽樣和 注入。在作業中，我初次使用效能分析工具，找到了耗時最多的三個函式，通過去...
軟體工程原則的應用例項分析
此作業要求參考 在本學期中，應用到了哪些軟體工程原則 規範 雖然計算機只關心編譯生成的機器碼，但是在團隊裡工作，規範很重要。在進行結對程式設計時，我和我的同伴一起制定了 的風格規範等，這樣兩個人共同編寫的 遵從共同的規範，在後面再回顧時，結構清晰，可以方便閱讀和理解。敏捷開發流程 敏捷流程強調盡早並...