合作者學号及部落格連結
- 陳璟 031602402 部落格位址：http://www.cnblogs.com/unbelievablecj/
- 陳曉彬 031602404 部落格位址：http://www.cnblogs.com/nanjibin/
設計思路
實作這個電腦主要有兩方面的内容
- 随機生成題目
- 得到題目的正确答案
除了這兩個部分其他的諸如中英雙界面什麼的都不是問題，也是以我和我的隊友各負責一部分，我負責得出正确的答案。
關于計算功能的實作我第一反應是仿照編譯器的編譯原理，好像是用了一種樹形結構來處理算式，但好像處理起來也很複雜的樣子，于是我還是決定用傳統的人的思維來解決計算的問題，首先需要兩個容器，一個存放數字，一個存放運算符，然後在運算符容器中不斷尋找除号和乘号，然後對數字容器運算，再尋找加号和減号，運算同上。這樣一個沒有括号的四則運算就完成了。我把這個過程設為
count()
，然後再設定一個
getAnswer()
，在這個函數中不斷尋找括号，将括号及其内容變為使用
count
得出的答案，例如将
1+(1+1)
變為
1+2
，再處理完括号後，再執行一遍
count()
,最終答案就出來了。
當然實際實作過程沒這麼簡單，過程中伴随着大量的bug。一下列出碰到的邏輯bug警醒我程式設計道路的兇險。
- bug 1 運算符的優先級
最初我是按照乘除加減的優先級來進行運算的，但後來發現不可行，比如 1-1+1，就會變成1-2，答案就會是-1，是以後來我用乘除一并尋找，誰在前面先算誰的方針，解決了這一bug。
- bug 2 括号内的分數
我對括号的處理是如果括号内答案有分數，将其變為假分數，比如（3-1/2）就是5/2而不是2+1/2，這就導緻了一個問題，5/(3/2)和5/3/2答案是不同的，當初以為乘除的優先級相同，括号沒影響，沒想到會出現這樣的問題，最後我在括号處理的那部分代碼加上一個條件判斷，如果括号前是除号且括号内為分數，将分數内的除号變為乘号，這樣就能完美解決這個bug了。
- bug 3 提前删除運算符
這個是我的實作的問題，在加減運算方面因為分數的存在，需要額外判别目前加減符号的前後有沒有除号，有則是分數，我分了四種情況，每種情況處理完後都會删除目前的加減号，這就出現了一個問題，比如 1-1+2/3 ，會對減号進行運算，算式變為0+2/3，這是目前運算符變為+，因為減号被删除了，問題就在這，四種情況的if是并列的，接下來程式會判别 + 後面是 / ,就又會進行一次減法運算，同時删除 + ，最後處理方法就是将運算符的删除放在最後，就不會有這個問題了。提這個問題主要是提醒各位，在用到if的時候要注意邏輯的清晰，同時要注意變量的改變對其他if的影響。
編碼規範
- 題目和答案的傳回使用string類型
- 計算答案的類名solve,存放在solve.h中,solve有一個getAnswer方法，傳入string類型的題目，傳回string類型的答案
本來想讓隊友也寫類的，奈何還不會，我也不知道隊友是如何寫随機生成題目的，唯一肯定的是題目是string類型，并保證分母不為0。
程式的實作和結果測試的截圖
github的送出連結和送出日志截圖
代碼連結
分工和協作證據截圖
合作過程
基本上在組完隊友後就明确了職責，我和隊友各負責一部分，彼此不會産生幹擾，就是完成自己的功能部分就沒事了，本來我是想和隊友各寫一個類，我負責main函數的編寫，主要就是調用方法。但是隊友好像還不會類，而且還要用main來生成題目，是以就把main函數的編寫也交給他，我隻負責solve類的編寫。完成後上傳GitHub，剩下的就是修複測試中碰到一些少見的bug。
合作體會
總的來說感覺還好。個人負責自己的代碼的話編寫的效率也高，不必費力氣去了解别人的代碼是什麼意思。合作的話隻要有一定的規範，基本和自己編碼沒什麼差。