第一節：編碼過程的命名約定（編碼命名規范）
======================================================================================
====================================PHP編碼規范=======================================
======================================================================================
PSR（PHP Standard Recommendations，PHP標准規范） 是由PHP FIG組織制定的PHP規范，是PHP開發的實踐標准。主要包含基礎編碼規范、編碼風格規范、日志接口規范、緩存接口規范、HTTP消息接口規范等。
1. 【必須】代碼必須使用4個空格符而不是「Tab 鍵」進行縮進。使用空格而不是「tab鍵縮進」的好處在於， 避免在比較代碼差異、打補丁、重閱代碼以及注釋時產生混淆。 並且，使用空格縮進，讓對齊變得更方便。
2. 【必須】類的屬性和方法必須添加訪問修飾符（private、protected 以及 public），abstract 以及 final 必須聲明在訪問修飾符之前，而 static 必須聲明在訪問修飾符之后。
3. 【必須】PHP所有關鍵字必須全部小寫。常量 true 、false 和 null 也 必須 全部小寫。
4. 【不該】類的屬性和方法不該使用下划線作為前綴，來區分是 protected 或 private。
目錄和文件
目錄使用小寫+下划線。（參考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。
常量和配置
常量以大寫字母和下划線命名，例如 APP_PATH,const TRANSACTION_TYPE = 'income', define('CURRENT_SCRIPT', 'index.php')。
配置參數以小寫字母和下划線命名，例如 $config=array('url_route_on'=>true,'url_convert'=>array())。
詳情參考：
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/51594
======================================================================================
====================================Java編碼規范==========================================
======================================================================================
變量標識符
1. 成員變量、局部變量使用lowerCamelCase風格（小駝峰法，首字母小寫），如：inputUserId。
2. 變量命名不能以下划線或美元符號開始，也不能以下划線或美元符號結束。
3. 嚴禁使用拼音和英文混合的方式，更不允許直接使用中文的方式來命名。純拼音命名方式也要避免使用，但國際通用的名稱可視同英文，如：taobao, alibaba,xiamen等。
包
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)國際許可協議進行許可,轉載請注明作者及出處。 |