《構建之法》上對**複審的定義是：看**是否在「**規範」的框架內正確地解決了問題。**複審可以檢查大家對**規範的執**況，發現**中的一些問題，提高**的質量，所以我們安排了小組成員互相進行**複審。
**複審需要檢查對**規範的執**況，所以我們先要有明確的**規範。**規範其實應當在**編寫前就確定下來，但是我們因為一些原因直到複審開始前才制定出用於本組的**規範，這也導致了我們進行**複審時發現的問題比較多。我們小組使用的語言是微軟公司的c#，微軟官方有相應的文件，但是不夠詳細。而對於coding平台提供的自動檢查功能，我又找不到其所使用的規範的具體內容，故無法採用。最後我在網上查詢了其它文件，參考了這篇文章，制定了本小組的**規範。
而小組的其他成員對這份規範的第一反應是：看不懂。的確，我們剛剛接觸c#，規範中提到的許多語法特性我們並不知道，也沒有在專案中使用。而一些設計方面的東西，由於我們的專案規模不大，我們也沒有涉及這方面的內容。這份應該是來自企業的文件，在我們看來是又長又難懂。經過討論，我們決定結合本小組的實際情況，只對這份規範的一部分進行複審，並且委託小組成員根據規範內容做出了乙份簡單明瞭的複審**，供複審時對照。
我負責進行複審的**是playercontrol類中他人編寫的部分。根據**規範，我作出了相應的複審報告。這份**的問題主要違反了以下兩點：
每行**和注釋不要超過70個字元或螢幕的寬度,超過則應換行,換行後的**應該縮排乙個tab.
除了 for 迴圈外,宣告要放在塊的最開始部分.
對於第一點，**編寫者的反饋是對應的**並沒有超出他電腦上的螢幕寬度，然而在我的電腦上是沒法在一行顯示的。這體現了我們選擇的**規範本身有不嚴謹的地方，螢幕寬度並沒有具體的量化標準。我們討論後覺得這個問題也不是特別嚴重，所以沒有修改規範的內容，只是相互溝通處理。
對於第二點，規範上的這條規定跟我們平常的習慣並不符合。變數宣告集中在開頭的確顯得整齊，然而拉長了**的長度，宣告與使用的距離比較遠，編寫的時候並不方便。而在使用時宣告則更符合思維習慣，可以對變數按照方法內的功能邏輯部分進行集中。**規範也有著方便小組成員交流的目的，我們在這方面的習慣比較一致，覺得沒有必要改變，而且unity官方的示例也沒有將宣告集中在開頭。所以經過討論，我們決定從**規範中刪除這一項內容。
第一輪複審後，我們根據複審報告對**進行修改，直到完全符合**規範。
經過這次**複審的實戰，我有了一些新的體會。以前編寫**幾乎就是自己乙個人寫給自己看，寫完之後如果表現得正常甚至自己都不會看第二遍。而在團隊中，我們要遵循同樣的規範，不能隨心所欲，要考慮到其他人也能看懂，所以變數名也變得講究，注釋也寫得多起來了，這樣團隊成員才能更好地溝通。複審時對同伴逐行地解釋自己所寫的**，自己的確也發現了編碼時沒注意到的問題，這對與提公升**的質量很有幫助。
第七周作業作業
1 自建yum倉庫，分別為網路源和本地源 建立yum配置檔案，類似如下 base name base baseurl file misc cd gpgcheck 0 epel name epel baseurl gpgcheck 0 enabled 1 本地源 以前自己整理的 2 編譯安裝http2...
第七周作業
書中習題1 說說下列程式的執行過程和運算結果 include includeusing namespace std double squ double x 函式原形 int main 主函式 書2,不用庫函式,求整數次冪 3.程式設計實現輸入兩個4x5矩陣和5x3矩陣，定義函式並在主函式中呼叫計算它...
第七周作業
1 列舉常見的核心引數以及引數的意義 1 net.ipv4.ip forward 資料報的路由 開關，設定為1表示開啟，0表示關閉。2 vm.drop caches 清空caches，釋放記憶體占用。設定為1表示清空 pagecache，設定為2表示清空 dentries 和 inodes，設定為3...