第四次博客做業-結對項目

1.結對成員的博客園地址：

 張於聖的博客：http://www.javashuo.com/article/p-qrraqtro-g.html

2.  代碼審查表：

a)   趙成的審查表

 

序號	內容	完成度
1.概要部分
1.1	代碼符合需求和規格說明嗎？	良好
1.2	代碼設計是否考慮周全？	否
1.3	代碼可讀性如何？	良好
1.4	代碼易於維護嗎？	良好
1.5	代碼的每一行都執行並檢查過了嗎？	是
2.設計規範部分
2.1	設計是否聽從已知的設計模式或設計中經常使用的模式？	B/S
2.2	有沒有硬編碼或字符串/數字等存在？	有
2.3	代碼有沒有依賴於某一平臺，是否會影響未來的移植？	否
2.4	開發者新寫的代碼可否用已有的Library/SDK/Framework 中的功能實現？在本項目中是否存在相似的功能能夠調用而不用所有從新實現?
2.5	有沒有無用的代碼能夠清除？	有
3.代碼規範部分
3.1	修改的部分符合代碼標準和風格麼（詳細條文略）	符合
4. 具體代碼部分
4.1	有沒有對錯誤進行處理？對於調用的外部函數，是否檢查了返回值或處理了異常？	已處理異常
4.2	參數傳遞有無錯誤？	無
4.3	邊界條件是如何處理的？switch 語句的default 分支是如何處理的？循環有沒有可能出現死循環？
4.5	有沒有使用斷言（Assert）來保證咱們認爲不變的條件真的獲得知足？	無
4.6	有無可能存在資源泄漏（內存、文件、各類GUI 資源、數據庫訪問的鏈接，等等）？有沒有優化的空間？	有
4.7	數據結構中有沒有用不到的元素？	無
5.效能
5.1	代碼的效能（Performance）如何？	通常
5.2	代碼中，特別是循環中是否有明顯可優化的部分（C++中反覆建立類、C#中 string的操做是否能用 StringBuilder 來優化）？	有
5.3	對於系統和網絡的調用是否會超時？如何處理?	是
6.可讀性
6.1	代碼可讀性如何？有沒有足夠的註釋？	良好
7.可測試性
7.1	代碼是否須要更新或建立新的單元測試？	否

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

b)   張於聖的審查表

序號	內容	完成度
1.概要部分
1.1	代碼符合需求和規格說明嗎？	通常
1.2	代碼設計是否考慮周全？	否
1.3	代碼可讀性如何？	通常
1.4	代碼易於維護嗎？	通常
1.5	代碼的每一行都執行並檢查過了嗎？	是
2.設計規範部分
2.1	設計是否聽從已知的設計模式或設計中經常使用的模式？	B/S
2.2	有沒有硬編碼或字符串/數字等存在？	有
2.3	代碼有沒有依賴於某一平臺，是否會影響未來的移植？	否
2.4	開發者新寫的代碼可否用已有的Library/SDK/Framework 中的功能實現？在本項目中是否存在相似的功能能夠調用而不用所有從新實現?
2.5	有沒有無用的代碼能夠清除？	有
3.代碼規範部分
3.1	修改的部分符合代碼標準和風格麼（詳細條文略）	符合
4. 具體代碼部分
4.1	有沒有對錯誤進行處理？對於調用的外部函數，是否檢查了返回值或處理了異常？
4.2	參數傳遞有無錯誤？	無
4.3	邊界條件是如何處理的？switch 語句的default 分支是如何處理的？循環有沒有可能出現死循環？
4.5	有沒有使用斷言（Assert）來保證咱們認爲不變的條件真的獲得知足？	無
4.6	有無可能存在資源泄漏（內存、文件、各類GUI 資源、數據庫訪問的鏈接，等等）？有沒有優化的空間？	有
4.7	數據結構中有沒有用不到的元素？	無
5.效能
5.1	代碼的效能（Performance）如何？	通常
5.2	代碼中，特別是循環中是否有明顯可優化的部分（C++中反覆建立類、C#中 string的操做是否能用 StringBuilder 來優化）？	有
5.3	對於系統和網絡的調用是否會超時？如何處理?	是
6.可讀性
6.1	代碼可讀性如何？有沒有足夠的註釋？	通常
7.可測試性
7.1	代碼是否須要更新或建立新的單元測試？	否

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.  選取其中一個成員的項目爲基礎，進行結對編程。結對項目撰寫的博客要求：

(3-1)代碼編寫基本規範（至少包括註釋規範與變量命名規範）。

    3.1.1：變量名規範

1.必須以字母、下劃線、或者美圓符$開頭；
①以美圓符$ 開頭命名的變量雖然可以編譯經過可是不建議使用；
②中文也能夠做爲命名開頭且編譯也能經過，可是不建議使用。
2.除開頭外後面的部分能夠有字母、下劃線、美圓符$以及數字組成；
3.雖然變量名不限制長度，但能表達清楚命名的含義便可；
4.變量名不能夠和java的關鍵字衝突； 

    3.1.2：註釋規範

       1.咱們能夠選擇使用//進行單行註釋

       2.咱們也能夠使用/* */進行多行註釋

       3.儘可能在項目的目錄中添加ReadMe文件，將該項目的實現功能和具體需求進行記錄

       4.在代碼的實現區域能夠添加代碼塊的解釋，方便使用的記錄  

(3-2)描述結對編程的感覺。

    該次編程過程，咱們將代碼實現所有更新，再也不從打印區進行輸入和操做。全部前端操做在web實現，即新建javaweb項目，

不過沒有使用MVC模式以及Spring框架。後期能夠改進，咱們只是將生成四則運算的輸入和選取操做放在了web頁面，後臺打

印輸出生成的題目。在頁面中能夠選擇生成的題目數量和最大、最小操做值，本身選擇包含什麼操做符。同時設置最大結果值，

咱們生成的操做值將小於您設置的數值。咱們在這次的結對編程中感覺到了雙方的編碼風格各有不一樣，雖然雙方的各有本身的

觀點，可是在積極努力的配合下咱們的項目一點點成形，目前結對編程仍處於相互磨合階段，但願下次能夠更快的進行項目的

實現以及促進結對編程的良好成果。

(3-3)結對場景照片

 

 

 

4.  結對項目編程要求：

      新增需求：（a）考慮數據異常處理問題，如在輸入題目生成範圍的數據時，輸入了「abc「等字符數據，程序如何處理。

             （b）增大算式生成數的範圍（如整數存不下的數），程序如何處理

 

 github的鏈接地址:https://github.com/55Cheng/codeHouse