1. 程式人生 > >結對作業項目報告——四則運算UI設計

結對作業項目報告——四則運算UI設計

基礎 電腦 而在 arc 算數 .net tails 正確答案 老師

一、項目要求

UI要求:

這是交付給最終用戶的軟件,有一定的界面和必要的輔助功能。完成Windows和Linux電腦圖形界面的程序,需實現以下功能:

對上述各屬性參數(生成題目的數量,操作數的數量,題目及答案中的數值的範圍……)進行設置

調用Core模塊得到題目和運算結果,顯示題目,接受輸入,並能判斷答案是否正確

增加“倒計時”功能,每個題目必須在20秒內完成,否則,得0分並進入下一題

增加“錯題記錄”功能,對於答錯的題,將其保存下來,當下次進行“復習”時,增大錯題在練習題中的概率

增加”歷史紀錄“功能,把用戶做題的成績紀錄下來並可以展現歷史紀錄

增加“成績分享”功能,生成成績單,想一想成績單裏要展現什麽,僅僅是最後的得分嗎?錯題的類型及數量?幫用戶分析其薄弱的環節,提出合理的學習建議?

UI組需對所有Core組的模塊進行測試。

二、項目Github地址

https://github.com/Roarcannotprogramming/homework_2/tree/master/homework_2

三、需求分析

1、 為用戶顯示題目,並且接受用戶答案從而評斷是否正確;

2、 用戶答題時需要有倒計時功能,限制為20秒;

3、 根據用戶答題之後生成錯題本;

4、 把用戶每一次的答題記錄生成歷史記錄;

5、 最後需要能產生文件將成績分享。

四、PSP表格

技術分享圖片

五、準備階段

1、 工具的選擇與安裝

我們小組選擇了QT進行UI的設計。

首先是QT的下載與安裝,下載地址:http://download.qt.io/archive/qt/

安裝教程:https://www.cnblogs.com/chenmingjun/p/8392713.html

在Visual studio2017上配置QT:https://blog.csdn.net/qq_33154343/article/details/78587699

4月5日:經過一下午的下載與安裝,成功在vs上創建了第一個QT項目。

2、QT的學習

學習QT:http://www.qter.org/portal.php?mod=view&aid=26

4月5日晚上與4月6日的早上根據網上的教程開始了QT的學習,經過一個晚上和一個早上的學習與了解,我們放棄了vs的使用,原因是不太熟悉在vs中對UI界面的操作,最終選擇了QT Creator,這個軟件不僅與教程較為貼切,而且對於QT新手較為友好,很容易進行上手。

4月6日:下午開始了項目。

六、工作階段(結對小夥伴為駕駛員,我為領航員)

1、 初始界面的設計

首先是任務欄,我們將任務欄分為:文件、工具兩類,其中文件裏包含了新建答題的選項,工具裏包含了錯題本、歷史記錄、生成成績單的選項;

其次是快捷鍵一欄我們設置了新建答題、錯題本、歷史記錄、生成成績單的快捷鍵;

頁面中心是“歡迎答題”四個字;

我們起初是只是設計了標語與“開始答題”的按鈕,

技術分享圖片

我們在之後的過程中逐步的進行了改進,考慮到Core組的算式生成,我們需要在答題之前確定用戶需要做多少到題目,每一個題目是需要有多少個運算符,最後還要選擇適合用戶該年齡階段的運算符種類,避免有用戶沒有學習乘除或乘方帶來的問題,以及學過的用戶的題過於簡單只有加減乘除的不平衡問題,之後能緊接著生成算式。於是我們在首頁的地方添加了題目數量、最多運算符、運算符種類的填寫與選擇以及高級選項(具體見下文),用戶需要自行填寫具體信息。

技術分享圖片

使用的工具:技術分享圖片技術分享圖片技術分享圖片技術分享圖片技術分享圖片

2、 答題界面的設計

首先我們思考的是答題界面是如何跳出來的,於是就有了不同想法,我想能不能在用戶點擊了“開始答題”的時候跳出一個單獨的頁面,在這個單獨的頁面進行題目的問答,但組隊的小夥伴覺得這個可以類似現在的一些軟件,在同一個頁面上只不過是頁面的內容變成題目的問答,我覺得這樣做更加流利與便捷。於是我們確定了答題界面出現的方式,利用Stacked Widget工具可以實現在同一個頁面下顯示不同的內容。

技術分享圖片

