UI第三組總結 PB16150206朱池葦+PB16070837劉鼎乾

項目簡介

    此次軟件工程結對項目爲製做一個給小學生用的四則運算出題軟件，咱們分配到的是UI組，也就是負責人機交互，使用Core組封裝好的模塊。

    GitHub地址：https://github.com/Ignoramus0817/Calculation-GUI

 

需求分析

•  對上述各屬性參數（生成題目的數量，操做數的數量，題目及答案中的數值的範圍……）進行設置
•  調用Core模塊獲得題目和運算結果，顯示題目，接受輸入，並能判斷答案是否正確
•  增長「倒計時」功能，每一個題目必須在20秒內完成，不然，得0分並進入下一題
•  增長「錯題記錄」功能，對於答錯的題，將其保存下來，當下次進行「複習」時，增大錯題在練習題中的機率
•  增長」歷史紀錄「功能，把用戶作題的成績紀錄下來並能夠展示歷史紀錄
•  增長「成績分享」功能，生成成績單，想想成績單裏要展示什麼，僅僅是最後的得分嗎？錯題的類型及數量？幫用戶分析其薄弱的環節，提出合理的學習建議？
•  對全部Core組的模塊進行測試

團隊分工

     結對編程做業大部分的時間都是採起共同編寫代碼的方式，即「一個作駕駛員，一個作領航員」，駕駛員負責敲鍵盤，領航員在一側提供建議、檢查錯誤或幫忙搜索相關的資料。

     就此次團隊項目而言，合做比較愉快。清明節的後兩天兩人一塊兒學習了Qt。因爲朱池葦對Qt比較熟悉，因此大部分程序都是朱池葦同窗做爲駕駛員，而劉鼎乾同窗則做爲領航員，與朱池葦同窗對問題進行討論，查找資料，檢查錯誤等。博客則由兩人共同完成。

 

PSP 表格

PSP2.1	任務內容	計劃完成須要的時間(min)	實際完成須要的時間(min)
Estimate	估算	15	15
Analysis	需求分析(包括學習)	135	200
Design Spec	設計文檔	15	15
Coding Standard	代碼規範	10	10
Design	具體設計	60	120
Coding	具體編碼	300	480
Code Review	代碼複審	--(包含在編碼過程當中)
Test	測試	120	300
Record Time Spent	記錄用時	10	10
Test Report	測試報告	20	40
Size Measurement	計算工做量	20	10
Postmortem	總結改進	180	180
Summary	合計	885	1380

 

代碼規範

 

1、命名風格

 

一、文件名：一概小寫。

 

二、類名：一概使用UpperCamelCase。

 

三、變量名、對象名、方法名（函數名）：一概使用lowerCamelCase。

 

 

 

2、代碼風格

 

一、4空格縮進

 

二、左花括號換行

 

三、不一樣模塊代碼之間空行

 

四、預處理命令：

 

​ 文件包含：類和頭文件分別集中，而且模塊之間空格

 

​ 宏定義：宏名一概大寫

 

 

 

3、其餘

 

一、程序全部內容所有爲英文，禁止出現中文和拼音，包括註釋和UI界面文字。（博客下方展現代碼塊中註釋是另外添加，程序中不含中文註釋）

 

 

代碼架構與具體實現

 

     UI界面佈局設計由Qt Designer完成，而複雜邏輯則由Qt Creator完成。

 

     UI界面很是簡單，因爲使用qStackedWidget來實現翻頁和題目的刷新，整個UI僅分爲三個部分：主窗口CalGUI，存檔對話框SaveSuccess，以及歷史記錄對話框History。絕大部分的功能都在主窗口上實現，存檔對話框以及歷史記錄對話框僅有顯示功能，所以着重介紹主窗口的結構和實現。

 

     主窗口上添加StackedWidget控件，分紅三頁：

 

     第一頁：初始化生成條件

 

     本頁主要由各類數字輸入框（SpinBox）和選項按鈕（CheckBox、RadioButton)構成，用SpinBox::value和CheckBox::isChecked、RadioButton::isChecked獲取用戶輸入的值，而經過設定默認值和輸入範圍的方法，能夠限制非法輸入。

 

     本頁包含兩個按鈕（PushButton），Next和Cancel，Cancel顧名思義是退出，而Next則是說明已經設定完畢，能夠開始作題，所以，Next的槽中調用了Core中的Setting接口。當用戶按下Next時，各個參數已經設置完畢。

 

     第二頁：顯示題目和題號、輸入答案、倒計時

 

     本頁有兩個按鈕Start和Next，分別實現「開始」和「下一題」，Next按鈕初始狀態爲隱藏，當Start被按下時顯示。Start按鈕使第一個題目顯示在一個文本瀏覽框TextBrowser中，並使計時器開始倒計時。

 

     倒計時的實現：

