PROJECT | 四則運算UI設計 - 項目總結

【項目Github地址】html

 https://github.com/oTPo/hw2前端

 

【項目規劃】git

PSP表格程序員

事項github

預計時間(min)編程

實際花費時間(min)後端

需求分析架構

60框架

60函數

開發流程分析

30

60

新技術學習

300

400

實際工程開發

600

750

工程總體調試和優化

270

350

項目總結

60

120

(合計)

1320

1740

 

【具體項目規劃】

>  需求分析

原本打算用MFC的,後面再和組員討論後決定使用Qt,由於能夠跨平臺。詳細博客地址請見:http://www.cnblogs.com/ustctp/p/8711860.html

>  開發流程分析

  • 程序基本架構爲:主窗口(參數設計窗口)+子窗口(答題窗口,錯題回顧窗口,成績單窗口)
  • 編程方式採用增量式編程,即每編完一個窗口即進行調試。
  • 實現程序總體框架和核心功能時,詹元成爲駕駛員,譚鵬爲領航者;實現界面美化時,譚鵬爲駕駛員,詹元成爲領航者。實現接口對接時,詹元成爲駕駛員,譚鵬爲領航者。

>  代碼規範(摘錄)

  •  (代碼風格)每一行開始處的縮進只能用Tab
  •   (代碼風格)在代碼行的結尾部分不能出現多餘的空格
  •   (代碼風格)除了特別狀況,函數體內不能出現兩個空行
  •   (代碼風格)"if"、"for"、"while"、"do"、"try"、"catch" 等語句自佔一行,執行語句不得緊跟其後。不論執行語句有多少都要加 "{ }" 。這樣能夠防止書寫和修改代碼時出現失誤
  •   (代碼風格)if語句若是有else語句,用 } else { 編寫爲一行,不推薦用 3 行代碼的方式。
  •   (代碼風格)多行變量定義,爲了追求代碼排版美觀,可將變量豎向對齊。
  •   (代碼風格)對於switch語句,若某個case不須要break必定要加註釋聲明。
  •   (命名規範)同一性:在編寫一個子模塊或派生類的時候,要遵循其基類或總體模塊的命名風格,保持命名風格在整個模塊中的同一性。
  •   (命名規範)標識符組成:標識符采用英文單詞或其組合,應當直觀且能夠拼讀,可望文知意,用詞應當準確,避免用拼音命名。
  •   (命名規範)最小化長度 && 最大化信息量原則:在保持一個標識符意思明確的同時,應當儘可能縮短其長度。
  •   (命名規範)避免過於類似:不要出現僅靠大小寫區分的類似的標識符,例如"i"與"I","function"與"Function"等等。
  •   (命名規範)避免在不一樣級別的做用域中重名:程序中不要出現名字徹底相同的局部變量和全局變量,儘管二者的做用域不一樣而不會發生語法錯誤,但容易令人誤解。
  •   (命名規範)正確命名具備互斥意義的標識符:用正確的反義詞組命名具備互斥意義的標識符,如:"nMinValue" 和 "nMaxValue","GetName()" 和"SetName()" ….
  •   (命名規範)避免名字中出現數字編號:儘可能避免名字中出現數字編號,如Value1,Value2等,除非邏輯上的確須要編號。這是爲了防止程序員偷懶,不願爲命名動腦筋而致使產生無心義的名字(由於用數字編號最省事)。

>  優化思路

  •   界面美化(字體大小,字體,窗口擴展——支持滾動條的窗口)
  •   功能完善

 

【項目細節】

>  接口定義

int error=0,error1=0;
seti[0];  //題目數
seti[1];  //上限
seti[12];  //下限
seti[3];  //操做數數量
argu.integer = seti[3];  //支持整數
argu.fraction = seti[4]; //支持分數
argu.decimal = seti[5];  //不支持小數
argu.add = seti[6];      //支持加法
argu.sub = seti[7];      //支持減法
argu.multiply = seti[8]; //支持乘法
argu.division = seti[9]; //支持除法
argu.pow = seti[10];      //不支持乘方
argu.bracktet = seti[11]; //支持括號
error=Setting(seti[0],seti[1], argu);
error=Setting(seti[0],seti[1],seti[2],seti[3],seti[4],seti[5],seti[6],seti[7],seti[8],seti[9],seti[10],seti[11]);
error1=Generate(error);

 

>  UI設計思路

  •  UI組的設計要求以下:
    • 對上述各屬性參數(生成題目的數量,操做數的數量,題目及答案中的數值的範圍……)進行設置
    • 調用Core模塊獲得題目和運算結果,顯示題目,接受輸入,並能判斷答案是否正確
    • 增長「倒計時」功能,每一個題目必須在20秒內完成,不然,得0分並進入下一題
    • 增長「錯題記錄」功能,對於答錯的題,將其保存下來,當下次進行「複習」時,增大錯題在練習題中的機率
    • 增長」歷史紀錄「功能,把用戶作題的成績紀錄下來並能夠展示歷史紀錄
    • 增長「成績分享」功能,生成成績單,想想成績單裏要展示什麼,僅僅是最後的得分嗎?錯題的類型及數量?幫用戶分析其薄弱的環節,提出合理的學習建議?
  • 針對上述設計要求,咱們將UI界面進行以下切分
    • 主界面——參數設置界面(設置生成題目的數量,操做數的數量,題目及答案中的數值的範圍等參數)
    • 子界面1——答題界面(配有計數器)
    • 子界面2——成績展現界面(經過顯示做答時間,正確率,分數等綜合評定作題人的表現,並給出合適的評語)
    • 子界面3——錯題記錄界面(展現作題過程當中的錯題以及超時的題目,方便作題人進行復習)
  • 界面展現

(主界面——參數設置界面)

(子界面1——答題界面)

 

 (子界面2——成績分享界面)

 

(子界面3——錯題記錄界面)

 

(使用說明界面)

 

 

>  開發過程當中的BUG及解決辦法

【問題】

  消息顯示框中文顯示亂碼

【解決方案】

  改變字符編碼

 

// 採用文字編碼轉換類QTextCodec
QTextCodec::setCodecForLocale(QTextCodec::codecForName("utf-8"));
//若是是Qt4版本的,還能夠設置tr進行中文轉換
QTextCodec::setCodecForTr::QTextCodec::codecForName("utf-8"));
//Windows下,通常狀況下設置gb18030就能夠顯示中文了

