團隊做業（三）：肯定分工

團隊做業（三）：肯定分工

需求說明書的修改

本週對上週的規格需求說明書進行了完善和修改。

• 對說明書中不規範的地方進行修改。
  • 修改了第一頁文字不能對齊的問題，讓其更整齊美觀。
  • 對說明書中的錯別字進行修改，對一些描述方式修改，讓其更嚴謹。
  • 對錶格中格式問題進行修改。
• 對說明書內容修改。
  • 對開發背景進行完善，讓用戶能充分了解開發目的。
  • 對出錯的界面原型進行修改，另增長了獲取密鑰的選項。
  • 對功能進行優化，將重複的功能進行整合。

團隊的編碼規範和編碼原則

• 程序風格：
  • 嚴格採用階梯層次組織程序代碼：每層次縮進爲4格，括號位於下一行。要求相匹配的大括號在同一列，對繼行則要求再縮進4格
  • 提示信息字符串的位置：在程序中須要給出的提示字符串，爲了支持多種語言的開發，除了一些給調試用的臨時信息外，其餘全部的提示信息必須定義在資源中。
  • 對變量的定義，儘可能位於函數的開始位置。
• 變量名的命名規則：
  • 只能由字母、數字、下劃線組成
  • 第一個字符必須是英文字母
  • 有效長度爲255個字符
  • 不能夠包含標點符號和類型說明符%,&,!,# ,@,$
  • 不能夠是系統的關鍵詞好比else
• 註釋
  • 註釋要簡單明瞭
  • 邊寫代碼邊註釋，修改代碼同時修改相應的註釋，以保證 註釋與代碼的一致性
  • 在必要的地方註釋，註釋量要適中，註釋的內容要清楚，明瞭，含義準確，防止註釋二義性，保持註釋與其描述的代碼相鄰，即註釋的就近原則
  • 對代碼的註釋應放在其上方相鄰位置，不可放在下面
  • 全局變量要有較詳細的註釋，包括對其功能、取值範圍、哪些函數或過程存取它以及存取時注意事項等的說明
  • 在每一個函數或過程的前面要有必要的註釋信息，包括：函數或過程名稱；功能描述
  • 輸入，輸出及返回值說明；調用關係及被調用關係說明等
• 可讀性
  • 避免使用不易理解的數字，用有意義的標識來替代
  • 不要使用難懂的技巧性很高的語句
  • 源程序中關係較爲緊密的代碼應儘量相鄰
• 函數，過程
  • 一個函數最好僅完成一件功能
  • 爲簡單功能編寫函數
  • 函數的功能應該是能夠預測的，也就是隻要輸入數據相同就應產生一樣的輸出　
  • 避免設計多參數函數，不使用的參數從接口中去掉
  • 用註釋詳細說明每一個參數的做用、取值範圍及參數間的關係
  • 檢查函數全部參數輸入的有效性
  • 函數名應準確描述函數的功能
  • 函數的返回值要清楚、明瞭，讓使用者不容易忽視錯誤狀況
  • 明確函數功能，精確（而不是近似）地實現函數設計
• 變量編輯
  • 去掉不必的公共變量
  • 構造僅有一個模塊或函數能夠修改、建立，而其他有關模塊或函數只訪問的公共變量，防止多個不一樣模塊或函數均可以修改、建立同一公共變量的現象
  • 仔細定義並明確公共變量的含義、做用、取值範圍及公共變量間的關係
  • 明確公共變量與操做此公共變量的函數或過程的關係，如訪問、修改及建立等
  • 當向公共變量傳遞數據時，要十分當心，防止賦與不合理的值或越界等現象發生
  • 防止局部變量與公共變量同名
  • 仔細設計結構中元素的佈局與排列順序，使結構容易理解、節省佔用空間，並減 少引發誤用現象
  • 結構的設計要儘可能考慮 向前兼容和之後的版本升級，併爲某些將來可能的應用保留餘地（如預留一些空間等）
  • 留心具體語言及編譯器處理不一樣數據類型的原則及有關細節
  • 嚴禁使用未經初始化的變量，聲明變量的同時對變量進行初始化
  • 編程時，要注意數據類型的強制轉換
• 代碼編譯
  • 編寫代碼時要注意隨時保存，並按期備份，防止因爲斷電、硬盤損壞等緣由形成代碼丟失
  • 同一項目組內，最好使用相同的編輯器，並使用相同的設置選項
  • 打開編譯器的全部告警開關對程序進行編譯

ER圖

項目的後端架構設計

肯定團隊分工

• WBS圖
  

• 燃盡圖
  

組員在上述任務中的分工和工做量比例

學號	姓名	負責工做
20175217	吳一凡	團隊項目的數據庫設計
20175210	閔天	項目的後端架構設計
20175205	侯穎	燃盡圖
20175225	張元瑞	完善需求規格說明書及制定編碼規範
20175226	王鵬雲	WBS圖