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

四.審查代碼總結及評價
審查完秦彬同學的代碼，我發現還有很多瑕疵之處，對此我總結了以下10個寫代碼的技巧。

1.百家之長歸我所有

??其實寫代碼的方式有很多，每個人都有自己的風格，但是眾多的風格中總有一些共性的、基本的寫代碼的風格，如為程序寫註釋、代碼對齊，等等。是不是編程規範？對就是編程規範。

2、取個好名字

??取個好的函數名、變量名，最好按照一定的規則起名。還是編程規範。

3、淩波微步，未必摔跤

??這裏我用“淩波微步”來形容goto語句。通常，goto語句使程序跳來跳去，不容易讀，而且不能優化，但是在某種情況下，goto語句反而可以增強程序的可讀性。Just go ahead，not go back。

4、先發制人，後發制於人
??Defensive Coding指一些可能會出錯的情況，如變量的初始化等，要考慮到出現錯誤情況下的處理策略。測試時要多運行幾個線程。有些程序在一個線城下運行是正常的，但是在多個線程並行運行時就會出現問題；而有些程序在一個CPU運行幾個線程是正常的，但是在多個CPU下運行時就會出現問題，因為單CPU運行線程只是狹義的並行，多CPU一起運行程序，才是真正的並行運算。

5、見招拆招，滴水不漏

??這裏的Error Case（錯誤情況），是指那些不易重視的錯誤。如果不對Error Case進行處理，程序在多數情況下不會出錯，但是一旦出現異常，程序就會崩潰。

6、熟習劍法刀術，所向無敵

??用“劍法刀術”來形容一些API是因為它們都是經過了很多優秀開發人員的不斷開發、測試，其效率很高，而且簡潔易懂，希望大家能掌握它，熟悉它，使用它。是不是象我們的ULIB。

7、雙手互搏，無堅不摧

??這裏的測試不是指別人來測試你的代碼，而是指自己去測試。因為你是寫代碼的原作者，對代碼的了解最深，別人不可能比你更了解，所以你自己在測試時，可以很好地去測試哪些邊界條件，以及一些意向不到的情況。

8、活用斷言

??斷言（assertion）是個很好的調試工具和方法，希望大家能多用斷言，但是並不是所有的情況下都可以用到斷言。有些情況使用斷言反而不合適。

9、草木皆兵，不可大意
??是指在寫代碼時，要小心一些輸入的情況，比如輸入文件、TCP的sockets、函數的參數等等，不要認為使用我們的API的用戶都知道什麽是正確的、什麽是錯的，也就是說一定要考慮到對外接口的出錯處理問題。

10、最高境界、無招勝有招

??意思就是說盡量避免寫太多的代碼，寫的越多，出錯的機會也越多。最好能重用別人開放的接口函數或直接調用別人的api。

??因此在以後的代碼學習和編譯過程中，我應該努力讓自己的代碼更加簡潔，規範，思路清晰，不冗雜，不出錯。給人留下清新的第一印象。

軟件工程（2018）結對編程第一次作業