【問題】

  文件中沒法寫入中文

【解決方案】

   採用QTextStream,而不用Qfile中自帶的文件讀取輸出函數

#include <QtCore/QCoreApplication>  
#include <QFile>  
#include <QtDebug>  
#include <QTextStream>  
  
int main(int argc, char *argv[])  
{  
    QCoreApplication a(argc, argv);  
      
    QFile file("test.txt");  
    //---參數:QFile::Truncate表示的是 將原文件內容清空,  
    //--以WriteOnly方式打開文件,若是在工程文件下沒有該txt文件,那麼程序將建立該文件,若存在,則將原文件內容清空,  
    if (file.open(QFile::WriteOnly | QFile :: Truncate))          
    {  
        //---建立 QTextStream流操做對象, 使與QFile對象file綁定。  
        QTextStream out(&file);   
        //----設置輸出格式爲: 居中,這裏格式還能夠設置爲:right/left。 佔10個字符;  
        out << "socre:" << qSetFieldWidth(10) << center << 90 << endl;  
    }  
    else  
    {  
        qDebug() << "open file failed";  
    }  
    file.close();       //---關閉文件~~~~~~  
  
    //-----輸出提示信息  
    qDebug() << "\1   writing data  succesful   \1" << endl;  
      
    return a.exec();  
}   

【問題】

  qt creator報錯 error: C1083: 沒法打開包括文件:「Untitle」: No such file or directory

