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

標籤：Java

上一篇：Java連載119-反編譯類的某個方法已經構造方法

下一篇：被纏上了，小王問我怎么在 Spring Boot 中使用 JDBC 連接 MySQL