Java代碼評審都是怎么開展的呢？

1，代碼評審可以幫我們提高代碼質量，實質上就是一群人沒事找找刷刷存在感。

2，代碼評審可以提高產品的拓展質量。

3，項目外包的代碼別提有多爛，外包公司只負責功能開發，不負責后期，所以很短的時間很難磨礪出來好的輪子。

4，代碼審查可以提高我們程序設計邏輯能力，代碼規范。

5，代碼要經過黑盒測試，掃描代碼安全漏洞。

為什么要做Java代碼評審？

常見的代碼規范：

阿里巴巴開發手冊，阿里代碼掃描工具。這兩個是常用的代碼規范工具吧，畢竟某廠996也是來源至此。（大型互聯網公司都有自己的代碼自檢工具，和規范，不同公司的規范是不一樣）

常見的代碼規范：我們代碼層面面向對象設計思想遵循，設計模式的原則就是最大的規范。（設計模式可以幫我做程序拓展，大大提高了代碼的移植和拓展，設計思想有多重要，百分之70程序員其實都不是很清楚，就只會面向百度編程，復制粘貼.......）

設計模式六大原則

開閉原則（Open Close Principle）

開閉原則就是說對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程序的擴展性好，易于維護和升級。想要達到這樣的效果，我們需要使用接口和抽象類，后面的具體設計中我們會提到這點。

里氏代換原則（Liskov Substitution Principle）

里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。

封裝 繼承 多態 重寫（模版方法設計模式中） 接口、抽象類

依賴倒轉原則（Dependence Inversion Principle）

這個是開閉原則的基礎，具體內容：針對接口編程，依賴于抽象而不依賴于具體。

接口隔離原則（Interface Segregation Principle）

這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟件的設計思想，從大型軟件架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。

迪米特法則（最少知道原則）（Demeter Principle）

為什么叫最少知道原則，就是說：一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。

合成復用原則（Composite Reuse Principle）

原則是盡量使用合成/聚合的方式，而不是使用繼承。

數據庫三大范式規范：

1、第一范式：

當關系模式R的所有屬性都不能在分解為更基本的數據單位時，稱R是滿足第一范式的，簡記為1NF。滿足第一范式是關系模式規范化的最低要求，否則，將有很多基本操作在這樣的關系模式中實現不了。

2、第二范式：

如果關系模式R滿足第一范式，并且R的所有非主屬性都完全依賴于R的每一個候選關鍵屬性，稱R滿足第二范式，簡記為2NF。

3、第三范式：

設R是一個滿足第一范式條件的關系模式，X是R的任意屬性集，如果X非傳遞依賴于R的任意一個候選關鍵字，稱R滿足第三范式，簡記為3NF。

服務器規范：

1，命令規范，必要權限控制，怕你使用rm -rm 像這樣的命令是很恐怖的。

2，權限規范，根據用戶分配不同權限，由專業的運維人員管理。

3， 越是安全等級高的服務器，越要嚴格劃分權限等級。

其實最恐怖的的是數據泄密規范，數據的泄密是屬于重大事故，國外對數據安全把控特別嚴格，國內也是特別重視數據的泄密操作，這也是你必須簽署保密協議，安全協議，就連開發都是涉密開發，涉密開發都還是一套安全機制的策略。

代碼評審屬于必不可少的環節，代碼審查是分析現有代碼存在的一些問題，規范代碼。

代碼審查的流程：

1,選擇代碼分支發起codeview。（一般代碼自檢工具都已經幫我們做了很多事）

2,代碼審查開始進行評審。

參與代碼審查會議，根據代碼核心功能，代碼實現，代碼用法，后期擴展，代碼規范，讀代碼。

一行一行審查代碼，哪里不妥。

3，代碼審查修改，再發起codeview,最后敲定版本進行代碼驗收。

看完你覺得代碼審查簡單嗎？代碼審查其實是部署階段一個很重要的環節，對此你怎么看？