Java生鮮電商平臺-生鮮系統代碼審查以及優化方案(小程式/APP)

說明：Java生鮮電商平臺-生鮮系統代碼審查以及優化方案(小程式/APP)

           代碼審查也就是我們常說的：CodeReview，常見的生鮮電商小程式或者APP中CodeReview有以下的規範與目標：

         1. 目標和原則

1. 提高代碼質量，及早發現潛在缺陷，降低修改/彌補缺陷的成本
2. 促進團隊內部知識共用，提高團隊整體水平
3. 評審過程對於評審人員來說，也是一種思路重構的過程，幫助更多的人理解系統
4. 是一個傳遞知識的手段，可以讓其它並不熟悉代碼的人知道作者的意圖和想法，從而可以在以後輕鬆維護代碼
5. 可以被用來確認自己的設計和實現是一個清楚和簡單的
6. 鼓勵相互學習對方的長處和優點
7. 高效迅速完成Code Review

          2. 代碼審查清單 

        Code Review主要檢查代碼中是否存在以下方面問題：代碼的一致性、編碼風格、代碼的安全問題、代碼冗餘、是否正確設計以滿足需求（功能、性能）等等

• 完整性檢查代碼是否完全實現了設計文檔中提出的功能需求代碼是否已按照設計文檔進行了集成和Debug代碼是否已創建了需要的資料庫，包括正確的初始化數據代碼中是否存在任何沒有定義或沒有引用到的變數、常數或數據類型
• 一致性檢查代碼的邏輯是否符合設計文檔代碼中使用的格式、符號、結構等風格是否保持一致
• 正確性檢查代碼是否符合制定的標準所有的變數都被正確定義和使用所有的註釋都是準確的所有的程式調用都使用了正確的參數個數
• 可修改性檢查代碼涉及到的常量是否易於修改(如使用配置、定義為類常量、使用專門的常量類等)代碼中是否包含了交叉說明或數據字典，以描述程式是如何對變數和常量進行訪問的代碼是否只有一個出口和一個入口（嚴重的異常處理除外）
• 可預測性檢查代碼所用的開發語言是否具有定義良好的語法和語義是否代碼避免了依賴於開發語言預設提供的功能代碼是否無意中陷入了死迴圈代碼是否是否避免了無窮遞歸
• 健壯性檢查異常處理和清理（釋放）資源代碼是否採取措施避免運行時錯誤（如數組邊界溢出、被零除、值越界、堆棧溢出等）
• 結構性檢查程式的每個功能是否都作為一個可辯識的代碼塊存在迴圈是否只有一個入口
• 可追溯性檢查代碼是否對每個程式進行了唯一標識是否有一個交叉引用的框架可以用來在代碼和開發文檔之間相互對應代碼是否包括一個修訂歷史記錄，記錄中對代碼的修改和原因都有記錄是否所有的安全功能都有標識
• 可理解性檢查註釋是否足夠清晰的描述每個子程式是否使用到不明確或不必要的複雜代碼，它們是否被清楚的註釋使用一些統一的格式化技巧（如縮進、空白等）用來增強代碼的清晰度是否在定義命名規則時採用了便於記憶，反映類型等方法每個變數都定義了合法的取值範圍代碼中的演算法是否符合開發文檔中描述的數學模型
• 可驗證性檢查代碼中的實現技術是否便於測試
• 可重用性DRY（Do not Repeat Yourself）原則：同一代碼不應該重覆兩次以上考慮可重用的服務，功能和組件考慮通用函數和類
• 可擴展性輕鬆添加功能，對現有代碼進行最小的更改。一個組件可以被更好的組件替換
• 安全性進行身份驗證，授權，輸入數據驗證，避免諸如SQL註入和跨站腳本（XSS）等安全威脅 ，加密敏感數據（密碼，信用卡信息等）
• 性能使用合適的數據類型，例如StringBuilder，通用集合類懶載入，非同步和並行處理緩存和會話/應用程式數據

         代碼檢查包括不局限於上述清單，提交人應在本地自我完成代碼格式、架構設計、面向對象分析與設計等檢查。備註：

• Java服務端開發必須遵循阿裡巴巴Java開發手冊（終極版）,IDEA中安裝相關插件有告警提示不允許提交合併

      3.Code Review的步驟

1. 代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UC依次講解自己負責的代碼和相關邏輯，從Web層->DAO層；
2. 代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發現隱藏的bug；對這些bug記錄在案。
3. 代碼講解完畢後，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要一行一行靜下心看。同時代碼又要全面的看，以確保代碼整體上設計優良。
4. 代碼審核者根據審核的結果編寫“代碼審核報告”，“審核報告”中記錄發現的問題及修改建議，然後把“審核報告”發送給相關人員。
5. 代碼編寫者根據“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。
6. 代碼編寫者 bug fix完畢之後給出反饋。
7. 代碼審核者把Code Review中發現的有價值的問題更新到"代碼審核規範"的文檔中，對於特別值得提醒的問題可群發email給所有技術人員。

備註：Code Review必備的文檔：“Code Review規範”文檔：記錄代碼應該遵循的標準。代碼審核者根據這些標準來Code Review代碼，同時在Code Review過程中不斷完善該文檔。