【解決方案】

   清理下項目。

  菜單——build——run qmake

  必定要執行qmake,不能只清理項目!!!!

 

>  對接過程的問題

  • 不一樣Core組的通訊方式不同,有的是經過文件進行通訊,而有的組是經過容器進行通訊。(咱們UI組這兩種常見的通訊方式都支持)
  • 有的Core組是經過頭文件和函數進行通訊, 所以須要新建工程添加頭文件和函數進行通訊,也可以通訊成功。
  • 有的Core組Debug版和Release版都提供,有的只提供Release版,不過對接的時候這方面影響不大,不妨礙功能的正常執行。

 

【項目總結】

>  結對編程意義

  • 結對編程能夠提升工做效率|軟件的內在複雜性決定了軟件開發必然是一個複雜的腦力勞動過程。在完成我的做業時,有時爲了急於完成任務,有了一點零星的想法就開始動工。因此上次就出現了因爲前期設計的方案不合理而致使後期代碼維護的噩夢。而在此次結對編程中,任何方案都是通過兩我的激烈的討論後產生的,這就有力的保證了設計和編碼的質量。好比在進行需求分析時,我主張使用MFC進行界面開發,而小夥伴主張使用Qt,激烈的討論以後最終選擇了使用Qt做爲咱們組的開發工具,事實也證實Qt是正確高效的選擇,由於Qt能夠跨平臺,並且IDE(Qt Creator)中的圖形界面編輯工具很是友好,大大提高了編程效率(不過Qt Creator在字符編碼上存在一些問題)。
  • 結對編程促進團隊建設|因爲結對編程組織性強,所以能夠有效地利用各類資源,進行最佳的組合。好比在這次結對編程中,我有Java的GUI開發經驗,而個人小夥伴對C++相對較熟,所以咱們兩個上手Qt Creator很快。經過結對編程,咱們倆的磨合速度很快,並且也很好的促進額團隊中的溝通交流。在這樣的團隊裏,你們都樂意互相協做,一塊兒分享知識,分享快樂。

 

>  流程改善|團隊項目流程完善

  • 若是是一個團隊進行軟件開發,那麼能夠將軟件的開發分爲若干個部分,而每一個部分由若干個2人小組共同開發。固然也不是全部的開發流程都須要結對編程,若是子項目的難度較低,那麼單人開發便可。
  • 好比咱們的團隊項目主要分爲前端開發和後端開發,那麼前端開發和後端開發中較難的開發部分能夠用結對編程進行解決,而相對較簡單的開發部分就由我的能力相對較強的同窗完成。

 

>  結對編程應用|工做崗位

  • 走上工做崗位後,會選擇結對編程用於解決部分任務。
  • 當軟件公司在新員工加入時,通常都會有一段時間的培訓,不少軟件公司也會簡歷本身的知識庫,看是不少新員工在面臨實際的項目時仍然會不知所措,培訓的效果微乎其微。而結對編程則會讓新員工有機會與有經驗的老員工一塊兒共事,新員工學到的不只是一些技術和技巧,更多的是他們思考問題,解決問題的方式。
  • 軟件攻擊比較容易出現人員流動的問題,特別是老員工的離去,意味着公司多年的技術和業務積累的流失。而在結對編程的團隊中,經過結對編程和結對夥伴的交換,知識再也不是掌握在一我的的手中,而是整個團隊一塊兒共享。經過結對編程使公司的人員,技術和業務處於很是穩定的狀態。

 

【課程意見】

  • 項目博客要求以及課後做業內容偏多,考慮到學生課餘時間有限,我以爲能夠適當減小博客,課後做業內容要求,經過量的減小來換取質量的提升。
  • 讀書筆記能夠取消評分制度,由於讀書筆記主要是寫給本身看的,本身有收穫就好,他人的評分雖然可能會起到督促做用,可是收效甚微。
相關文章
相關標籤/搜索