緊接著便是答題界面的具體布局,這個也遇到了一個需要思考的問題:如何顯示問題?有兩種方式擺在我們的面前,第一種是在一個頁面上將所有的題目顯示出來,再進行答題,第二種是在一個頁面上只顯示一道題,用戶答完一道題之後,再點擊按鈕進行下一道。與Core組討論了一下他們最後傳遞算式的方式,是一個一個算式提供給我們,於是我們就確定了一道一道題地顯示。

又一個問題出現了,我們要不要利用Stacked Widget工具根據題目數量生成相應數量的界面,在每一個界面都采用同樣的格式與布局,但當時就被我們pass了,因為這樣做不僅工作量大,而且最後的結構會很復雜,於是我們采取了一種“刷新”的機制,意思是只做一個答題的界面,而每答完一道題後顯示題目的文本框便會清除裏面的內容,答題的文本框也會將用戶的答案讀取後清除,從而達到要求。

之後便是界面上的其他功能,第一個是計時器,根據要求每道題的答題時間為20秒,20秒時間到了便彈出一個提醒框,點擊後就會跳到下一題;第二個是下一題的按鈕,當用戶作答完畢後,便可以點擊進入下一題的回答;第三個是題目序號的顯示,這個功能可以顯示出用戶當前是第幾道題。

技術分享圖片

使用的工具:技術分享圖片技術分享圖片技術分享圖片技術分享圖片技術分享圖片技術分享圖片

3、 結束界面的設計

在用戶做完所有的題目之後,便會出現結束界面,這個界面我們也是在Stacked Widget工具中進行設計。首先是一個標題“恭喜你做完了”,提高一下用戶的愉悅度;其次我們想在最後的頁面上可以放什麽?第一個功能便是 “退出”,這裏的退出是整個頁面全部關閉,第二個功能是“再來一次”,這個功能可以方便一些意猶未盡的用戶再進行一次答題,點擊這個按鈕後便會跳轉到初始界面,進行新一輪的答題,第三個功能是進入錯題本,這個可以跳到錯題本界面(具體見下文),第四個功能是顯示題目總數與做對的題目數,這個可以更好的並及時的讓用戶看到自己的成績。

技術分享圖片

使用的工具:技術分享圖片技術分享圖片技術分享圖片技術分享圖片

4、 高級選項界面的設計

這個界面是獨立與主頁面的,它的主要功能是為算式的生成提供更詳細的信息,可以說是對於算式的更高一層的限制,使得用戶可以有針對性的進行算數訓練,避免出現超綱或過於簡單的事情,包括了運算符數、表達式類型(整數、小數、分數)、操作數最小值、操作數最大值、小數點後保留幾位的算式限制條件,用戶可以通過這個選項對自己的答題進行操控,如果沒有選擇,我們默認為5個運算符數、表達式類型為整數、操作數最小0、最大100,防止用戶需要經常設置的尷尬。

技術分享圖片

使用的工具:技術分享圖片技術分享圖片技術分享圖片技術分享圖片

5、 錯題本界面的設計

這個頁面,是獨立於主頁面存在的。用戶點擊有關“錯題本”的按鈕就會出現此頁面,這個頁面的主要功能是顯示用戶在這次答題中錯題序號、錯誤題目、用戶答案和正確答案,這個界面旨在更好的服務用戶,讓用戶在使用我們的軟件的時候能夠通過錯題的積累中得到進步,其中包括了顯示信息的文本框,與清空文本框的功能。

技術分享圖片

使用的工具:技術分享圖片技術分享圖片技術分享圖片技術分享圖片

6、 歷史記錄界面的設計

這個頁面是獨立與主頁面的。這個界面的功能是查看用戶過去的答題記錄。這個頁面包括了總題數、正確題數、正確率、正確答案的顯示,這個可以讓用戶更好的回顧以前的答題,通過對比可以發現自己的問題以及進步,為用戶提供最優質的服務。

技術分享圖片

使用的工具:技術分享圖片技術分享圖片技術分享圖片技術分享圖片

7、 與Core的對接

我們嘗試了與第15組和第9組的對接,通過API實現Core與UI的對接,首先通過用戶的選項,進行判斷,其次通過判斷得出用戶需要什麽樣的算式,於是調用Core組給的文件,將信息傳給Core,在將Core根據要求產生的算式在答題的文本框中顯示,並且會給我們正確答案,用戶每做完一題後都會與正確答案進行字符串的比對,如果正確,則對正確的個數加一,如果錯誤則將算式、題號、用戶的答案和正確答案直接送到錯題本中。最後在結束界面顯示總題數與正確的題目數量。

8、 測試與運行結果

技術分享圖片技術分享圖片技術分享圖片技術分享圖片技術分享圖片技術分享圖片技術分享圖片

9、 界面修飾與點綴

七、Bug

