Alpha代碼規範、衝刺任務與計劃

Alpha代碼規範、衝刺任務與計劃

團隊名稱: 雲打印
做業要求: Alpha代碼規範、衝刺任務與計劃
做業目標:代碼規範、衝刺任務與計劃。

團隊隊員

隊員學號	隊員姓名	我的博客地址	備註
221600412	陳宇	http://www.cnblogs.com/chenyuu/	隊長
221600411	陳迎仁	https://www.cnblogs.com/yinen/
221600409	蔡森林	https://www.cnblogs.com/csl8013/
221600401	陳詩嫺	https://www.cnblogs.com/orangepoem/
221600408	蔡鴻鍵	https://www.cnblogs.com/jichiwoyaochi/

---

代碼規範

後端採用Springboot編寫 java代碼規範我一直是用阿里雲java開發手冊上的要求。（有些瀏覽器可能不支持pdf在線預覽，那就只能直接下載,我正常使用的都是Google瀏覽器）
阿里巴巴Java開發手冊記念版.pdf在線預覽

代碼規範參考阿里巴巴Java開發手冊記念版：

1、命名風格

【強制】代碼中的命名均不能如下劃線或美圓符號開始，也不能如下劃線或美圓符號結束。
反例：_name / name / $name / name_ / name$ / name
【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不容許直接使用中文的方式。
說明：正確的英文拼寫和語法可讓閱讀者易於理解，避免歧義。注意，即便純拼音命名方式也要避免採用。國際通用的名稱，可視同英文。
反例：DaZhePromotion [打折] / getPingfenByName() [評分] / int 某變量 = 3
【強制】類名使用 UpperCamelCase 風格，但如下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
【強制】方法名、參數名、成員變量、局部變量都統一使用 lowerCamelCase 風格，必須聽從駝峯形式。
正例： localValue / getHttpMessage() / inputUserId
【強制】常量命名所有大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。
正例：MAX_STOCK_COUNT
反例：MAX_COUNT
【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類 命名以它要測試的類的名稱開始，以 Test 結尾。
【強制】包名統一使用小寫，點分隔符之間有且僅有一個天然語義的英語單詞。包名統一使用單數形式，可是類名若是有複數含義，類名可使用複數形式。
正例：應用工具類包名爲 com.alibaba.ai.core.util、類名爲 MessageUtils（此規則參考 spring 的框架結構）
【強制】杜絕徹底不規範的縮寫，避免望文不知義。
反例：AbstractClass「縮寫」命名成AbsClass；condition「縮寫」命名成 condi，此類隨 意縮寫嚴重下降了代碼的可閱讀性。
【推薦】爲了達到代碼自解釋的目標，任何自定義編程元素在命名時，使用盡可能完整的單詞組合來表達其意。
正例：在 JDK 中，表達原子更新的類名爲：AtomicReferenceFieldUpdater。
反例：變量 int a 的隨意命名方式。

2、代碼格式

【強制】大括號的使用約定。若是是大括號內爲空，則簡潔地寫成{}便可，不須要換行；若是是非空代碼塊則：
左大括號前不換行。
左大括號後換行。
右大括號前換行。
右大括號後還有 else 等代碼則不換行；表示終止的右大括號後必須換行。
【強制】if/for/while/switch/do 等保留字與括號之間都必須加空格。
【強制】採用 4 個空格縮進，禁止使用 tab 字符。

3、註釋規約

【強制】類、類屬性、類方法的註釋必須使用 Javadoc 規範，使用/**內容/格式，不得使用 // xxx 方式。
說明：在 IDE 編輯窗口中，Javadoc 方式會提示相關注釋，生成 Javadoc 能夠正確輸出相應註釋；在 IDE 中，工程調用方法時，不進入方法便可懸浮提示方法、參數、返回值的意義，提升閱讀效率。
【強制】全部的抽象方法（包括接口中的方法）必需要用 Javadoc 註釋、除了返回值、參數、異常說明外，還必須指出該方法作什麼事情，實現什麼功能。
說明：對子類的實現要求，或者調用注意事項，請一併說明。
【強制】全部的類都必須添加建立者和建立日期。
【強制】方法內部單行註釋，在被註釋語句上方另起一行，使用//註釋。方法內部多行註釋 使用/ */註釋，注意與代碼對齊。
【強制】全部的枚舉類型字段必需要有註釋，說明每一個數據項的用途。
【推薦】與其「半吊子」英文來註釋，不如用中文註釋把問題說清楚。專有名詞與關鍵字保持英文原文便可。
反例：「TCP鏈接超時」解釋成「傳輸控制協議鏈接超時」，理解反而費腦筋。
【推薦】代碼修改的同時，註釋也要進行相應的修改，尤爲是參數、返回值、異常、核心邏輯等的修改。
說明：代碼與註釋更新不一樣步，就像路網與導航軟件更新不一樣步同樣，若是導航軟件嚴重滯後，就失去了導航的意義。

前端代碼規範

一、變量名稱用先小寫後大寫命名，如：maxStudy
二、前後端數據變量一導致用後端命名方式
三、若在小範圍的命名變量中使用三個字母的命名，如：msg
四、避免使用不易理解的數字，用有意義的標識來替代。涉及物理狀態或者含有物理意義的常量，不該直接使用數字，必須用有意義的靜態變量來代替。
五、不要使用難懂的技巧性很高的語句，除非頗有必要時。說明：高技巧語句不等於高效率的程序，實際上程序的效率關鍵在於算法。
六、css、js語句代碼後加「 ; 」斷句
七、使用空行來分割邏輯

衝刺任務與計劃（含衝刺總結）

任務	內容	時間
第一天	閱讀代碼規範，安裝相應的環境	4.24
次日	完成微信小程序登陸受權	4.25
第三天	完成微信小程序上傳文件	4.26
第四天	完成後臺計算頁數	4.27
第五天	學習微信支付接口	4.28
第六天	完成小程序微信支付接口	4.29
第七天	後端和小程序和微信支付對接	4.30
第八天	完成商家端接單和查看訂單	5.1
第九天	整合代碼，測試程序	5.2
第十天	發佈Alpha版本程序	5.3
第十一天	發佈一篇衝刺總結隨筆，描述項目預期計劃、現實進展、過程體會、組員分工及在Alpha階段的工做量比例、下階段展望。	5.4