//添加在Start按鈕按下信號的槽函數中
void CalGUI::on_startButton_clicked()
{
    QTimer *timer = new QTimer(this);
    connect(timer,&QTimer::timeout,this,&CalGUI::timerUpdate);
    timer->start(1000);
}

//刷新時間的函數
void CalGUI::timerUpdate()
{
    int a=ui->restTime->value();
    if(a>0)
        ui->restTime->display(a-1);
    else
        ui->qNext->clicked();  //若是時間耗盡，發出Next按鈕按下的信號，自動跳轉至下一題。
}

//timer的信號函數設置爲空
void CalGUI::timeOut()
{
}

     Next按鈕控制界面的刷新（從新向控件中寫入數據便可）以及對錯的判斷，判斷正誤，獲取LineEdit中字符串，和答案字符串比較便可。若正確，作對的題目加一，若錯誤，存儲至錯題部分。

     將Timer的時間耗盡和Next的按下兩個信號鏈接在一塊兒，便可方便地實現時間耗盡自動跳轉的功能，因爲判斷正誤由Next控制，所以將二者合併不會形成誤判。

     用兩個QLabel分別顯示當前題號和總題數。在Next槽函數中比較兩個QLabel對應數字的大小（Qt提供了相關轉換函數，很是方便），當前者大於後者時，進入顯示結果頁面。

     第三頁：顯示結果，存檔和查看歷史記錄

     結果顯示即爲前面作題時存儲的正確題目數量、錯題、正確率的顯示。

     存檔按鈕控制生成.txt存檔文件（因爲沒有掌握對話框數據傳遞，偷了個懶不讓用戶自行輸入文件名），歷史記錄按鈕控制查看往期記錄（包括時間、正確題目數、總題目數、正確率、錯題、錯誤答案和正確答案）。比較簡單。

 

測試結果

 

參數設置頁面

 

 

開始答題前

 

開始答題後

 

結果（太難沒法口算所以全錯）

 

結果2（爲了展現錯題和正確率統計故意錯一半）

 

歷史記錄對話框

BUG記錄與分析

 

    一、LNK2019 沒法解析的外部命令

 

     這是編寫UI和對接過程當中遇到最多的一個BUG。

 

     若是是在編寫UI自己過程當中遇到，通常是給出了函數聲明，可是沒有具體實現所致使的，在.h+.cpp這種類定義和成員函數定義分離的狀況下，此類錯誤極易出現。我認爲較好的方法是，聲明後馬上在cpp文件中撰寫函數定義，若是暫且不須要寫，能夠用花括號留空。

 

     若是是在對接過程當中遇到，不多是相關函數core組同窗沒有定義。則通常是lib文件沒有正常加載，或者是dll文件的屬性（位數x86仍是x6四、debug仍是release)與編譯環境的屬性不匹配所致使的。合理地發佈SDK就能解決這種問題，所謂合理，指的是發佈時分類，而且指明相應SDK的屬性。

 

 

 

    二、沒法打開xxxx.lib文件

 

    這是庫文件沒有正常加載致使的，Qt Creator中.lib文件的加載方式和VS中有所不一樣，須要在.pro文件中新增格式以下的代碼：

LIBS +=-L$$quote(D:\zhu\Software Engineering\2018-SE-Course\Calculator GUI\CalGUI\untitled\Core15\x64) -lCore15
或
LIBS +=-LD:\zhu\SoftwareEngineering\2018-SE-Course\CalculatorGUI\CalGUI\untitled\Core15\x64 -lCore15

     其中-L後接.lib文件的絕對路徑，-l後接.lib文件不加拓展名的文件名。若是路徑中含有括號，應該使用$$quote（）將路徑括起。

     值得注意的是，假如須要將源代碼發給他人，此處絕對路徑須要修改成相對路徑，不然沒法正常加載。

     許多組發佈SDK時僅僅註明了Qt for VS的使用方法，而忽略了Qt Creator的使用方法。

 

    三、函數參數表沒法將xxx轉換爲xxx

     這種BUG本是函數傳入的參數和參數表不一致致使的，是編程時出現的失誤，爲什麼要在此處列出呢？由於Qt雖然支持部分C++庫和語法，但二者仍然有區別。

     好比Qt中的字符串類爲QString，而C++中類爲string(std::string)，須要通過QString::fromStdString轉換，纔可使用。

     這種差別的存在致使對接過程當中此類BUG大量出現，當心一些便可避免。

 