4.Code Review的執行

準備階段

1. 評審規範和標準
2. 在CR前設計確定評審規範和標準是必要，通過規範和標準我們在審查過程中可以有據可依，有理可循，而且還可以做到標準統一。
3. 選擇CR活動的參與者
4. 在CR開始前，必須把本次CR活動的對象、審查內容以及審查的規範和標準通過email通報給所有的參與者。
5. 選擇CR活動的實施方式
6. CR活動有很多形式可供我們選擇，我們可以根據實際情況選擇桌面式CR、演示講解式CR、一對一的座位CR等等。(一般按新增功能桌面式CR、里程碑功能演示講解式CR、BUG修複一對一的座位CR)

5.實施階段

充分的事前準備，只是做好CR活動的前提，在CR實施過程中，我們要做好以下工作。

1. 準確記錄
2. 對於CR過程發現的問題，我們必須清晰準確的記錄，可以使用問題點記錄單，明確記錄的項目和內容。
3. 講解與提問
4. CR過程中，要採用代碼作者講解和審查者提問方式。審查者不能只在發現問題時提問，同時也要根據本次審查的內容要求代碼作者對某個特定問題的講解。
5. 逐項審查
6. 對事前確定的審查內容，要逐項審查，不能因為時間不足等因素一掃而過。
7. 註意氣氛
8. 實施審查時，要營造一個討論問題、解決問題的氛圍，不能把審查會搞成批判會，這樣會影響相關人員的積極性。

6.事後跟蹤

1. 確認發現的問題 CR結束後，對發現的問題，首先需要確定以下內容。
2. 問題點的難易程度以及影響的範圍；
3. 解決問題的責任者和問題點修正結果的確認者；
4. 解決問題點的時限。
5. 修正問題責任者 對於修正問題責任者，在問題點的修正過程中，要三方面內容的記錄。問題點的原因；
6. 解決問題點的對策；
7. 修正的內容。

修正結果確認者做為修正結果的確認者，必須按照事前約定的時限及時的對修正結果進行全面的確認

7.註意事項

• 經常進行Code Review

（1）要Review的代碼越多，那麼要重構，重寫的代碼就會越多。而越不被程式作者接受的建議也會越多，唾沫口水戰也會越多。（2）程式員代碼寫得時候越長，程式員就會在代碼中加入越來越多的個人的東西。 （3）越接近軟體發佈的最終期限，代碼也就不能改得太多。

• Code Review不要太正式，而且要短

忘了那個代碼評審的Checklist吧，走到你的同事座位跟前，像請師父一樣請他坐到你的電腦面前，然後，花5分鐘給他講講你的代碼，給他另外一個5分鐘讓他給你的代碼提提意見，這比什麼都好。而如果你用了一個Checklist，讓這個事情表現得很正式的話，下麵兩件事中必有一件事會發生：（1）只有在Checklist上存在的東西才會被Review。（2）Code Reviews 變成了一種禮節性的東西，你的同事會裝做很關心你的代碼，但其實他心裡想著儘快地離開你。只有不正式的Code Review才會讓你和評審者放輕鬆，人只有放鬆了，才會表現得很真實，很真誠。記住Review只不過是一種形式，而只有在相互信任中通過相互的討論得到了有意義和有建設性的建議和意見，那才是最實在的。不然，作者和評審者的關係就會變成小偷和警察的關係。

• 儘可能的讓不同的人Review你的代碼

如果可能的話，不要總是只找一個人來Review你的代碼，不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個方面評論你的代碼。但不要太多了，人多嘴雜反而適得其反，基本上來說，不要超過3個人，這是因為，這是一個可以圍在一起討論的最大人員尺寸。 下麵是幾個優點：（1）從不同的方向評審代碼總是好的。（2）會有更多的人幫你在日後維護你的代碼。（3）這也是一個增加團隊凝聚力的方法。

• 保持積極的正面的態度

程式員最大的問題就是“自負”，尤其當我們Review別人的代碼的時候，我已經見過無數的場面，程式員在Code Review的時候，開始抨擊別人的代碼，質疑別人的能力。太可笑了，我分析了一下，這類的程式員其實並沒有什麼本事，因為他們指責對方的目的是想告訴大家自己有多麼的牛，靠這種手段來表現自己的程式員，其實是就是傳說中所說的“半瓶水”。 所以，無論是代碼作者，還是評審者，都需要一種積極向上的正面的態度，作者需要能夠虛心接受別人的建議，因為別人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態度向作者提意見，因為那是和你在一個戰壕里的戰友。記住，你不是一段代碼，你是一個人！

• 學會享受Code Review

這可能是最重要的一個提示了，如果你到了一個人人都喜歡Code Review的團阿，那麼，你會進入到一個生機勃勃的地方，在那裡，每個人都能寫出質量非常好的代碼，在那裡，你不需要經理的管理，團隊會自適應一切變化，他們相互學習，相互幫助，不僅僅是寫出好的代碼，而且團隊和其中的每個人都會自動進化，最關鍵的是，這個是一個團隊。

 QQ:137071249

共同學習QQ群：793305035