此作業要求參見：
1. 效能分析
在詞頻統計的作業中，我首次接觸到了效能分析這個概念。從前提到優化，也只能憑藉自己對**的了解大概**一下耗時最多的是什麼函式，這種做法既不專業，也顯得低能。在《構建之法》中，提到了兩種分析方法：抽樣和**注入。在作業中，我初次使用效能分析工具，找到了耗時最多的三個函式，通過去掉不必要的 print和 調整 i/o 操作來優化函式，讓程式跑的快了一些。
2. **規範
**規範包括：**風格規範和**設計規範。在本科階段的合作程式設計中，由於專業課都是乙個老師教的，所以同學們的程式設計習慣大體類似（與老師上課時程式設計的習慣類似），並沒有體會到**規範的重要性。在結對程式設計四則運算作業中，由於我和隊友的程式設計習慣以及擅長的語言十分不同，所以**規範就起到了十分重要的作用。縮排上的問題到還好，但是在括號，分行，命名和注釋方面，我們就要嚴格執行當初一起制定的**規範，增強了程式的可讀性也提高了編碼效率。整個過程中，我感覺到**規範就是一種契約精神，兩人一起制定也就要共同遵守，共同避免掉很多細節中的麻煩。兩人結對程式設計尚且如此，多人開發中更要注重**規範的制定和實施。
3. 從spec 到實現
在詞頻統計作業中，spec 由老師制定，實現四個功能。我在編碼時為了方便快捷，把四種功能寫為了四種模式，使用者需要輸入模式選擇從而進行單詞頻測。但是spec中並沒有要求有模式選擇的步驟，也就是說使用者不會進行模式選擇，所以整個功能就是沒有按照 spec 的要求，結果四個功能都得了0分。所以在以後的工程專案中，作為程式設計師一定不能私自違背 spec 而進行開發，要嚴格符合spec的要求。
4. 敏捷開發
在小組開發的作業中，老師要求小組成員每天都開站立會議，討論昨天做了什麼，今天要做什麼，以及遇到了哪些問題。起先也覺得很無聊和沒必要，但是在執行中，我們會討論每個人的任務究竟是什麼，每個人在開發過程中都遇到了哪些困難，困難如何解決，完成這個任務還需要多少時間，有哪些任務還沒有完成，並且更新每天的任務燃盡圖。通過每天的迭代，我們的小專案從0行**到完成冒煙測試，再到每個功能的完善，每日立會的記錄使每天的工作更加高效，並且可以考核。
5. 版本控制
在入學之前，我和同學之間互傳**依舊使用qq和行動硬碟（我承認我們是原始人），上這門課之後才接觸到版本控制工具。老師要求用 git，後來偷懶使用了 烏龜git。在詞頻統計和結對程式設計中，我都不太理解版本控制的必要性。但是在小組開發中，人數一多，其優勢就明顯突現出來。每個成員上傳的**其他成員可以自行分享，避免掉合作開發中的很多麻煩。版本控制會伴隨我的一生。
軟體工程原則的應用例項分析
此作業要求參考 在本學期中，應用到了哪些軟體工程原則 規範 雖然計算機只關心編譯生成的機器碼，但是在團隊裡工作，規範很重要。在進行結對程式設計時，我和我的同伴一起制定了 的風格規範等，這樣兩個人共同編寫的 遵從共同的規範，在後面再回顧時，結構清晰，可以方便閱讀和理解。敏捷開發流程 敏捷流程強調盡早並...
附加作業 軟體工程原則的應用例項分析
作業要求 1.版本控制 最初並不能理解版本控制的實際作用，覺得操作上也存在著很複雜的過程，一次版本控制要花費需對時間去建倉庫上傳 等等，但是經歷過一次更改了的 找不到之後發現，尋找以及重新編譯所花的時間比版本控制要多得多。也慢慢養成了版本控制的習慣，更有助於 的儲存與修改。2.規範 當我們進行結對程...
附加作業 軟體工程原則的應用例項分析
此作業要求 spec原則 之前在完成詞頻統計作業的時候不了解spec，沒有應用命令列引數以及重定向完成任務，而是使用了控制台輸入的方法，這導致我在四個功能的實現中都只拿到了0分。如果我當初能遵循spec現在也許就不需要寫這篇部落格了。版本控制 在完成四則運算作業的過程中有一次使用git時由於操作失誤...