在與第七組對接後的BUG和解決方案：

 

    一、顯示結果頁面正確率和正確題數顯示不正常（因爲計時器信號未阻塞，會致使正確題目數量不斷增長，又因爲正確率爲實時計算，所以正確率也會不斷增長），跳至結果頁面後，阻塞計時器信號便可解決。

 

 

    二、分辨率問題，控件沒法自適應窗口大小和分辨率。修改UI佈局能夠解決（推薦剛開始編寫UI時就考慮這個問題，不然會產生巨大的工做量）。

 

 

 

 

    三、運行時有命令行（見上圖），修改Qt設置文件，將CONFIG += console改成CONFIG += release便可。

 

由編程得出的一些建議

     一、發佈SDK時必定要根據編譯環境和平臺分類。

     二、勤於寫README，而且在寫README時要考慮各類用戶的需求（好比VS用戶和Qt Creator用戶）。

     三、接口越少越好（接口數和參數數量折中）。

 

工做時刻

 

結對編程的意義相關 

• 一我的編寫代碼，老是有種燈下黑的現象。一些很是簡單的錯誤，由駕駛員本身是很難檢查出來的，旁觀者清，領航員則可以較爲輕易地發現。
• 結對編程至關於在編寫代碼的同時，進行復審，這可使駕駛員可以「朝着目標方向」前進，代碼規範、算法思想、以及最重要的，概念完整性，能夠獲得保障。
• 能夠不斷從別人那裏學習，提升本身的水平。在他人的監督下寫代碼有利於造成良好的代碼風格，清晰的編碼思路，以及熟練的調試技巧等
• 兩我的的知識結構能夠互補，好比駕駛員擁有穩重的編程風格和嚴謹的代碼規範，但不善於設計巧妙的算法；而領航員則有靈活的頭腦，二者結合，可使代碼高效、優雅而不失嚴謹，不會成爲「奇技淫巧」。

關於走上工做崗位後是否會選擇結對編程

（劉鼎乾）我認爲我會選擇結對編程。不只是由於隊友之間能相互找到彼此的燈下黑，還由於能在工做之餘和別人進行交流，切磋。這也是不斷提升本身，終身學習的有效途徑。

（朱池葦）在工程須要迅速完成且規模不大時，我不會選擇結對編程；但在工做量大的工程中，結對編程無疑是有其意義的。工程較大時，思路容易混亂，或者由於繁瑣的各類定義而犯一些低級的錯誤。結對編程大大減小了這方面的成本。

 

課程建議：

  （劉鼎乾）我認爲鄧老師確實很是很是負責，很認真地想把這門課上好，可是我以爲仍是有一些問題。

      一、上課不僅是講軟件工程的理論，還但願能多講一些實際編程有關的東西。
      二、安排大做業和結對編程的時候，儘可能和期中考等考試分開，能不影響你們的gpa就不影響。但願後面補作我的做業和結對編程時，不要放在和期末考衝突的時候，能夠考慮放在暑假。
      三、我以爲爲了難而難是不可取的。有些時候加大難度我感受不是頗有現實意義。而咱們工科是很是講究現實意義的。增長難度能夠，但要創建在實際有用的基礎上，若是爲了難爲咱們而故意弄一些很繁瑣的事情，我以爲並不可取。

 

  （朱池葦）目前我選這門課的目的基本上都實現了：瞭解本身技術棧的缺陷、體驗一下稍難一些的工程、磨鍊編程技術和肝功能（逃）。所以意見也很少。主要以下：

  但願能具體介紹一下哪一種工程師須要精通哪些技能（好比：前端工程師必須精通HTML，XML,JS，CSS，json，ajax等等），使咱們課外本身學習更有方向性，我在這方面比較迷茫，哪些東西是會有用的，它們是用來幹嗎的。若是能推薦一些教材或者學習時能夠設定的目標等等就更好了。

 

團隊項目如何改進    

  與結對編程相似，一個團隊中通常都有所謂「架構師」「產品負責人」的存在，這些人對技術或是需求很是瞭解，他們應該成爲團隊的領航員，由他們規定工程的架構和規範，全部人須要根據他們設定的規則完成本身的工做。

  而複審工做則不是同時進行的，而是完成一個部分後將代碼交由領航員審覈，對其中不恰當的部分進行修正。

  同時組內工做職能相近的同窗也能夠採用標準的結對編程方式。