Java結對編程之挑戰出題
需求分析
- 需求
- 對於挑戰出題來說最主要的就是要產生的式子並將重復的式子去掉。
設計思路
-
具體的思路：
-
思路一：
原先我打算用集合中的元素的不重復性進行去重，這種思路的好處就是在運算符少的時候重復的概率越低，在參加運算的數字比較少的是好用。后來發現在產生大量的運算符參加運算時去重去掉的式子太多，就是說在運算符越多重復數字越多時去掉的式子太多從而大大的降低了運行的速率，就是說時間太長所以就放棄了這種方式。 -
思路二：
后來在於同學交流之后就選擇了用另外一種去重的方法，就是將結果相同的式子去掉，這個思路的好處就是運算符越多重復的可能性就越低可以產生比較多的式子。
實現過程中的關鍵代碼解釋
- 入口類
import java.io.IOException;
/**
* Created by 春旺 on 2017/6/4.
*/
public class ExpressionGenerator {
public static void main(String[] args) throws IOException {
OutQuestion questionNumber = new IOPractice();
int num1 = Integer.parseInt(args[0]);
int num2 = Integer.parseInt(args[1]);
questionNumber.problem(num1,num2);
((IOPractice)questionNumber).inFile(args[2]);
}
}
這是為了用工具類在命令行下實現而設計的。
運行過程截圖
- 依次運行的結果
測試
代碼托管地址
- 要運行的是不在文件夾下的ExpressionGenerator類
- 編譯時請老師編譯Src文件夾下后綴為.Java的文件。
- 我們的結對編程的項目在最后的時候克隆在本地地有點問題所以改提交在了我的個人項目中
遇到的問題及其解決方法。
-
問題1去重
解決：我去網上找了很多資料之后還是沒有找到一個比較好的方法來去重后來就選擇了在設計思路中說到的兩種方法來進行測試。
這個問題還沒有找到很好的方法來解決。 -
問題二 測試工具
測試工具必須在src文件運行后產生的class的文件夾中運行並且代碼中不可以有包名否則無法運行
對結對的小伙伴做出評價
- 結對伙伴： 20162312 張家鋮
結對伙伴的思維比較活躍，在寫代碼遇到困難時有助於我做出突破，他比較善於和同學交流在我們遇到瓶頸的時候總是可以找同學交流之后找到一個比較好的方法；
但是也是比較粗心，而且對於時間的把握還有待改善。最主要的是在寫代碼的注釋的時候有些時候有些難懂，並且在寫代碼時太慢；
給結對伙伴分：
- 分數 40
- 依據
1.代碼相對來說我提交的比較多一些。
2.設計文檔都有參與不分多少。
3.測試中的參與度比較少。
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（小時） | 實際耗時（小時） |
|---|---|---|---|
| Planning | 計划 | 1 | 1 |
| · Estimate | · 估計這個任務需要多少時間 | 20 | 20 |
| · Analysis | · 需求分析 (包括學習新技術) | 0.5 | 2.5 |
| · Design Spec | · 生成設計文檔 | 1 | 1 |
| · Design Review | · 設計復審 (和同事審核設計文檔) | 0.5 | 0.5 |
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | 1 | 1 |
| · Design | · 具體設計 | 2 | 2.5 |
| · Coding | · 具體編碼 | 2.5 | 2.5 |
| · Code Review | · 代碼復審 | 2 | 2.5 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | 2 | 1 |
| Reporting | 報告 | 1 | 1.5 |
| · Test Report | · 測試報告 | 2 | 1.5 |
| · Size Measurement | · 計算工作量 | 1 | 1.5 |
| · Postmortem & Process Improvement Plan | · 事后總結, 並提出過程改進計划 | 1 | 1 |