李洋同學的部落格位址：
內容
魏一人
李洋
1.概要部分
1）**符合需求和規格說明麼？
符合符合
2）**設計是否考慮周全？是是
3）**可讀性如何
可讀性高，有足夠注釋
可讀性高，邏輯清晰
4）**容易維護麼？
**自上而下寫法有助於後期的維護
易維護5）**的每一行都執行並檢查過了嗎？是是
2.設計規範部分
1）設計是否遵從已知的設計模式或專案中常用的模式是是
2)有沒有硬編碼或字串或數字等存在?有有
3)**有沒有依賴於某平台，是否會影響將來的移植(如
win32
到win64)?
沒有依賴平台
否沒有依賴平台
否4)開發者新寫的**能否用已有的library/sdk/framework中的功能實現？
是否存在類似的功能可以呼叫而不用全部重新實現?沒有否
沒有否5)有沒有無用的**可以清除
? (很多人想保留盡可能多的**， 因為以後可能會用上，
這樣導致程式檔案中有很多注釋掉的**，這些**都可以刪除，因為源**控制已經儲存了原來的老**。
沒有沒有
3.**規範部分
修改的部分符合**標準和風格麼(
詳細條文略
) ?符合
符合4.具體**部分
1)有沒有對錯誤進行處理
?對於呼叫的外部函式，是否檢查了返回值或處理了異常
?有對錯誤進行處理並處理了異常
有對錯誤進行處理，檢查了返回值
2)引數傳遞有無錯誤，字串的長度是位元組的長度還是字元
(可能是單
1雙位元組
)的長度，
是以0開始計數還是以
1開始計數
?無錯誤
從0開始
無；從0開始
3)邊界條件是如何處理的
? switch
語句的default
分支是如何處理的
?迴圈有沒有可能出現死迴圈
?開始時就先指定邊界條件；
當沒有default分支時，如果沒有滿足條件的
case
，直接結束
switch；
不會出現死迴圈。
先確定邊界條件是什麼，沒有default分支時，無滿足條件語句直接跳出switch語句，不會出現死迴圈。
4)有沒有使用斷言
( assert)
來保證我們認為不變的條件真的得到滿足?沒有
沒有5)對資源的利用，是在**申請，在**釋放的
?有無可能存在資源洩漏
(記憶體、檔案、
各種gui
資源、資料庫訪問的連線，等等
) ?有沒有優化的空間
?申請全域性變數，在程式執行完後釋放掉；無動態申請資源的地方，資源全部限制在函式或者類的區域性範圍之內不會出現資源洩露的情況。
申請全域性變數，在程式執行完後釋放掉；
有限次申請，所以可能不會導致資源洩露。
6)資料結構中有沒有用不到的元素
?無無用元素
沒有無用元素
5.效能
1)**的效能
( performance )如何?
效能較好
效能較好
2)**中，特別是迴圈中是否有明顯可優化的部分
(c++
中反覆建立類，c#中
string
的操作是否能
stringbuilder
來優化) ?否否
3)對於系統和網路的呼叫是否會超時
?如何處理?否
沒有相關呼叫
6.可讀性
**可讀性如何?
有沒有足夠的注釋
?可讀性高，有足夠注釋
可讀性高，有足夠注釋
7.可測試性
**是否需要更新或建立新的單元測試?
針對特定領域的開發
(如資料庫、網頁、多執行緒等
)，可以整理專門的核查表。
是沒有上述要求
是無此需求
(1)．每行80個字數限制,每一行盡量不要超過80個字元，超出後進行回車排版，方法名的冒號要對齊。
(2)．行寬限定為100字元。
(1)．類命名：首字母大寫，每個單詞首字母大寫（大駝峰命名法），盡量使用能夠反映類功能的名詞短語，例：usermanage ,userdata等。
(2)．方法名：首字母小寫，剩餘的每個單詞的首字母大寫（小駝峰命名法）。
(3)．變數名：首字母小寫，之後每個單詞首字母都大寫，具有足夠的說明性，成員變數不需要新增「_」字首，成員變數新增「_」字首。
(1).在方法內部注釋的地方使用//即可。
(2).複雜的注釋要放在類頭，並且注釋要隨著程式的修改而不斷更新。
(1)．乙個函式必須限制在50行左右（如果需要來回滾動眼球或**才能看全乙個方法，就會很影響思維的連貫性，對閱讀**的速度造成比較大的影響。最好的情況是在不滾動眼球或**的情況下一眼就能將該方法的全部**映入眼簾。
）(2)．單一原則：
每個函式的職責都應該劃分的很明確（就像類一樣）。
(1)．**簡潔易懂，邏輯清晰。
(2)．面向變化程式設計而非面向需求程式設計，因為需求是暫時的，**要利於根據需求變化。
(3)．先保證程式的正確性，以防開始時就過度考慮**的擴充套件性。
優點：1．我認為結對程式設計的程式設計效率會比個人程式設計高，而且互相鼓勵，不容易沮喪：團隊工作能增加成員的工作積極性。因為在面對問題的時候，會有人一起分擔，共同嘗試新的策略。
2．互相監督，不容易偷懶：兩個人一起工作需要互相配合，如果想偷懶去幹別的，就會拖延工作進度。
3．互相學習程式設計技巧：在程式設計中，相互討論，可以更快更有效地解決問題，互相請教對方，可以得到能力上的互補。
缺點1.兩個人想法不同的時候容易產生爭執。
2.寫**習慣不一樣，容易產生有的地方看不懂的情況。
綜上所述，結對程式設計」優點還是多於缺點，結對程式設計對學習和鍛鍊自己都是很好的方式途徑，但在學習合作中也要結對程式設計的時間需要合理安排。
本次四則運算的程式設計，通過j**a編寫能夠完成四則運算的各個功能，利用物件導向的程式設計的思想，將各個元件的事件響應用不同的方式表現出來。
(1).分析四則運算需要完成的功能
(2).考慮異常處理
(3).編碼實現各個功能
第四次部落格作業 結對專案
任務1 已完成 結對成員03班謝曉飛 03班張九川 任務2 2 互審 謝曉飛的 審查表 由張九川完成 能夠工作麼？它有沒有實現預期的功能，邏輯是否正確等。是2.所有的 是否簡單易懂？是3.符合你所遵循的程式設計規範麼？這通常包括大括號的位置，變數名和函式名，行的長度，縮排，格式和注釋。是4.是否存在...
第四次部落格作業 結對專案
結對成員 2班 趙迎港 2班 陶一鳴 1.概要部分 1.1 符合需求和規格說明嗎 符合 1.2 設計是否考慮周全 是1.3 可讀性如何 易讀1.4 容易維護嗎 容易1.5 每一行都執行並檢查過了嗎 是2 設計規範 2.1設計是否遵從已知的設計模式或專案中常用的模式 是2.2有無硬編碼或字串 數字等存...
第四次部落格作業 結對專案
一 結對成員部落格鏈結位址 四班孫成功 四班馬原飛 二 結對成員對四則運算專案進行 互審 部分內 容 孫 成 功 審查結果 馬 原 飛 審查結果 1 概要部分 1 符合需求和規格說明嗎 符合符合 2 設計是否考慮周全是是 3 可讀性如何好好 4 容易維護嗎 容易容易 5 每一行都執行並檢查過了嗎是是...