團隊任務電子公文傳輸系統
團隊作業（三）：確定分工
項目名：電子公文傳輸系統
成員：20191331劉宇軒、20191303姜淳譯、20191305李天琦、20191311陳之韜、20191318王澤文
撰寫：劉宇軒
日期：2021.10.31
一、《需求規格說明書》修改：
-
分層形式描述不夠具體清晰，沒有做到逐層深入，缺少目錄。
目錄：
1.引言
1.1使用說明 1.2背景2.用戶場景
3.類圖
4.界面原型
5.功能描述
5.1用戶功能 5.2系統管理員功能 5.3數據庫管理員 5.4安全審計員 5.5系統功能補充6.驗收驗證標准
-
未描述成員具體分工和工作量比例。
-
上次制定的需求規格說明書中部分內容實現起來較為困難且冗余，我們刪除了管理員字號管理功能。
更新后的《需求規格說明書》：https://gitee.com/vegetable-dogggg/docsys/blob/master/規格需求說明書v2.md
二、代碼規范和編碼
團隊的編碼規范：
1.代碼風格規范
代碼風格的原則是：簡單，易讀，無二義性。包括縮進、行寬、括號等。
-
縮進：將Tab鍵擴展定義為4個空格。不使用tab鍵的原因是它在不同的情況下會顯示不同的長度。使用空格可讀性高。
-
行寬：行寬限制為100字符。
-
括號：在復雜的條件表達式中，用括號清楚地表示邏輯優先級；左右小括號和字符之間不能出現空格。
-
斷行與空白的{}行：每個｛和｝都單獨占一行，互為一對的{和}要位於同一列，並且與引用它們的語句左對齊。
-
代碼行：if、else、for、while、do 等語句自占一行。不論執行語句有多少行，就算只有一行也要加{}，並且遵循對齊的原則。
-
命名：
-
代碼中的命名只能由字母、數字、下划線組成；不能以下划線或美元符號開始，也不能以下划線或美元符號結束。
-
命名不能直接使用中文。
-
不可以是系統的關鍵詞比如if、else等。
-
常量命名全部大寫，單詞用下划線隔開。
-
-
注釋：保證代碼與注釋的一致性，要簡潔明了，注釋的雙斜線與注釋內容之間有且僅有一個空格復雜的注釋放在函數頭，注釋中應只使用ASCII字符。
2.代碼設計規范
-
函數：
-
一個函數最好僅完成一件功能，多調用為簡單功能編寫函數。
-
函數的功能應該是可以預測的，也就是只要輸入數據相同就應產生同樣的輸出。
-
避免設計多參數函數，不使用的參數從接口中去掉。
-
檢查函數所有參數輸入的有效性與作用。
-
函數名應准確描述函數的功能，便於查找和修改。
-
明確函數功能。
-
-
變量：
-
去掉沒必要的公共變量。
-
構造僅單一模塊或函數可以修改、創建的公共變量，防止多個不同模塊或函數都可以修改、創建同一公共變量的現象。
-
定義並明確公共變量的含義、作用、取值范圍及公共變量間的關系。明確公共變量與操作此公共變量的函數或過程的關系，如訪問、修改及創建等。
-
當向公共變量傳遞數據時，要十分小心，防止賦與不合理的值或越界等現象發生。
-
局部變量與公共變量不能同名。
-
嚴禁使用未經初始化的變量。聲明變量同時對變量進行初始化。
-
注意數據類型的強制轉換。
-
-
編寫：
-
注意隨時保存與備份避免代碼丟失。
-
使用相同編輯器與選項設置。
-
編寫代碼過程中互相幫助，隨時找出代碼中的錯誤並進行改進，相互學習。
-
三、通過Powerdesigner完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖。
四、進行項目的后端架構設計，要與需求規格說明書中的界面原型設計相對應。
五、確定團隊分工。請參考"分而治之(WBS - Work Breakdown Structure)"，提供下述內容。
相應的WBS圖：
象限法分析核心需求：
當前核心任務TODOList：
燃盡圖：
六、描述組員在本次任務中的分工和工作量比例。
正在編篡。