======================================================================================javascript
====================================PHP編碼規範=======================================
======================================================================================php
PSR（PHP Standard Recommendations，PHP標準規範） 是由PHP FIG組織制定的PHP規範，是PHP開發的實踐標準。主要包含基礎編碼規範、編碼風格規範、日誌接口規範、緩存接口規範、HTTP消息接口規範等。css
1. 【必須】代碼必須使用4個空格符而不是「Tab 鍵」進行縮進。使用空格而不是「tab鍵縮進」的好處在於， 避免在比較代碼差別、打補丁、重閱代碼以及註釋時產生混淆。 而且，使用空格縮進，讓對齊變得更方便。
2. 【必須】類的屬性和方法必須添加訪問修飾符（private、protected 以及 public），abstract 以及 final 必須聲明在訪問修飾符以前，而 static 必須聲明在訪問修飾符以後。
3. 【必須】PHP全部關鍵字必須所有小寫。常量 true 、false 和 null 也 必須 所有小寫。
4. 【不應】類的屬性和方法不應使用下劃線做爲前綴，來區分是 protected 或 private。html
目錄和文件
目錄使用小寫+下劃線。（參考linux目錄命名，所有小寫，linux目錄單詞間沒有分隔符，如/var/spool/clientqueue,/etc/inittab,/bin/dnsdomainname等）
類的文件名均以命名空間定義，而且命名空間的路徑和類庫文件所在路徑一致。
類文件採用大駝峯法命名（首字母大寫），其它文件採用小寫+下劃線命名。
類名和類文件名保持一致，統一採用大駝峯法命名（首字母大寫）。前端
函數和類、屬性命名
類的命名採用大駝峯法（首字母大寫），例如 User、UserType，默認不須要添加後綴，例如UserController應該直接命名爲User。
函數的命名使用小寫字母和下劃線（小寫字母開頭）的方式，例如 get_client_ip。
方法的命名使用小駝峯法（首字母小寫），通常使用動詞+名詞的形式來描述該方法的功能，如sendMessage()發送短信，getUserName()獲取用戶名。
屬性的命名使用小駝峯法（首字母小寫），例如 tableName、instance。(屬性的類型能夠在phpdoc中標識，所以屬性名稱無需考慮類型前綴來標識，如 /** @var integer */ protected $sex=0;)
變量的命名使用小駝峯法（首字母小寫），建議在變量前加表示類型的前綴。例如 $intSex=0;$intLoginErrorCount=0。 (變量名稱沒法使用phpdoc，所以建議增長類型前綴標識)
以雙下劃線「__」打頭的函數或方法做爲魔術方法，例如 __call 和 __autoload。java
常量和配置
常量以大寫字母和下劃線命名，例如 APP_PATH,const TRANSACTION_TYPE = 'income', define('CURRENT_SCRIPT', 'index.php')。
配置參數以小寫字母和下劃線命名，例如 $config=array('url_route_on'=>true,'url_convert'=>array())。linux
詳情參考：
https://psr.phphub.org/
https://github.com/summerblue/psr.phphub.org/tree/master/psrs
https://www.kancloud.cn/manual/thinkphp5/118007
http://www.cfei.net/archives/51594git
======================================================================================
====================================Java編碼規範==========================================
======================================================================================github
變量標識符
1. 成員變量、局部變量使用lowerCamelCase風格（小駝峯法，首字母小寫），如：inputUserId。
2. 變量命名不能如下劃線或美圓符號開始，也不能如下劃線或美圓符號結束。
3. 嚴禁使用拼音和英文混合的方式，更不容許直接使用中文的方式來命名。純拼音命名方式也要避免使用，但國際通用的名稱可視同英文，如：taobao, alibaba,xiamen等。web
包
1. 包名統一用小寫，點分符號之間有且僅有一個天然語義的英語單詞。包名統一使用單數形式，但類名若有複數含義，類名能夠用複數形式。如：com.alibaba.open.util.MessageUtils。
類
1. 類名使用UpperCamelCase風格（大駝峯法，首字母大寫），如：XmlService, TcpUdpDeal, TaPromotion。
2. 抽象類命名使用Abstract或Base開頭。
3. 若是使用到了設計模式，建議在類名中體現出具體的模式，有利於閱讀者快速理解架構設計思想，如：public class OrderFactory; public class LoginProxy; public class ResourceObserver。
4. 對於Service和DAO類，基於SOA的理念，暴露出來的服務必定是接口，內部的實現類用Impl的後綴與接口區別，如：CacheServiceImpl實現CacheService接口。
枚舉 (Enum)
1. 枚舉類名建議帶上Enum後綴，如：DealStatusEnum。
2. 枚舉成員名稱須要全大寫，單詞間用下劃線隔開。（枚舉其實就是特殊的常量類，且構造方法被默認強制是私有）如：UNKNOW_REASON。
參數
1. 參數名使用lowerCamelCase風格（小駝峯法，首字母小寫），如：localValue。
方法
1. 方法名使用lowerCamelCase風格（小駝峯法，首字母小寫），如：getHttpMessage()。
常量 (const)
1. 常量命名所有大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。如：MAX_SOCKET_COUNT。
2. long或者Long初始賦值時，必須使用大寫的L，不能是小寫的l，小寫容易跟數字1混淆，形成誤解。如：Long a = 2l; 很難辨別寫的是數字的21仍是Long型的2。
異常類
1. 異常類命名使用Exception結尾。
測試類
1. 測試類命名要以它要測試的類的名稱開始，以Test結尾。
數組
1. 數組定義使用String[] args，不要使用String args[]的方式來定義。
POJO類
1. 布爾值的變量，都不要以加is前綴，不然部分框架解析會引發序列化錯誤，如：定義爲基本數據類型boolean isSuccess的屬性，它的方法也是isSuccess()，PRC框架在反向解析的時候，覺得對應的屬性名稱是success，致使屬性獲取不到，進而拋出異常。
各層命名規約：
A) Service/DAO 層方法命名規約
1） 獲取單個對象的方法用 get 作前綴。
2） 獲取多個對象的方法用 list 作前綴。
3） 獲取統計值的方法用 count 作前綴。
4） 插入的方法用 save（推薦）或 insert 作前綴。
5） 刪除的方法用 remove（推薦）或 delete 作前綴。
6） 修改的方法用 update 作前綴。
B) 領域模型命名規約
1） 數據對象：xxxDO，xxx 即爲數據表名。
2） 數據傳輸對象：xxxDTO，xxx 爲業務領域相關的名稱。
3） 展現對象：xxxVO，xxx 通常爲網頁名稱。
4） POJO 是 DO/DTO/BO/VO 的統稱，禁止命名成 xxxPOJO。
註釋規約：
1. 代碼修改的同時，註釋也要進行相應的修改，尤爲是參數、返回值、異常、核心邏輯等的修改。代碼與註釋更新不一樣步，就像路網與導航軟件更新不一樣步同樣，若是導航軟件嚴重滯後， 就失去了導航的意義。其實一些優秀的團隊在編寫代碼時默認是沒有任何註釋的，由於咱們追求的是 self-explanatory methods。即代碼自己已經就能說明它的用途。只有在不多的狀況下須要添加註釋。
2. 註釋掉的代碼儘可能要配合說明，而不是簡單的註釋掉。 （代碼被註釋掉有兩種可能性：1）後續會恢復此段代碼邏輯。2）永久不用。前者若是沒有備註信息，難以知曉註釋動機。後者建議直接刪掉（代碼倉庫保存了歷史代碼））
其餘規約：
1. 循環體內，字符串的聯接方式，使用 StringBuilder 的 append 方法進行擴展。（反編譯出的字節碼文件顯示每次循環都會new出一個StringBuilder對象，而後進行append操做，最後經過toString方法返回String對象，形成內存資源浪費）
2. 相同參數類型，相同業務含義，纔可使用Java的可變參數，避免使用Object。如：public User getUsers(String type, Integer... ids)。（儘可能不用可變參數編程）
3. 類成員與方法訪問控制從嚴，要嚴控類、方法、參數、變量的訪問範圍。過寬泛的訪問範圍不利於模塊解耦。思考：若是是一個 private 的方法，想刪除就刪除，但是一個 public 的 Service 方法，或者一個 public 的成員變量，刪除一下，不得手心冒點汗嗎？變量像本身的小孩，儘可能在本身的視線內，變量做用域太大，會無限制的處處跑，那麼你會擔憂的。
4. 接口類中的方法和屬性不要加任何修飾符號(public也不要加)，保持代碼的整潔性，並加上有效的Javadoc註釋。儘可能不要在接口中定義變量，若是必定要定義變量，確定是與接口方法相關，而且是整個應用的基礎常量，如：String COMPANY="alibaba";
5. 不要使用一個常量類維護因此常量，應該按常量功能進行歸類，分開維護。如：緩存相關的常量放在類：CacheConsts下，系統配置相關的常量放在類：ConfigConsts下。大而全的常量類，非得使用查找功能才能定位到修改的常量，不利於理解和維護。
6. 對外暴露的接口簽名，原則上不容許修改方法簽名，避免對接口調用方產生影響。接口過期必須加@Deprecated註解，並清晰地說明採用的新接口或者新服務是什麼。同理，不要使用過期的類或方法。
7. 全部的相同類型的包裝類對象之間值的比較，所有使用equals方法比較。如：對於Integer var=?在-128至127之間的賦值，Integer對象是在IntegerCache.cache產生，會複用已有對象，這個區間內的Integer值能夠直接使用==進行判斷，可是這個區間以外的全部數據，都會在堆上產生，並不會複用已有對象，這是一個大坑，推薦使用equals方法進行判斷。
8. 關於基本數據類型與包裝數據類型的使用標準以下：
1） 全部的POJO類屬性必須使用包裝數據類型。
2） RPC方法的返回值和參數必須使用包裝數據類型。
3） 全部的局部變量【推薦】使用基本數據類型。
9. 序列化類新增屬性時，請不要修改serialVersionUID字段，避免反序列失敗；若是徹底不兼容升級，避免反序列化混亂，那麼請修改serialVersionUID值。 由於serialVersionUID不一致會拋出序列化運行時異常。
10. 類內方法定義順序依次是：公有方法或保護方法 > 私有方法 > getter/setter方法。說明：公有方法是類的調用者和維護者最關心的方法，首屏展現最好；保護方法雖然只是子類關心，也多是「模板設計模式」下的核心方法；而私有方法外部通常不須要特別關心，是一個黑盒實現；由於方法信息價值較低，全部Service和DAO的getter/setter方法放在類體最後。
11. setter方法中，參數名稱與類成員變量名稱一致，this.成員名=參數名。在getter/setter方法中，儘可能不要增長業務邏輯，增長排查問題的難度。
12. final可提升程序響應效率，聲明成final的狀況：
1） 不須要從新賦值的變量，包括類屬性、局部變量。
2） 對象參數前加final，表示不容許修改引用的指向。
3） 類方法肯定不容許被重寫。
13. 不要在foreach循環裏進行元素的remove/add操做。remove元素請使用Iterator方式，若是併發操做，須要對Iterator對象加鎖。
14. 使用entrySet遍歷Map類集合KV，而不是keySet方式進行遍歷。（keySet實際上是遍歷了2次，一次是轉爲Iterator對象，另外一次是從hashMap中取出key所對應的value。而entrySet只是遍歷了一次就把key和value都放到了entry中，效率更高。若是是JDK8，使用Map.foreach方法）
15. 循環體中的語句要考量性能，如下操做盡可能移至循環體外處理，如定義對象、變量、獲取數據庫鏈接，進行沒必要要的try-catch操做（這個try-catch是否能夠移至循環體外）。
16. HashMap在容量不夠進行resize時因爲高併發可能出現死鏈，致使CPU飆升，在開發過程當中注意規避此風險。
詳情參考：
https://yq.aliyun.com/articles/69327
======================================================================================
====================================C#編碼規範=======================================
======================================================================================
變量標識符
1. 變量建議置於塊的開始處，不要老是在第一次使用它們的地方作聲明。如：void MyMethod(){int int1 = 0; if (condition){int int2 = 0; ...}}
2. 只要合適，在變量名的末尾或開頭加計算限定符（Avg、Sum、Min、Max、Index）。如：salaryAvg
3. 布爾變量名應該包含 Is，這意味着 Yes/No 或 True/False 值，如 fileIsFound。
3. 在命名狀態變量時，避免使用諸如 Flag 的術語。狀態變量不一樣於布爾變量的地方是它能夠具備兩個以上的可能值。不要使用 documentFlag，而是使用更具描述性的名稱，如 documentFormatType。
4. 即便對於可能僅出如今幾個代碼行中的生存期很短的變量，仍然使用有意義的名稱。僅對於短循環索引使用單字母變量名，如 i 或 j。
5. 儘可能不要使用原義數字或原義字符串（避免使用不易理解的數字，用有意義的標識來替代（枚舉和常量）），如For i = 1 To 7。而是使用命名常數，如 For i = 1 To NUM_DAYS_IN_WEEK 以便於維護和理解。
6. 不要將縮寫或縮略形式用做標識符名稱的組成部分。例如，使用 GetWindow，而不要使用 GetWin。
命名空間
1. 命名空間使用Pascal大小寫(大駝峯法，首字母大寫)，用逗號分隔開。
2. 命名命名空間時的通常性規則是使用公司名稱，後跟技術名稱和可選的功能與設計，如：CompanyName.TechnologyName[.Feature][.Design]，其中TechnologyName 指的是該項目的英文縮寫，或軟件名。
3. 命名空間和類不能使用一樣的名字。例如，有一個類被命名爲Debug後，就不要再使用Debug做爲一個名稱空間名。
類
1. 使用Pascal大小寫(大駝峯法，首字母大寫)，用名詞或名詞短語命名類，不要使用下劃線字符 (_)。
2. 使用全稱避免縮寫，除非縮寫已經是一種公認的約定，如URL、HTML
特性 (Attribute，至關於Java的註解[Annotation])：
1. 應該老是將後綴 Attribute 添加到自定義屬性類。如：public class ObsoleteAttribute {}
枚舉 (Enum)
1. 對於 Enum 類型和值名稱使用 Pascal 大小寫，少用縮寫。
2. 不要在 Enum 類型名稱上使用 Enum 後綴。
3. 對大多數 Enum 類型使用單數名稱，可是對做爲位域的 Enum 類型使用複數名稱。
參數
1. 使用描述性參數名稱。參數名稱應當對參數的含義具備足夠的描述性，以便參數的名稱及其類型可用於在大多數狀況下肯定它的含義。
2. 對參數名稱使用 Camel 大小寫（小駝峯法，首字母小寫）。
3. 不要給參數名稱加匈牙利語類型表示法的前綴。（匈牙利命名法：變量名＝屬性＋類型＋對象描述，如：m_bFlag，m表示成員變量，b表示布爾，合起來爲：「某個類的成員變量，布爾型，是一個狀態標誌」）
方法
1. 使用 Pascal 大小寫，使用動詞或動詞短語命名方法，如：RemoveAll();GetCharArray();
屬性 (property)
1. 使用 Pascal 大小寫。使用名詞或名詞短語命名屬性。
2. 不要使用匈牙利語表示法。
3. 考慮用與屬性的基礎類型相同的名稱建立屬性。例如，若是聲明名爲 Color 的屬性，則屬性的類型一樣應該是 Color，如：public Color Color { get; set; }。
常量 (const)
1. 全部單詞大寫，多個單詞之間用 "_" 隔開。 如：public const string PAGE_TITLE = "Welcome";
字段
1. private、protected 使用 Camel 大小寫（小駝峯法，首字母小寫）。如：protected string userName;
2. public 使用 Pascal 大小寫（大駝峯法，首字母大寫）。如：public string UserName;
3. 拼寫出字段名稱中使用的全部單詞。僅在開發人員通常都能理解時使用縮寫。字段名稱不要使用大寫字母。如：class SampleClass{string destinationUrl;}
4. 不要對字段名使用匈牙利語表示法。好的名稱描述語義，而非類型。
5. 對預約義對象實例使用公共靜態只讀字段。若是存在對象的預約義實例，則將它們聲明爲對象自己的公共靜態只讀字段。使用 Pascal 大小寫，緣由是字段是公共的。如：public struct Color { public static readonly Color Red = new Color(0x0000FF); }
靜態字段
1. 使用 Pascal 大小寫。使用名詞、名詞短語或者名詞的縮寫命名靜態字段。
2. 對靜態字段名稱使用匈牙利語表示法前綴。
3. 建議儘量使用靜態屬性而不是公共靜態字段。
事件
1. 對事件處理程序名稱使用 EventHandler 後綴，如：ButtonClickEventHandler(object sender, EventArgs e)。
2. 指定兩個名爲 sender 和 e 的參數。sender 參數表示引起事件的對象。sender 參數始終是object 類型的，即便在可使用更爲特定的類型時也如此。與事件相關聯的狀態封裝在名爲 e 的事件類的實例中。對 e 參數類型使用適當而特定的事件類。
3. 用 EventArgs 後綴命名事件參數類。如：MySelfEventArgs:EventArgs {}
4. 考慮用動詞命名事件。如：class PublishEvent {}
5. 使用動名詞（動詞的「ing」形式）建立表示事件前的概念的事件名稱，用過去式表示事件後。例如，能夠取消的 Close 事件應當具備 Closing 事件和 Closed 事件。不要使用BeforeXxx/AfterXxx 命名模式。
6. 不要在類型的事件聲明上使用前綴或者後綴。例如，使用 Close，而不要使用 OnClose。
7. 一般狀況下，對於能夠在派生類中重寫的事件，應在類型上提供一個受保護的方法（稱爲OnXxx）。此方法只應具備事件參數 e，由於發送方老是類型的實例。
異常
1. 使用 Pascal 大小寫。使用名詞或名詞短語命名異常，而且在類名中能清楚的描述出該異常的緣由。以Exception結尾。如：class FileNotFoundException {}
委託
1. 應該老是將後綴 EventHandler 添加到委託類。如：public delegate void MouseEventHandler (object sender, MouseEventArgs e);
控制語句
1. return語句中不使用括號，除非它能使返回值更加清晰。如：return; return myDisk.size(); return (size ? size : defaultSize);
詳情參考：
http://www.cnblogs.com/jailu/archive/2007/07/17/820959.html
http://www.studyofnet.com/news/211.html
======================================================================================
====================================代碼外觀規範======================================
======================================================================================
1. 列寬: 代碼列寬控制在110或120字符左右，超出須要換行。
2. 換行: 當表達式超出或即將超出規定的列寬，遵循如下規則進行換行
1). 第二行相對第一行縮進 4 個空格，從第三行開始，再也不繼續縮進
2). 在逗號後換行。
3). 在操做符前換行，運算符與下文一塊兒換行，方法調用的點符號與下文一塊兒換行。
4). 在括號前不要換行
當以上規則會致使代碼混亂的時候本身採起更靈活的換行規則。
能夠經過一些重構手法來減小單行字符長度從而避免換行。關於參數，不少方法調用超過 120 個字符須要換行，這暴露除了過長參數列的代碼壞味道，解決方式之一就是使用重構手法的 Replace Parameter With Method 的方式把一次方法調用化爲屢次方法調用，或者使用 Introduce Parameter Object 手法創造出參數對象並進行傳遞。
3. 縮進: 縮進採用4個空格，禁止使用tab字符。使用空格代替tab字符進行縮進已經成爲了編程界的共識。其主要緣由是不一樣的平臺甚至不一樣的編輯器下tab字符的長短是不同的。
4. 空格: 多個參數用逗號隔開，每一個逗號後都應加一個空格。
5. 聲明：一行只建議做一個聲明，聲明必需加註釋說明，並從上到下依次按字母順序排列。如
int level; //推薦
int x, y; //不推薦
6. 杜毫不規範的縮寫，避免望文不知義，如：AbstractClass縮寫成AbsClass，此類隨意縮寫將嚴重下降代碼的可閱讀性。
======================================================================================
====================================數據庫設計約定=======================================
======================================================================================
數據表和字段
1. 庫名與應用名稱儘可能一致，使用小寫英文和下劃線組成。（從數據庫名稱中能夠一眼看出是哪一個應用或者系統在使用的）
2. 數據表和字段採用小寫字母或數字加下劃線方式命名，並注意字段名不要如下劃線或數字開頭，例如 user 表和 user_name字段，不建議使用駝峯和中文做爲數據表字段命名。（數據庫字段名的修改代價很大，由於沒法進行預發佈，因此字段名稱須要慎重考慮）
3. 數據表不使用複數名詞。（表名應該僅僅表示表裏面的實體內容，不該該表示實體數量，對應於模型類名也是單數形式，符合表達習慣）
4. 表的命名最好是加上「業務名稱_表的做用」。 正例：tiger_task / tiger_reader / mpp_config。
5. 惟一索引名爲uk_字段名；普通索引名則爲idx_字段名。（uk_ 即 unique key；idx_ 即index的簡稱）
6. 小數類型爲decimal，禁止使用float和double。（float和double在存儲的時候，存在精度損失的問題，極可能在值的比較時，獲得不正確的結果。若是存儲的數據範圍超過decimal的範圍，建議將數據拆成整數和小數分開存儲）
7. 若是存儲的字符串長度幾乎相等，使用char定長字符串類型。
8. varchar是可變長字符串，不預先分配存儲空間，長度不要超過5000，若是存儲長度大於此值，定義字段類型爲text，獨立出來一張表，用主鍵來對應，避免影響其它字段索引效率。
9. 表必備三字段：id, created_at, modified_at（或create_time,update_time）。 說明：其中id必爲主鍵，類型爲unsigned bigint、單表時自增、步長爲1。created_at, modified_at的類型均爲date_time類型。
10. 若是修改字段含義或對字段表示的狀態追加時，須要及時更新字段註釋。
11. 字段容許適當冗餘，以提升性能，可是必須考慮數據同步的狀況。冗餘字段應遵循：
1）不是頻繁修改的字段。
2）不是varchar超長字段，更不能是text字段。
例如：商品類目名稱使用頻率高，字段長度短，名稱基本一成不變，可在相關聯的表中冗餘存儲類目名稱，避免關聯查詢。
12. 單錶行數超過500萬行或者單表容量超過2GB，才推薦進行分庫分表。 說明：若是預計三年後的數據量根本達不到這個級別，請不要在建立表時就分庫分表。
13. 合適的字符存儲長度，不但節約數據庫表空間、節約索引存儲，更重要的是提高檢索速度。 如：人的年齡用unsigned tinyint（表示範圍0-255，人的壽命不會超過255歲）；海龜就必須是smallint，但若是是太陽的年齡，就必須是int；若是是全部恆星的年齡都加起來，那麼就必須使用bigint。
14. 儘可能使用數字型字段，若只含數值信息的字段儘可能不要設計爲字符型，這會下降查詢和鏈接的性能，並會增長存儲開銷。這是由於引擎在處理查詢和連 接時會逐個比較字符串中每個字符，而對於數字型而言只須要比較一次就夠了。（IP、時間能夠轉換成數值類型存儲，日期保存爲數值類型(unix時間戳)，能夠提升範圍查詢效率，國際化兼容性較好；IP保存爲數值類型，能夠提升範圍查詢效率；中文以Base64編碼保存，這樣在MySql多種引擎編碼下兼容性較好）
15. 最好不要給數據庫留NULL，儘量的使用 NOT NULL填充數據庫.（備註、描述、評論之類的能夠設置爲 NULL）。
16. 拆分大的 DELETE 或 INSERT 語句，若是你須要在一個在線的網站上去執行一個大的 DELETE 或 INSERT 查詢，你須要很是當心，要避免你的操做讓你的整個網站中止響應。由於這兩個操做是會鎖表的，表一鎖住了，別的操做都進不來了。若是你有一個大的處理，你定你必定把其拆分，使用 LIMIT 條件是一個好的方法。下面是一個示例：DELETE FROM logs WHERE log_date <= '2017-07-11' LIMIT 1000。
索引規約：
1. 業務上具備惟一特性的字段，即便是組合字段，也必須建成惟一索引。（不要覺得惟一索引影響了insert速度，這個速度損耗能夠忽略，但提升查找速度是明顯的；另外，即便在應用層作了很是完善的校驗和控制，只要沒有惟一索引，根據墨菲定律，必然有髒數據產生）
2. 超過三個表禁止join。須要join的字段，數據類型保持絕對一致；多表關聯查詢時，保證被關聯的字段須要有索引。（即便雙表join也要注意表索引、SQL性能）
3. 頁面搜索嚴禁左模糊或者全模糊，若是須要請走搜索引擎來解決。（索引文件具備B-Tree的最左前綴匹配特性，若是左邊的值未肯定，那麼沒法使用此索引）
4. 建組合索引的時候，區分度最高的在最左邊。 如：where a=? and b=? ，a列的幾乎接近於惟一值，那麼只須要單建idx_a索引便可。（存在非等號和等號混合判斷條件時，在建索引時，請把等號條件的列前置。如：where a>? and b=? 那麼即便a的區分度更高，也必須把b放在索引的最前列）
5. 若是有全球化須要，全部的字符存儲與表示，均以utf-8編碼，那麼字符計數方法注意：SELECT LENGTH("輕鬆工做")；返回爲12; SELECT CHARACTER_LENGTH("輕鬆工做")；返回爲4。若是要使用表情，那麼使用utfmb4來進行存儲，注意它與utf-8編碼的區別。
6. 使用索引是有代價的, 索引須要空間來存儲,也須要按期維護, 每當有記錄在表中增減或索引列被修改時, 索引自己也會被修改. 這意味着每條記錄的INSERT , DELETE , UPDATE將爲此多付出4 , 5 次的磁盤I/O （更新表時不只須要保存數據，還要保存索引文件）. 由於索引須要額外的存儲空間和處理,那些沒必要要的索引反而會使查詢反應時間變慢.。按期的重構索引是有必要的。
7. 對於惟一值的列，索引效果最好，對於具備多個重複值的列，如年齡或性別，創建索引不是好辦法。
8. 索引不會包含有NULL值的列，在數據庫設計時儘可能不要讓字段的默認值爲NULL，不然沒法創建相關字段的索引。
SQL命令優化規約：
1. 使用參數化查詢：防止SQL注入，預編譯SQL命令提升效率。
2. 去掉沒必要要的查詢和搜索字段：其實在項目的實際應用中，不少查詢條件是無關緊要的，能從源頭上避免的多餘功能儘可能砍掉，這是最簡單粗暴的解決方案。
3. 選擇最有效率的表名順序: 數據庫的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表將被最早處理，在FROM子句中包含多個表的狀況下,你必須選擇記錄條數最少的表放在最後，若是有3個以上的錶鏈接查詢,那就須要選擇那個被其餘表所引用的表放在最後。
4. 不要使用select *：不要使用select *，以提升查詢效率，減小輸出的數據量，提升傳輸速度。（數據庫或在解析過程當中將"*"依次轉換成全部列名，這意味着消耗更多的時間）
5. 儘可能避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
6. 減小訪問數據庫的次數：經過存儲過程等，把多條語句放在一個存儲過程當中執行，減小數據庫訪問次數。
7. 使用表的別名(Alias)：當在SQL語句中鏈接多個表時, 請使用表的別名並把別名前綴於每一個Column上.這樣一來,就能夠減小解析的時間並減小那些由Column歧義引發的語法錯誤。
8. 使用列的別名：當列的名稱很長的時候，使用簡短的列的別名能夠查詢結果更清晰，更簡潔。
9. 統計相關的查詢，影響結果集每每巨大，應避免在業務高峯期執行統計相關的查詢，或者僅在從庫中執行統計查詢。同時建議把數據先保存在內存、緩存中(如redis)，再按必定策略寫入數據庫。
10. select count(*) from table；這樣不帶任何條件的count會引發全表掃描，而且沒有任何業務意義，是必定要杜絕的，能夠用其餘方法代替。
11. where 子句中對字段進行 null 值判斷、包含not、!=、<>等操做符，或like的關鍵詞前加%(like '%關鍵詞')，都沒法使用索引，從而引起全表掃描。
12. 使用like進行模糊查詢時應注意,除非必要，不然不要在關鍵詞前加%，不然必然致使全表查詢。
13. 對於多張大數據量（這裏幾百條就算大了）的表JOIN，要先分頁再JOIN，不然邏輯讀會很高，性能不好。
14. 避免頻繁建立和刪除臨時表，以減小系統表資源的消耗。
15. 若是使用到了臨時表，在存儲過程的最後務必將全部的臨時表顯式刪除，先 truncate table ，而後 drop table ，這樣能夠避免系統表的較長時間鎖定。
1. 不要將系統級別的錯誤直接暴露給用戶，而更應該的是把系統拋出的錯誤信息記錄到LOG日誌文件中去，告訴用戶友好的提示信息。
2. 無論客戶端是否作過數據校驗，在服務端必需要有數據校驗
1). 對用戶輸入的字符串值進行長度驗證（腳本注入攻擊必然會大大增長變量值的長度，經過長度驗證能夠有效避免注入攻擊）
2). 對接收的參數進行類型格式化，好比id參數獲取後，進行int類型轉換
3). 對用戶輸入的值進行html編碼（防護xss跨站攻擊）
4). 對用戶輸入的字符串值包含的單引號、雙引號等符號進行轉義（防護SQL注入攻擊）
5). 對接收的參數內容，去掉任何遠程內容的引用（尤爲是樣式表和javascript）
3. 頁面輸出以前作html轉碼，不要原內容輸出。（防護xss跨站攻擊）
4. 不要把機密的信息明文存儲，務必進行加密。（這樣就算信息被竊取，也不會形成很大損失）
5. 儘可能使用cookie的httponly屬性，使客戶端js腳本沒法讀取cooie；對cookie內容進行加密。（防護xss跨站攻擊-Cookie欺騙）
6. 必須使用參數化SQL命令，永遠不要使用動態拼裝的SQL命令。（防護SQL注入攻擊）
7. 實現session tokens表單令牌，拒毫不明來源的非法提交。
8. 對用戶上傳的文件盡心更嚴格限制，例如限制文件類型、文件尺寸等。同時對上傳文件後存儲的文件目錄進行權限限制，去掉腳本執行權限和文件解壓權限等。（防護上傳入侵）
9. 不要直接暴露文件下載地址，而要把文件下載放到一個邏輯處理程序中，並對每一個IP作刷新次數的限制。（防護CC攻擊直接經過刷新文件下載而耗盡流量）
10. 頁面儘量把頁面作成靜態，由於動態網頁相對靜態網頁，對CPU、IO、數據庫的性能消耗高不少，作成靜態網頁能夠節約服務器資源，提升服務器性能。（防護DDoS攻擊、防護xss攻擊和SQL注入攻擊）
11. 檢查程序漏洞，對程序引用的第三方代碼、第三方插件、第三方類庫等，要即時更新官方漏洞補丁。
12. 服務器賬號、Ftp賬號、數據庫賬號、網站管理員賬號等，要設置足夠安全的強度，密碼最好很多於12位，幷包含大小寫字母、數字、特殊字符等。（防護暴力破解攻擊）
13. 過濾沒必要要的端口和服務，可使用Inexpress、Express、Forwarding等工具來過濾沒必要要的服務和端口。（防護端口入侵和DDoS端口攻擊）
14. 在存在多站的服務器上，嚴格限制每個站容許的IP鏈接數和CPU使用時間。（防護DDoS攻擊）
15. 對網站啓用https協議，防止數據被竊聽，特別是在交易過程當中，使用https保證數據傳輸安全。
參考文章：
http://www.cnblogs.com/sochishun/p/7007959.html
http://www.cnblogs.com/sochishun/p/7081739.html
http://www.cnblogs.com/sochishun/p/7028056.html
http://www.cnblogs.com/sochishun/p/6994918.html
http://www.cnblogs.com/sochishun/p/6993997.html
在線檢測：
360網站安全檢測 - 在線安全檢測，網站漏洞修復，網站後門檢測。 (http://webscan.360.cn/)
騰訊電腦管家官方網站網站安全檢測專區 ，提供網址安全檢測,網站安全檢測診斷工具,域名檢測等。 (http://guanjia.qq.com/online_server/webindex.html)
百度雲觀測 - 百度旗下網站雲監測平臺|免費安全檢測|網站測速|漏洞掃描|網站檢測。 (http://ce.baidu.com/)
網站安全檢測爲站長免費提供了網站漏洞檢測、網站掛馬實時監控、網站篡改實時監控等服務。 (http://tool.chinaz.com/webscan/)
參考文章：
http://tool.chinaz.com/webdetect/
http://www.2cto.com/article/201609/551091.html
前端優化：
1. 儘可能減小HTTP請求：把多個css文件合併成一個。
2. 使用Minify壓縮精簡Javascript和Css代碼文件。
3. 把CSS文件放到HTML代碼頁面頭部，這麼作能夠避免瀏覽器在解釋一次以後，使用css進行第二次解釋，由於用戶對css裸奔的效果根本就不感興趣。
4. 避免 CSS 表達式，凡是隻有IE能用的東西，都不是好東西。
5. 從頁面中剝離 JavaScript 與 CSS放到外部文件中引用，剝離後，可以有針對性的對其進行單獨的處理策略，好比壓縮或者緩存策略。
6. 使用 <link> 而不是 @import，在 IE 中 @import 指令等同於把 link 標記寫在 HTML 的底部，這與第一條相違背。
7. JS儘可能放到頁面最下端，當一個腳本在下載的時候，瀏覽器會卡住，沒法響應其餘請求。因此，能夠將功能性的JS放到最後端去處理。
8. 若是是移動端，單個數據對象小於25KB。
9. 注意控制Cookie大小和污染，由於Cookie是本地的磁盤文件，每次瀏覽器都會去讀取相應的Cookie，因此建議去除沒必要要的Coockie，使Coockie體積儘可能小以減小對用戶響應的影響。
圖片優化：
1. 壓縮圖片並使用 CSS Sprites 對圖片優化，簡單的說就是"利用 CSS background 相關元素進行背景圖絕對定位"，把屢次HTTP 調用變爲一次調用，減小HTTP請求。
2. 儘量的使用 PNG 格式的圖片，由於和GIF相比，PNG有更多的功能和更小的體積。
3. 用更小的而且可緩存的 favicon.ico，緣由是沒有favicon.ico，服務器會返回一個404，與能夠長時間緩存的文件相比，大量的404會增長服務器的響應數量。
服務端優化：
1. 使用CDN加速，靜態資源作CDN部署。（使用前端CDN增長網頁的並行載入速度，減小本地服務器的負擔，節省流量。一個瀏覽器對與同一域名的並行下載的個數默認是2個， HTTP.1.0中規定的是4個。這樣，咱們可使用不一樣的域名來提高下載的速度）
2. 開啓靜態文件壓縮，使用Gzip壓縮內容，以減小寬帶需求，讓頁面更快加載出來。
3. 對Ajax請求使用GET方法，XMLHttpRequest POST 要兩步，而 GET 只須要一步。
4. 儘可能使用JSON格式來進行數據交換。（與XML序列化相比，JSON序列化後產生的數據通常要比XML序列化後數據體積小）
5. 先後端作數據分離，讓搜索服務解耦，在高併發狀況下更靈活作負載均衡。（前端使用Vue.js、AngularJs等，數據來源能夠不限編程語言）
6. 後端數據大部分來自緩存，加載快，給用戶更快的體驗。（商品詳情、商品庫存等，能夠放在緩存（redis集羣），避免頻繁去數據庫取數據，提升商品信息的讀能力）
參考文章：
http://www.cnblogs.com/sochishun/p/7071705.html
http://www.cnblogs.com/sochishun/p/7003190.html
http://www.open-open.com/news/view/9902b7
http://www.cnblogs.com/Darren_code/archive/2011/12/31/property.html
http://www.cnblogs.com/wildweeds/archive/2010/06/12/web_performance.html
http://www.cnblogs.com/JustinYoung/archive/2007/11/20/speeding-up-web-site-14rule.html
http://www.cnblogs.com/zhangpengshou/archive/2013/05/31/3110304.html
瀏覽器插件
Google Page Speed: 谷歌網頁速度測試是一個開源的Firefox / Firebug插件。 網站管理員和Web開發人員可使用該工具來評估其網頁的性能並獲取有關如何改進它們的建議。
YSlow: YSlow用來分析網頁性能，並在高性能網頁規則基礎上建議如何改善。
PageTest: Internet Explorer的插件，經常使用來顯示瀏覽器加載內容時發出的請求並提供了該進頁面性能的建議。
Pylot: 開源的測試工具，能夠測試網站的性能和可擴展性。 它運行HTTP負載測試，這是有用的容量規劃，基準，分析和系統調整。
在線測試網站
Pingdom: 測試網站全部對象的加載時間（HTML，images，JavaScript，CSS，嵌入式框架等）。 您還能夠檢查網站每一個元素的加載速度並改善加載緩慢的項目。 在測試結果中，能夠看到網站每一個元素的加載時間報告，元素的大小和元素的總數量。
測試地址：https://www.pingdom.com/
GTmetrix: 結合了最流行的Firefox性能組件YSlow的和谷歌網頁速度測試工具。 Gtmetrix給你提供改進網站速度的建議，雖然YSlow的和谷歌網頁的速度測試的建議是針對Firefox的，也能夠適用於其餘瀏覽器。
測試地址：https://gtmetrix.com/
Site-Perf: 它模擬瀏覽器下載圖片，CSS，JS和其餘文件，在報告中你能夠看到先加載網站的哪些頁以及加載時間。 這是十分有用的性能報告，能夠用來查找到提升你的網站的載入速度須要改善的元素。
測試地址：https://gtmetrix.com/
參考文章：
http://www.cnblogs.com/lhb25/archive/2010/12/26/1917047.html
1. 對外暴露的接口簽名，原則上不容許修改方法簽名，避免對接口調用方產生影響。接口過期必須加@Deprecated註解，並清晰地說明採用的新接口或者新服務是什麼。同理，不要使用過期的類或方法。
2. 代碼修改的同時，註釋也要進行相應的修改，尤爲是參數、返回值、異常、核心邏輯等的修改。代碼與註釋更新不一樣步，就像路網與導航軟件更新不一樣步同樣，若是導航軟件嚴重滯後， 就失去了導航的意義。其實一些優秀的團隊在編寫代碼時默認是沒有任何註釋的，由於咱們追求的是 self-explanatory methods。即代碼自己已經就能說明它的用途。只有在不多的狀況下須要添加註釋。
3. 註釋掉的代碼儘可能要配合說明，而不是簡單的註釋掉。 代碼被註釋掉有兩種可能性：
1）後續會恢復此段代碼邏輯。
2）永久不用。
前者若是沒有備註信息，難以知曉註釋動機。後者建議直接刪掉。（代碼倉庫保存了歷史代碼）
4. 代碼修改後，要作功能測試，確保沒有由於修改而產生新的BUG。
參考文章：
http://blog.sina.com.cn/s/blog_7665a8ef0100rj6w.html
http://www.cnblogs.com/houbowei/archive/2010/06/07/1752821.html
1. 項目經理編寫產品發佈說明，產品發佈說明的內容應該包括：產品發佈時間；產品版本說明；產品概要介紹；本次發佈包含的安裝包、文檔說明；本次發佈包含或者新增的功能特性說明；遺留問題及影響說明；版權聲明以及其餘須要說明的事項。
2. 發佈以前，全部程序由測試人員進行確認測試；檢查登記的全部bug都已關閉，或者遺留的bug不影響系統的使用，若是有嚴重bug未解決（級別爲很嚴重以上）不能發佈。
3. 測試負責人編寫release產品測試報告和總結，給出發佈與否的結論。
4. 軟件打好包後郵件通知相關人員，提交產品安裝包。
5. 源碼、文檔入基線庫。源碼包括數據庫建立腳本（含靜態數據）、 編譯構建腳本和全部源代碼；文檔包括需求、設計、測試文檔，安裝手冊、使用手冊、二次開發手冊、產品介紹（ppt）、使用demo和項目經理提交的產品發佈說明等。
6. 上傳程序包、使用文檔至download站點。
7. 項目經理或者高級經理髮送產品正式發佈通知郵件，通知開發、測試、市場、銷售各相關部門並附上產品發佈說明和產品介紹；或者以產品發佈會議的形式進行通知。
8. 產品發佈後，在使用過程當中可能還會發現一些bug。在不影響正常使用的狀況下，這些bug將在下一版本發佈時解決；若是bug嚴重影響使用，必須打patch或者按照流程從新發布。
參考文章：
https://wenku.baidu.com/view/6f9b17baf121dd36a32d82c0.html
http://www.blogjava.net/jasmine214--love/archive/2011/11/24/364733.html
1. 先更新，再提交
源碼託管更新的原則是要隨時更新，隨時提交。當完成了一個小功能，可以經過編譯而且本身測試以後，謹慎地提交。
若是在修改的期間別人也更改了對應的文件，那麼commit就可能會失敗。若是別人和自 己更改的是同一個文件，那麼update時會自動進行合併，若是修改的是同一行，那麼合併時會產生衝突，這種狀況就須要同以前的開發人員聯繫，兩我的一塊兒協商解決衝突，解決衝突以後，須要兩人一塊兒測試保證解決衝突以後，程序不會影響其餘功能。
在更新時注意所更新文件的列表，若是提交過程當中產生了更新，則也是須要從新編譯而且完成本身的一些必要測試，再進行提交。這樣既能瞭解別人修改了哪些文件，同時也能避免合併錯誤致使代碼有錯。
2. 多提交
每次提交的間歇儘量地短，以幾個小時的開發工做爲宜。例如在更改UI界面的時候，能夠每完成一個UI界面的修改或者設計，就提交一次。在開發功能模塊的時候，能夠每完成一個小細節功能的測試，就提交一次，在修改bug的時候，每修改掉一個bug而且確認修改了這個bug，也就提交一次。咱們提倡多提交，也就能多爲代碼添加上保險。
3. 不要提交不能經過編譯的代碼
代碼在提交以前，首先要確認本身可以在本地編譯。若是在代碼中使用了第三方類庫，要考慮到項目組成員中有些成員可能沒有安裝相應的第三方類庫。項目經理在準備項目工做區域的時候，須要考慮到這樣的狀況，確保開發小組成員在簽出代碼以後可以在統一的環境中進行編譯。
4. 每次提交必須書寫明晰的標註
在一個項目組中使用SVN，若是提交空的標註或者不確切的標註將會讓項目組中其餘的成員感到很無奈，項目經理沒法很清晰的掌握工做進度，沒法清晰的把握這次提交的概要信息。在發現錯誤後也沒法準確的定位引發錯誤的文件。因此，在提交工做時，要填寫明晰的標註，可以概要的描述所提交文件的信息，讓項目組其餘成員在看到標註後不用詳細看代碼就能瞭解你所作的修改。
5. 提交時注意不要提交本地自動生成的文件
例如eclipse中的.classpath文件，Windows生成的縮略圖Thumbs.db，項目編譯生成的臨時文件.obj, .class等等。若是項目中沒有進行這方面的配置來強行禁止提交這樣的文件，請自覺不要提交這樣的文件。提交了這樣的文件後，別人在更新後就可能與本地的環境衝突從而影響你們的工做。
6. 不要提交本身不明白的代碼
代碼在提交入源碼託管服務器以後，你的代碼將被項目成員所分享。若是提交了你不明白的代碼，你看不懂，別人也看不懂，若是在之後出現了問題將會成爲項目質量的隱患。所以在引入任何第三方代碼以前，確保你對這個代碼有一個很清晰的瞭解。
7. 慎用鎖定功能
在項目中要慎用鎖定的功能，在你鎖定了一個文件以後別人就沒法繼續修改提交該文件，雖然能夠減小衝突的發生率，可是可能會影響項目組中其餘人員的工做。平時只有在編輯那些沒法合併的文件（例如圖片文件，flash文件等）時，才適當的採用鎖定操做。
參考文章：
http://www.cnblogs.com/xpxu/archive/2010/04/06/1705195.html
http://blog.csdn.net/nokianasty/article/details/12168577
http://www.360doc.com/content/12/0222/13/5236655_188606356.shtml
http://www.ruanyifeng.com/blog/2015/08/git-use-process.html
1. 使用合適的字符存儲長度，防止被注入攻擊的信息保存在數據庫，形成永久的攻擊和破壞。
2. 對機密的數據進行加密，如密碼字段。
3. 對交易信息使用巧妙的隱藏手段進行冗餘校驗，好比新增一個交易校驗表，表最好不要和主數據庫放在一塊兒，表結構爲(id, sign)，id對應交易明細表的自增加id，sign包含交易明細表的交易金額、交易時間、交易用戶、用於餘額等進行des加密，這樣若是用戶帳戶信息被篡改，就能夠經過後臺作數據挖掘對比，篩選被篡改的記錄。或者能夠經過巧妙的方法，把sign的值變成交易單號，直接就能夠和交易表無縫融合。
4. 按期作好數據備份，特別是重要的資金信息的備份，作好災後恢復的準備。
參考文章：
http://www.cnblogs.com/huangzijian/p/6347293.html
1. 備份數據，並認真作好備份記錄（最好有專職人員負責數據備份）。
2. 必須作好兩個或兩個以上的備份副本，並將其分別存儲於本地磁介質(指硬盤)與移動磁介質(指優盤)或網絡服務器上，以備災難恢復。
3. 按期檢查備份數據的保存狀況。
4. 根據數據的保密規定和用途，肯定使用人員的存取權限、存取方式和審批手續，禁止泄露、更改和轉移專業數據信息。
5. 備份數據類別包括：網站、郵件、數據庫、系統文件、日誌文件、配置文件、圖片、視頻、CA證書等。
參考文章：
https://wenku.baidu.com/view/f6282f2c0066f5335a8121f1.html
https://yq.aliyun.com/product/1229?utm_medium=text&utm_source=baidu&utm_campaign=dts&utm_content=se_460895
https://wenku.baidu.com/view/cbc2e438580216fc700afd40.html
第三方雲主機提供商通常會提供安全增值服務，360公司也有提供網站安全檢測服務，善用這些服務能夠大大提升網站安全性。
參考文章：
http://webscan.360.cn/
http://ce.baidu.com/
http://guanjia.qq.com/online_server/webindex.html
http://tool.chinaz.com/webscan
| 版權聲明：本文采用署名-非商業性使用-相同方式共享(CC BY-NC-SA 3.0 CN)國際許可協議進行許可,轉載請註明做者及出處。 |