1、 出現的bug

A、 答案填寫中出現回車就會影響最終的判定,並且會影響最終錯題本的生成

技術分享圖片

B、 在歷史記錄裏的表頭中無法使用“總”、“率”等字

技術分享圖片

2、 原因

A、 沒有對用戶的輸入進行一個篩選

B、 因為QT Creator使用的是MSVC2017的編譯器,使用的字符編碼是GB2312,而我們需要的是utf8

3、 調試時間

A、 耗費了半個小時

B、 耗費了半個小時

4、 教訓

總是在一些細節的問題上出現Bug,而這些細節是一些很難再編程的時候註意到的,需要在調試的過程中慢慢尋找,可以將自己視作為一個真正的用戶,在不斷的考驗著最後的成果,通過各種作為一個用戶可能會做的事來判斷自己的項目是否有容錯性,在使用的時候盡量不按照常規走,這樣更可以在一個看似完美的地方找到從未發現的漏洞

八、結對編程與個人編程的差異

這次的結對編程充分的顯現了個人與團隊的差別,不是說個人工作不好,而是結對工作實在是很有效。

首先從合作的角度看,一個好的結對是很不容易的,這個裏面需要避免個人的隨意性,要隨時為大局考慮,可以說自由性會有所下降,舉個例子,在這次組隊中如果兩個人沒有協調好,那麽造成的危害是無法計量的,可能會出現重復的危害,也可能最終因為交流不及時造成項目不能及時完成,這是一個很需要我們明白的道理,因為以後的結對項目充斥著我們的工作。

相比與個人而言,結對編程更加有效率,首先從分析用戶需求的時候來看,兩個人的想法不僅比一個人的想法多,這不是一個蘋果加上另一個蘋果這麽簡單,而是一種試劑加上另一種試劑會產生劇烈的化學反應。每個人都有在認知上面的盲點,沒有一個人可以充分的看到一個事情的全部表現,如果兩個人甚至是更多的人結對,對於需求的剖析絕對會達到一個人無法達到的地步,最終理解就是個人與結對無法相比的;其次是在正式碼代碼的時候,一個人可能會比兩個人工作時快一點,但最終的結果卻不一定比結對的好,兩個人結對編碼的時候思維是經過碰撞的,思路可能會更清晰,也更明確具體的方向,出現問題很容易就能及時發現並改正,一個人如果中途的想法有了一絲偏差,在過程中沒有發現,最終帶來的結果可能就會不盡人意;最後就是工作量上會有一點點的減少,減輕了一個人開發時的壓力,面對令人頭疼的問題是也會比個人而言更容易去解決。

相比與個人而言,結對編程更有益於人的進步。“結對”的過程同樣是“交流”的過程,也是學習的過程,這就是擺脫“閉門造車”的最好機遇。首先這次的UI,我們是對於QT不太了解的,通過結對學習也能增強自己對於這個的理解,對於工具的使用,在結對中可以不斷的嘗試與搜尋,這個就比個人工作所需要的時間少,對於新的事物可以通過討論得到充分的理解。如果是倆個水平相當的同學,則可以互相進步,以他人之長補己之短,在結對中能夠更快的提升自己,;如果是一個技術薄弱的人與一個能力很強的人,對於技術薄弱的一方就是一次很好的學習機會,通過與“大佬”的交流可以更快的看到自己的不足以及時彌補,而對於“大佬”而言,這是一次促進合作能力的工作,可以為以後步入社會與他人合作奠定基礎。

相比與個人而言,結對編程更能促進工作的積極性。一個人的工作可能不會受到打擾而影響進度,但是一個人的熱情會很快就會下降,如果說在團隊中工作,當你的熱情下降的時候,你會發現同伴任在努力奮鬥當中,這是快要熄滅的火苗會立即燃燒起來,這是一個相互的作用,不會有一個人從頭到尾都一直保持著那種勁頭,但在結對中可以提高保持沖勁的時間。如果當別人的工作進度已經達到了很快的地步,反觀自己就會有一種壓力,這也是一種動力,促進自己完成工作的動力,畢竟也不想出現,對方工作快完成了,而自己的還遙遙無期的尷尬,並且出現了可以相互監督的操作,已達到更好的工作狀態。

從而在這次結對編程中,深刻的感覺到了一個人的力量總是有限的,兩個人甚至更多的創造是無限的。

九、個人看法(走上工作崗位後,是否選擇結對編程用於解決部分任務?)

