團隊做業第二週

團隊做業第二週

——油條只要半根

---

團隊博客總目錄：團隊做業第一週 團隊做業第二週

---

需求規格說明書

• 上次的《需求規格說明書》初稿有哪些不足？
• 上週是小組做業開始的第一週，咱們對項目的理解還不夠充分，你們的思路也沒有可以很好地整理出來，因此寫出來的《需求規格說明書》也有不少的不足。
  像是格式不對，沒有和碼雲或GitHub連接上，只是用簡單的話說明了咱們要開發的這個項目所要實現的功能和一些約束。
• 本週對《需求規格說明書》作出的修改：
• 1.《需求規格說明書》按要求實現了Markdown格式的編寫
  Markdown格式
  2.本週的《需求規格說明書》更加的完善，繪製了咱們所要完成APP的功能介紹圖。
  3.參考其餘標準的《需求規格說明書》，描寫了具體用戶的使用場景和用戶需求分析
  

碼出高效——小組代碼規範

編程規約

一.命名風格

• 1.代碼中的命名不能如下劃線、美圓符號開頭或結尾。

  反例：_name/$name/name&/name_

• 2.【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不容許直接使用中文的方式。 說明：正確的英文拼寫和語法可讓閱讀者易於理解，避免歧義。注意，即便純拼音命名方式
  也要避免採用。

  正例：name/age/address等國際通用的可使用。 反例：mingzi/getNiJi()/dizhi等不可以使用。

• 3.【強制】類名使用 UpperCamelCase 風格，即首字母大寫。

  正例：MyBase/ViewPager/ViewPagerAdpter 反例：mybaseiewpageriewpageradpter

• 4.【強制】方法名、參數名、成員變量、局部變量都統一使用 lowerCamelCase 風格，必須聽從
  駝峯形式。

  正例：myBase/getMessage()iewPager

• 5.【強制】常量命名所有大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。

  正例：MAX_STOCK_COUNT 反例：MAX_COUNT

• 6.【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類
  命名以它要測試的類的名稱開始，以 Test 結尾。

  正例：AbstractAnimals/NotfoundException

1. 【強制】類型與中括號緊挨相連來表示數組。

   正例：定義整形數組 int[] arrayDemo; 反例：在 main 參數中，使用 String args[]來定義。

• 8.【參考】各層命名規約： - 獲取單個對象的方法用 get 作前綴。
  • 獲取多個對象的方法用 list作前綴，複數形式結尾如：listObjects。
  • 獲取統計值的方法用 count 作前綴。
  • 插入的方法用 save/insert 作前綴。
  • 刪除的方法用 remove/delete 作前綴。

  • 修改的方法用 update 作前綴。

    二.常量定義

• 1.【強制】不容許任何魔法值（即未經預先定義的常量）直接出如今代碼中。

• 2.【強制】在 long 或者 Long 賦值時，數值後使用大寫的

  L，不能是小寫的 l，小寫容易跟數字
  1 混淆，形成誤解。
  說明：Long a = 2l; 寫的是數字的 21，仍是 Long 型的 2?

  三.代碼格式

• 1.【強制】大括號的使用約定。若是是大括號內爲空，則簡潔地寫成{}便可，不須要換行；若是
  是非空代碼塊則： - 左大括號前不換行。
  • 左大括號後換行。
  • 右大括號前換行。
  • 右大括號後還有 else 等代碼則不換行；表示終止的右大括號後必須換行。
• 2.【強制】if/for/while/switch/do 等保留字與括號之間都必須加空格。
• 3.【強制】註釋的雙斜線與註釋內容之間有且僅有一個空格。
• 4.【強制】任何二目、三目運算符之間必須加一個空格。

• 5.採用四個空格縮進、嚴謹使用tab鍵縮進！

  舉例：

public static void main(String[] args) {
// 縮進 4 個空格
String say = "hello";
// 運算符的左右必須有一個空格
int flag = 0;
// 關鍵詞 if 與括號之間必須有一個空格，括號內的 f 與左括號，0 與右括號不須要空格
if (flag == 0) {
System.out.println(say);
}

// 左大括號前加空格且不換行；左大括號後換行
if (flag == 1) {
System.out.println("world");
// 右大括號前換行，右大括號後有 else，不用換行
} else {
System.out.println("ok");
// 在右大括號後直接結束，則必須換行
}
}

• 6.【強制】註釋的雙斜線與註釋內容之間有且僅有一個空格。

