軟工4：結對編程之代碼復審

1.題目要求

(1). 首先在同學中找一個同伴，範圍不限，可以在1~5班中隨意組合，建議盡量不要找同組的成員，女同學盡量找男同學結對，但是不做強制要求；
(2). 從以往個人完成的項目中選擇一個作品，例如：以往的數據結構課程設計或者其它具有比較完整功能的小系統，代碼至少要大於100行；
(3). 將代碼上傳至個人GitHub或Coding.net系統中，並將代碼地址交給對方；
(4). 對同伴的作品進行代碼復審，並參照C/C++代碼審查表和 Java代碼審查表 這兩篇博文的內容自行設計代碼審查表並填寫內容；
(5). 將對夥伴審查的結果以表格的形式寫到自己的博客作業裏，博客中應該附有夥伴作業的GitHub或Coding.net的代碼地址；
(6). 對同伴的代碼寫一篇500字以上的評論，介紹同伴的優缺點。

2.代碼審查表

完成此次作業參考博客:c/c++代碼審查

結對夥伴：郭金鑫

代碼地址:github

3.評價總結

• 首先我先來看下程序的運行結果：
  

• 從上面可以看到程序的運行結果是正確的，說明程序代碼本身沒有問題。再回頭來看代碼格式本身，我夥伴郭金鑫的代碼風格還是很規範的，該有的註釋也都有，因為本身代碼復審的前提是對方可以讀懂你的代碼，所以必要的註釋是必須的。普通函數正確的形式應該為聲明與定義分離，聲明就是一個函數原型，函數原型應該有一個函數名字，一個參數列表，一個返回值類型和一個分號，定義就是函數的內在，花括號內的就是函數的定義，這一點夥伴的代碼也都滿足。對於此次合作的過程還是很順暢的，上課時老師就曾教導過現在的程序員方方面面都得過關，其中就有一塊兒是與人合作，通過這次代碼復審讓我切實的體會了這一過程，與人溝通，不僅自己懂自己的代碼，需求，還得讓對方以很簡單明了的方式去讀懂。其實我更覺得完全按照編碼規格標準進行的代碼審查是一個浪費開發人員寶貴時間的方式，代碼審查的實質是確認代碼能夠正確的運行，發現安全漏洞、功能錯誤、代碼錯誤、設計失誤、安全驗證和防範、惡意代碼等，而不是單單按照編碼規範完全保證代碼格式一致，而丟失了代碼審查的實質。而這次因為我夥伴的代碼實現功能較為單一，這些其實沒有深層次的涉及到，我後續可以嘗試和他進行溝通，將代碼的實現功能設計的更復雜一些，當然，就這次他本身的需求來講，這一次完全沒有任何問題。反思我自己，平時寫代碼有時為了簡單省事，往往沒有按照規範的方式去寫，這些其實都是非常不好的習慣，為以後的進一步工作埋下了隱患，所以啊，通過這次的代碼復審，我才意識到問題的嚴重性，以後務必規範書寫代碼，增強代碼的規範性和可讀性。

軟工4 代碼復審