我的看法:說實話,結對編程是很有助於問題的解決,不僅體現在時間花費上面,還體現在最終成果的質量上,但是在工作崗位上還要考慮自己未來的發展,如果是為了更好的完成任務與向他人學習的時候,結對無疑是一個很有效的途徑,但如果在個人完成後能夠得到的收獲比結對的收獲更多的情況下,我會選擇個人編程,從工作上看,結對無疑比個人更輕松的有收獲,但是沒有經歷過一個人編程時的壓力與絕望,作為一個程序員是無法得到正真的歷練與成長。所以在正真工作崗位上,我比較傾向於結對,但我也不會放過個人編程的機會,在結對中彌補自己,在個人裏鍛煉自己。

小夥伴的看法:走上工作崗位後,希望可以繼續有結對的機會,這主要是因為有的時候如果一個人編程,可能會出現懈怠的情緒,而兩個人共同編程會互相激勵,起到促進作用在個人編程時,有時會出現對整體架構把握不清的情況,這時如果能跟隊友共同討論分析,會大大加快理解以及設計的速度。在一個人敲代碼時,另一個人可以反思這部分代碼有什麽問題,哪裏可以進行優化,與其他部分的關系是什麽,下一步應該如何進行處理。這些都能夠使代碼質量得到極大的提升。總之,我認為這是一種非常適合我的編程方法,所以自己比較青睞於結對解決部分任務。

十、總結(今後的團隊作業,每周的任務,準備如何吸收個人作業、結對作業,改善開發流程?)

首先從團隊作業說,這次的結對就是一次小型的團隊作業,這個給了我們一次很重要的經歷,讓我們更好的理解什麽是團隊?如何適應團隊?怎樣在團隊中更好的工作?最後如何能夠在不影響他人的情況下發揮自己的優點?這些都能夠在這次小小的結對作業中得到體現,最終反映在結果之中。今後的團隊作業自然要吸取這次沒有做好的地方的教訓,繼續保持能夠提高效率的工作技巧,從最基本開始,每一個細節都有可能是決定未來勝負的關鍵,。

對每周任務而言,可以提高自己的時間利用率,類似在個人與結對中會出現一些完全沒有必要浪費時間的事情,在以後的任務中應該盡量避免,在經歷了一次個人作業的磨礪中,明白了項目開始的越早,越可以把控全局,在當時自己沒有領悟到這個精髓,導致自己在工作時很慌亂,腦海總會冒出完不成的想法影響工作的進程,然後熬了三天夜,才勉強完成,自然比不上一開始就進行項目的同學代碼質量,在這次結對的作業中,我們一開始就對作業進行了分析,當時是沒有UI 的要求,我們討論的是Core的內容,從基礎的需求分析到代碼構建,我們可以說是做了大部分,當分組出來時,我們是UI組,之前的討論並不是一無所用,而是給了我們在設計用戶圖形界面的時候提供了一個框架與模板,之後便是最基本的工作,所以越早開始越能把控全局。

對於我們,一個好的開發流程是能夠起到至關重要的作用,這好比自己的經歷,遇到了第一次的個人項目,完全沒有一個流程,就是遇到啥就解決啥,就出現了以前解決問題的方法導致了現在問題的復雜化,這個困難的增長是幾何增長的,沒有一個好流程就會對工作造成很多無法預知的困難與不知如何下手的尷尬局面,但是在這次結對中我們體會到了擁有一個開發流程的便捷,從初步的構型,到實際的設計,每一步我們都有很明確的方向,不會在尋找出口的問題上浪費時間,正如小夥伴在進行頁面的設計時,我可以進行界面功能的構思與探索,這個可以很好的提高我們之間的工作效率

每一次的作業都對於我們來說都是意義非凡的,這其中包括了知識的積累,眼界的開闊,思維的重構等,收獲的不僅僅是最終的結果,更是開發的過程。

十一、 看法與意見

對於本課的看法:

有效的將同學們從書本中拽了出來,讓我們體驗了在戰場上的驚險與刺激,俗話說的好“實踐出真知”,只有在一次次的真槍真刀的戰鬥中,一個程序員才能夠得到正真的成長,而在這堂課中老師充分的模擬了未來在工作崗位上我們會遇到的問題,例如在規定的時間內交付給用戶完整並可使用的原型,還有就是在工作中需要在一個團隊中共同工作的情況等,這個課不單單的是在教我們如何編程,而是在教我們如何成為一個公司或者實驗室真正需要的程序員,老師經常強調我們已經不是代碼層次,而是軟件開發層次,這是一個質的飛躍,同樣是對我們的一次烈火考驗。

對於本課的意見:

可以多進行一些“幹貨”的講解,對於未來有幫助的工具進行一些大致的介紹。

結對作業項目報告——四則運算UI設計