// 這是示例註釋，請注意在雙斜線以後有一個空格
String ygb = new String();

• 7.【強制】方法參數在定義和傳入時，多個參數逗號後邊必須加空格。

// 下例中實參的 args1，後邊必需要有一個空格。
method(args1, args2, args3);

• 8.【推薦】沒有必要增長若干空格來使某一行的字符與上一行對應位置的字符對齊。

// 反例：
int aa = 1;
int bb = 2;
int  c = 3;// 不必爲了等號對齊而多添加空格。

四.控制語句

• 1.【強制】在一個 switch 塊內，每一個 case 要麼經過 break/return 等來終止，要麼註釋說明程
  序將繼續執行到哪個 case 爲止；在一個 switch 塊內，都必須包含一個 default 語句而且
  放在最後，即便空代碼。
• 2.【強制】在 if/else/for/while/do 語句中必須使用大括號。即便只有一行代碼，避免採用
  單行的編碼方式：if (condition) statements;

五.註釋語句

• 1.【強制】類、類屬性、類方法的註釋必須使用 Javadoc 規範，使用/**內容*/格式，不得使用
  // xxx 方式。

• 2.【強制】全部的抽象方法（包括接口中的方法）必需要用 Javadoc 註釋、除了返回值、參數、
  異常說明外，還必須指出該方法作什麼事情，實現什麼功能。

  說明：對子類的實現要求，或者調用注意事項，請一併說明。

• 3.【強制】全部的類都必須添加建立者和建立日期。

  安全規則

• 【強制】用戶敏感數據禁止直接展現

  例一：中國大陸我的手機號碼顯示爲:158****9119，隱藏中間 4 位，防止隱私泄露。 例二：密碼不能被看到,例如********。

  參考資料

  本文參考《阿里巴巴java開發手冊》

代碼規範理由：碼出高效，碼出質量

前言：

當今軟件的複雜性要求了須要協同開發完成。無規矩不成方圓，無規範難以協同。對於開發一個APP，適當的規範和標準絕對不是消滅代碼內容的創造性、優雅性，而是限度過分的個性化，以一種廣泛承認的同一方式一塊兒作事，提高協做效率、下降溝通成本。

爲何要代碼規範？

• 規範的代碼能夠促進團隊合做。
• 規範的代碼能夠減小bug處理。
• 規範的代碼能夠下降維護的成本。
• 規範的代碼有助於代碼的審查。
• 養成寫規範代碼的習慣，有助咱們的成長。

聯繫自身

對於咱們團隊的五我的，有不少知識都是先前沒有學到的。各部分都是由團隊中的一我的寫的，其餘人爲了項目相關的對接、學習相關知識，必然會閱讀到他人寫的代碼，所以代碼的規範就顯得很是重要！固然，寫規範的代碼不只僅是爲了他人的閱讀，更重要的是爲了本身之後複習~

數據庫設計

• 什麼是數據庫設計？
  

• Powerdesigner完成的數據庫設計

• ER圖（實體聯繫模型）
  

後端架構設計

• 用戶登陸時使用的後端架構
  

• 在用戶登入APP後，會有四種不一樣類型的任務來讓用戶選擇。用戶能夠根據本身的實際狀況來對任務做出合理的選擇。
  用戶在選定任務以後會進入相關任務的界面，用戶能夠了解該任務的相關信息，如：具體內容、限定時間等。。
  用戶能夠查看本身的積分值，並自由支配本身的積分值
  用戶能夠設置本身我的的相關信息。

  團隊分工

• 優先級
  

• 版本需求
  

• WBS圖
  

• TODOList實現的燃盡圖
  

由於安裝的時候沒有配置，因此這周的燃盡圖沒有辦法設置開始時間，因此在最後是一天之間未完成的任務就結束了。

組員的分工和工做量比例。

總的項目分工

本週任務的分工

• 侯澤洋：肯定UI框架，初步實現獎勵頁面（使用文件存儲）
• 周亞傑：登陸界面雛形，實現微信受權登陸的相關資料查找和實踐
• 王志偉：引導頁面框架（完成），數據庫基礎
• 仇夏：APP用戶登陸註冊的實現（使用不可逆加密算法在APP中存儲用戶及相應密碼）
• 唐才銘：APP啓動界面實現（後續會繼續更改優化），需求規格說明書修改

參考資料

• Github項目生成燃盡圖的方式
• 《阿里巴巴java開發手冊》