一、代碼規範
我認為我們編寫的代碼都需要進行規範的操作，因為如果為了圖省事情或者為了減少時間去完成這個程式設計。在最後檢驗的時候就會出現一些警告，導緻你這次程式設計的代碼出現問題，當出現問題的時候你在回頭去檢查你的代碼，是一件非常頭痛的事情，這樣會讓你很難發現問題所在，導緻需要用很長時間去調試這個代碼，甚至會讓你前功盡棄，需要從新對代碼進行程式設計。換句話說，這就好像我們在生活中洗菜做飯一樣，在你洗菜的時候如果不仔細一些把它洗幹淨，那麼在你吃的時候就會生病，導緻你花費更長的時間去為你當初的不仔細和省時間付出代價。
1.不同意！對于這個觀點就像我剛才說的一樣，如果你在程式設計的時候不規範自己的代碼，那麼在後續過程中如果出現問題，就會導緻你從頭再來，這樣會浪費更多時間，更加影響你的開發效率，是以還不如從開始程式設計的時候就規範自己的代碼，這樣在後續的過程中如果出現了問題，那麼你也好檢查自己的代碼那裡出現了錯誤，更好的修改，會節約時間，增加你的開發效率。
2.不同意！因為規範是對所有人而言的，這個所謂的程式設計規範就相當于咱們生活當中的規矩一樣，如果每個人都有自己的規矩，按照自己的規矩去做事的話，那麼這個世界就亂了。是以我們都要一起去遵守一種規矩。這樣友善大家去評判，也友善自己去找到自身的缺點。
3.不同意！規範就是規範，不允許有例外産生。如果你的規範允許有例外産生，那麼别人的規範也允許有例外産生，那麼它就無法稱之為一個規範了，跟沒有規範是一樣的。是以我們都要遵守一樣的規範，更不允許有例外産生，它對每個人都是一樣的。
4.不同意！因為規範是已經制定好而且被大家公認的一種東西，并不是誰可以改變或者制定的，是以我們要去遵守它，而不是改變或者制定它。當我們都去遵守它的時候，那麼當别人檢視你的代碼或者幫你檢查代碼的人就會更加友善，不會導緻檢查的人浪費更多的時間在你代碼的格式上，會更專注與你的代碼含義，這樣才更有意義。
二、代碼複審
我的代碼複審的同伴是杜堯，首先在接到這個任務的時候，還是相比比較開心的，因為我們是一個宿舍的。他當時在制作這個四則運算的時候我幫過他改進自己的代碼。對他這個四則運算的程式還是比較了解，當再一次看到他制作好的完整的代碼的時候，我覺得比之前在調試的時候已經好很多了。我把他的代碼放到VS裡進行了運作，可以正常運作并顯示結果，我覺得他的這個程式中也有需要我學習的地方，比如在rand()函數前 加上 srand(time(NULL));語句，且頭檔案中加上#include<time.h>。這樣就可以讓他的數字進行随機改變。我覺得他的代碼制作的還是不錯的，隻是使用的是C語言，偏簡單一些，希望他以後可以有一些提高。
三、PSP幾率個人項目耗時情況
| PSP2.1 | Personal Software Process Stages | Time |
| Planning | 計劃 | 20min |
| Estimate | 估計這個任務需要多長時間 | 4h |
| Development | 開發 | 10min |
| Analysis | 需求分析 | 30min |
| Design Spec | 生成設計文檔 | |
| Design Review | 設計複審 | 15min |
| Coding Standard | 代碼規範 | |
| Design | 具體設計 | 2h |
| Coding | 具體編碼 | |
| Code Review | 代碼複審 | |
| Test | 測試 | |
| Reporting | 報告 | |
| Postmortem&Report | 總結和報告 |