程式設計師的注意事項（網上拷貝）
阿新 • • 發佈：2019-01-10
**做框架的態度**
1. 不要因為困難的而不去做
2. 辨認是否真的做不了
3. 將使用者當傻瓜(不要讓使用者做得太多)
4. 框架技術選擇(大眾化)
**JavaScript**
1. 控制元件本質(對於DOM元素的位置變換、隱現，事件的控制)
2. 注意重用(加強複用東西（元件、控制元件）的編寫能力挺重要)
**Hybrid框架（mobile）**
1. 如何做得像原生做的
2. 別用單頁
**部署自動化**
1. 能自動化的東西，就別手動做(程式打包編譯都應該實現自動化)
2. 把開發人員解放出來(當你花幾天做出自動化東西，會發現後面省下的時間何止幾天)
**對學習的問題**
1.學習只能靠自己
2.多學習多總結(學習東西必須有結論)
**對錯誤的態度**
1.不要怕(對於錯誤，先理清問題到底是什麼，然後考慮怎麼解決)
2.承認做不了(自己做不了，就承認做不了，別死鴨子嘴硬，到後面出問題了再說，那就尷尬了)
**對於自我**
1. 直面不足（我不是個聰明的人，只是還有些小勤奮，我會花時間去弄懂）
2.成為別人的依靠（使得自己在某些方面是別人完成不了最後一個依靠）
3.有些偏執了（隨著我看到的東西越來越多，知道得越多，越能認清一個東西對錯好壞，對於我認為不對的，就不妥協，一定指出來）
4.小進步（我追求是每天有一點不同，每天有一點小進步）
**開發**
從小事做起，然後再擴充套件
一次只做一件事
儘早地新增日誌和錯誤處理
每一行新程式碼必須至少執行一次
在整體測試之前先進行模組測試
所有事情所花費的時間總是比你預期的要長
先了解現有的程式碼
閱讀和執行程式碼
**故障排除**
Bug 總是難免的（BUG的定義基本上是:“我們沒有想到”）
解決故障報告（每個開發人員都應該花時間去處理來自客戶的故障報告，並修復bug，這能讓你更好地理解客戶的意圖。）
重現問題
修復已知錯誤，然後再看看有沒有其他不對的地方
沒有巧合
關聯時間戳
**合作**
面對面的交流最有效
小黃鴨除錯法
問問題
共享榮譽
**其他**
動手去做
帶著問題睡覺
改變/跳槽（不要害怕角色變化。和不同的人共事，開發不同的產品，感受不同的公司文化是非常有意思的。）
活到老學到老（有機會可以學到新的東西。你可以嘗試不同的程式語言和工具，閱讀軟體開發的書籍，接受MOOC課程。）
**習慣**
1.要有負責心
在我們的每日工作中，有一半以上時間是在解決各種Bug。高階程式設計師在面對這些Bug時會從多個維度思考，Bug出現的時間、系統環境、硬體版本以及軟體版本等等。接著修復問題，嚴格自測，上線後觀察，一直會跟進到底，把影響降低到最小。
他們會主動承擔責任，為結果負責。面對各種問題時，不是第一時間為自己找藉口，不是互相推脫，互相指責。而是，想盡一切辦法解決問題，即使解決不了，也會給出最優選擇。
責任心在程式設計師的職業生涯中，具有最重要的指導意義，也是成為高階程式設計師必須具備的素質。
2.掌握程式碼除錯技巧
眾所周知，在移動網際網路時代，基於市場和需求的變化，專案週期的變化也會很快。有時一個月的工作計劃，會縮短到2個星期。面對巨大的專案壓力，程式設計師的程式碼質量會有所下降。
這時除錯技巧就尤為重要。一行程式碼的輸入輸出要清楚，一個函式的輸入輸出要明確而具體。高階程式設計師會在函式的開始和結束輸出Log，把所有的引數和返回值列印到日誌系統，便於追蹤。在解決問題的過程中，使用開發工具一行一行進行除錯，實時觀看引數的變化。
高階程式設計師清楚的知道他寫的每一行程式碼在專案中的作用和意義。
3.不要重複造“輪子”
我們對程式碼的記憶最多隻有2天，如果程式碼沒有註釋說明，也許第二天一早就會忘記它的具體意義。30天之前寫的程式碼相信沒幾個人會記得。
重複是怎樣發生的呢？-1.程式設計師們沒有意識到他們在重複。-2.程式設計師們偷懶，他們重複，因為那樣似乎更容易。-3.同一個團隊的幾個人重複同樣的資訊。
新需求持續進行迭代，需求的變化導致程式碼需要重新修改。這時的程式設計師也未必是當初那個程式設計師，導致隱藏的問題產生，產品到使用者手上隨時可能會爆發問題。
高階程式設計師會盡力避免開發重複的程式碼，組裝成公共元件庫是最好的選擇。
4.儘量使你的程式解耦
全球首位計算機博士David Wheeler曾經說過這樣一句話，“電腦科學領域的任何問題都可以通過增加一箇中間層來解決”。這句話詮釋瞭解耦的重要性。網路七層協議的設計，軟體開發的設計中，資料層、服務層和應用層，無不參考這位偉大計算機博士的思想。
生活中隨處可見這樣的例子。共享單車的出現，就是對我們出行的解耦合。你要做的就是在你需要的時候去使用，不需要了解更多的細節，出現問題了也不需要你去維修，只管用就好。
高階程式設計師開發的程式碼，既遮蔽細節，又提高了靈活性。
5.適當的進行重構
重構是改善現有程式碼的設計。在給外部提供介面不變的前提下，隨著時間的推移，在內部重寫、重做和重新架構程式碼。
什麼時間做最好？做的太早，看不出有做的必要性。做的晚，耗費大量的時間週期，會影響當前的專案。
初期的系統架構設計以簡單、易用為主。在創業公司3、5個人一個小隊，開始了一個專案。在人力資源匱乏的條件下，首要任務是先把系統搭建起來，短期實現基礎版。後期隨著需求的增加，系統變得龐大。早期的架構明顯有些弊端，不能跟隨專案進行發展。這時候重構就勢在必行了。
高階程式設計師清楚在什麼時間點進行重構。在不影響外部系統的情況，重新開發，提供更穩定的服務。
6.積累自己的程式碼庫
如果你做了多年的軟體開發，沒有積累自己的程式碼庫，沒有做好筆記。面對新的專案，所有程式碼重寫一遍。無疑了浪費了很多時間。網路上也可以下載到相關程式碼，但隨手的一個小功能，如果在自己的程式碼倉庫裡積累好。也省去了搜尋的時間。
高階程式設計師會積累自己的程式碼倉庫。
7.實踐、實踐、再實踐
有很多原則和道理我們聽過無數遍，但是從來沒有去實踐。如果不經過幾十萬行程式碼的錘鍊。很難達到一個高度。外部環境的支撐很重要。但是，如果沒有這樣的機遇，就需要我們創造條件去尋找。
**開發經驗**
一、對於團隊而言，流程太重要了。（各司其責+節奏）
二、不要炫技，老老實實寫程式碼。（想清楚了再決定用什麼+最好是跟隨成功專案的腳步）
三、架構上實用+適用。（在當前階段達到：開發效率+架構的平衡；並向後展望3-6個月，看看架構能不能適應。）
四、既要有攻城之力，也要有熬戰之氣——BUG。（不瞭解+粗心大意+使用情況各異導致的）
五、自審。（到底是在承擔過去，還是在改變未來）
六、註釋。（為了自己以後維護的方便+為了其他人接手的方便）
七、程式碼結構。（乾淨+整潔）
八、程式碼風格。（好比一家人）
九、安全與逆向。（加固+混淆+程式碼判斷）
十、開發效率。
十一、安裝包體積。
十二、UI渲染效率。（快並穩定）
**Java 程式碼效能優化**
減小程式碼的體積+提高程式碼執行的效率
1、儘量指定類、方法的final修飾符
類指定final修飾符可以讓類不可以被繼承，為方法指定final修飾符可以讓方法不可以被重寫。如果指定了一個類為final，則該類所有的方法都是final的。Java編譯器會尋找機會內聯所有的final方法，內聯對於提升Java執行效率作用重大。
2、儘量重用物件
Java虛擬機器不僅要花時間生成物件，以後可能還需要花時間對這些物件進行垃圾回收和處理。
3、儘可能使用區域性變數
棧中建立的變數，隨著方法的執行結束，這些內容就沒了，不需要額外的垃圾回收。
4、及時關閉流
5、儘量減少對變數的重複計算
6、儘量採用懶載入的策略，即在需要的時候才建立
7、慎用異常
8、不要在迴圈中使用try…catch…，應該把其放在最外層
9、如果能估計到待新增的內容長度，為底層以陣列方式實現的集合、工具類指定初始長度
10、當複製大量資料時，使用System.arraycopy()命令
11、乘法和除法使用移位操作
12、迴圈內不要不斷建立物件引用
13、基於效率和型別檢查的考慮，應該儘可能使用array，無法確定陣列大小時才使用ArrayList
14、儘量使用HashMap、ArrayList、StringBuilder，除非執行緒安全需要，否則不推薦使用Hashtable、Vector、StringBuffer
15、不要將陣列宣告為public static final因為這毫無意義，這樣只是定義了引用為static final，陣列的內容還是可以隨意改變的，將陣列宣告為public更是一個安全漏洞，這意味著這個陣列可以被外部類所改變
16、儘量在合適的場合使用單例（資源的使用+例項的產生+資料的共享）
17、儘量避免隨意使用靜態變數
當某個物件被定義為static的變數所引用，那麼gc通常是不會回收這個物件所佔有的堆記憶體的。
18、及時清除不再需要的會話
19、實現RandomAccess介面的集合比如ArrayList，應當使用最普通的for迴圈而不是foreach迴圈來遍歷
20、使用同步程式碼塊替代同步方法
21、將常量宣告為static final，並以大寫命名這樣在編譯期間就可以把這些內容放入常量池中，避免執行期間計算生成常量的值。另外，將常量的名字以大寫命名也可以方便區分出常量與變數。
22、不要建立一些不使用的物件，不要匯入一些不使用的類。
23、程式執行過程中避免使用反射。
24、使用資料庫連線池和執行緒池。
25、使用帶緩衝的輸入輸出流進行IO操作。
26、順序插入和隨機訪問比較多的場景使用ArrayList，元素刪除和中間插入比較多的場景使用LinkedList。
27、不要讓public方法中有太多的形參。
28、字串變數和字串常量equals的時候將字串常量寫在前面。
29、請知道，在java中if (i == 1)和if (1 == i)是沒有區別的，但從閱讀習慣上講，建議使用前者
30、不要對陣列使用toString()方法
31、不要對超出範圍的基本資料型別做向下強制轉型
32、公用的集合類中不使用的資料一定要及時remove掉
33、把一個基本資料型別轉為字串，基本資料型別.toString()是最快的方式、String.valueOf(資料)次之、資料+””最慢
34、使用最有效率的方式去遍歷Map
35、對資源的close()建議分開操作
**Mysql資料庫32條軍規**
1、不在資料庫做運算,cpu計算務必移至業務層
2、控制單表資料量：int型不超過1000w，含char則不超過500w；
合理分表；限制單庫表數量在300以內；
3、控制列數量：欄位少而精，欄位數建議在20以內；
4、平衡正規化與冗餘：效率優先；往往犧牲正規化；
5、拒絕3B：拒絕大sql語句：big sql；拒絕大事務：big transaction；拒絕大批量：big batch；
6、用好數值型別：tinyint(1Byte)；smallint(2Byte)；mediumint(3Byte)； int(4Byte)； bigint(8Byte)
7、字元轉化為數字：用int而不是char(15)儲存ip；SELECT INET_ATON('192.168.1.200');
8、優先使用enum或set：例如：sex enum (‘F’, ‘M’)
9、避免使用NULL欄位：NULL欄位很難查詢優化； NULL欄位的索引需要額外空間； NULL欄位的複合索引無效；
10、少用text/blob：varchar的效能會比text高很多；實在避免不了blob，請拆表；
11、不在資料庫裡存圖片
12、謹慎合理使用索引：
改善查詢、減慢更新；索引一定不是越多越好；覆蓋記錄條數過多不適合建索引，例如“性別”；
13、字元欄位必須建字首索引
14、不在索引做列運算
15、innodb主鍵推薦使用自增列；
16、不用外來鍵：請由程式保證約束；
17、sql語句儘可能簡單：一條sql只能在一個cpu運算；大語句拆小語句，減少鎖時間；一條大sql可以堵死整個庫；
18、簡單的事務：事務時間儘可能短；
19、避免使用trig/func：觸發器、函式不用；客戶端程式取而代之；
20、不用select *：消耗cpu，io，記憶體，頻寬；
21、OR改寫為IN()： or的效率是n級別； in的訊息時log(n)級別； in的個數建議控制在200以內；
22、OR改寫為UNION： mysql的索引合併很弱智；
23、避免負向%
24、慎用count(*)
25、limit高效分頁： limit越大，效率越低；
26、使用union all替代union： union有去重開銷；
27、少用連線join
28、少用group by：分組；自動排序；
29、請使用同類型比較
30、使用load data導資料：load data比insert快約20倍；
31、打散批量更新
32、新能分析工具
**前端優化**
[內容]儘量減少HTTP請求數
[內容]減少DNS查詢
[內容]避免重定向
[內容]延遲載入元件
[內容]預載入元件
[內容]減少DOM元素的數量
[內容]跨域分離元件
[內容]儘量少用iframe
[內容]杜絕404
[內容]讓Ajax可快取
[伺服器]使用CDN（Content Delivery Network）
[伺服器]添上Expires或者Cache-Control HTTP頭
[伺服器]Gzip元件
[伺服器]配置ETags
[伺服器]儘早清空緩衝區
[伺服器]對Ajax用GET請求
[伺服器]避免圖片src屬性為空
[cookie]給Cookie減肥
[cookie]把元件放在不含cookie的域下
[css]選擇 捨棄@import
[css]避免使用濾鏡
[css]把樣式表放在頂部
[css]避免使用CSS表示式
[js, css]把JavaScript和CSS放到外面
[js, css]壓縮JavaScript和CSS
[js]去除重複指令碼
[js]儘量減少DOM訪問
[js]用智慧的事件處理器
[js]把指令碼放在底部
[圖片]優化圖片
[圖片]優化CSS Sprite
[圖片]不要用HTML縮放圖片
[圖片]用小的可快取的favicon.ico（P.S. 收藏夾圖示）
[移動端]保證所有元件都小於25K
[移動端]把元件打包到一個複合文件裡
1. 不要因為困難的而不去做
2. 辨認是否真的做不了
3. 將使用者當傻瓜(不要讓使用者做得太多)
4. 框架技術選擇(大眾化)
**JavaScript**
1. 控制元件本質(對於DOM元素的位置變換、隱現，事件的控制)
2. 注意重用(加強複用東西（元件、控制元件）的編寫能力挺重要)
**Hybrid框架（mobile）**
1. 如何做得像原生做的
2. 別用單頁
**部署自動化**
1. 能自動化的東西，就別手動做(程式打包編譯都應該實現自動化)
2. 把開發人員解放出來(當你花幾天做出自動化東西，會發現後面省下的時間何止幾天)
**對學習的問題**
1.學習只能靠自己
2.多學習多總結(學習東西必須有結論)
**對錯誤的態度**
1.不要怕(對於錯誤，先理清問題到底是什麼，然後考慮怎麼解決)
2.承認做不了(自己做不了，就承認做不了，別死鴨子嘴硬，到後面出問題了再說，那就尷尬了)
**對於自我**
1. 直面不足（我不是個聰明的人，只是還有些小勤奮，我會花時間去弄懂）
2.成為別人的依靠（使得自己在某些方面是別人完成不了最後一個依靠）
3.有些偏執了（隨著我看到的東西越來越多，知道得越多，越能認清一個東西對錯好壞，對於我認為不對的，就不妥協，一定指出來）
4.小進步（我追求是每天有一點不同，每天有一點小進步）
**開發**
從小事做起，然後再擴充套件
一次只做一件事
儘早地新增日誌和錯誤處理
每一行新程式碼必須至少執行一次
在整體測試之前先進行模組測試
所有事情所花費的時間總是比你預期的要長
先了解現有的程式碼
閱讀和執行程式碼
**故障排除**
Bug 總是難免的（BUG的定義基本上是:“我們沒有想到”）
解決故障報告（每個開發人員都應該花時間去處理來自客戶的故障報告，並修復bug，這能讓你更好地理解客戶的意圖。）
重現問題
修復已知錯誤，然後再看看有沒有其他不對的地方
沒有巧合
關聯時間戳
**合作**
面對面的交流最有效
小黃鴨除錯法
問問題
共享榮譽
**其他**
動手去做
帶著問題睡覺
改變/跳槽（不要害怕角色變化。和不同的人共事，開發不同的產品，感受不同的公司文化是非常有意思的。）
活到老學到老（有機會可以學到新的東西。你可以嘗試不同的程式語言和工具，閱讀軟體開發的書籍，接受MOOC課程。）
**習慣**
1.要有負責心
在我們的每日工作中，有一半以上時間是在解決各種Bug。高階程式設計師在面對這些Bug時會從多個維度思考，Bug出現的時間、系統環境、硬體版本以及軟體版本等等。接著修復問題，嚴格自測，上線後觀察，一直會跟進到底，把影響降低到最小。
他們會主動承擔責任，為結果負責。面對各種問題時，不是第一時間為自己找藉口，不是互相推脫，互相指責。而是，想盡一切辦法解決問題，即使解決不了，也會給出最優選擇。
責任心在程式設計師的職業生涯中，具有最重要的指導意義，也是成為高階程式設計師必須具備的素質。
2.掌握程式碼除錯技巧
眾所周知，在移動網際網路時代，基於市場和需求的變化，專案週期的變化也會很快。有時一個月的工作計劃，會縮短到2個星期。面對巨大的專案壓力，程式設計師的程式碼質量會有所下降。
這時除錯技巧就尤為重要。一行程式碼的輸入輸出要清楚，一個函式的輸入輸出要明確而具體。高階程式設計師會在函式的開始和結束輸出Log，把所有的引數和返回值列印到日誌系統，便於追蹤。在解決問題的過程中，使用開發工具一行一行進行除錯，實時觀看引數的變化。
高階程式設計師清楚的知道他寫的每一行程式碼在專案中的作用和意義。
3.不要重複造“輪子”
我們對程式碼的記憶最多隻有2天，如果程式碼沒有註釋說明，也許第二天一早就會忘記它的具體意義。30天之前寫的程式碼相信沒幾個人會記得。
重複是怎樣發生的呢？-1.程式設計師們沒有意識到他們在重複。-2.程式設計師們偷懶，他們重複，因為那樣似乎更容易。-3.同一個團隊的幾個人重複同樣的資訊。
新需求持續進行迭代，需求的變化導致程式碼需要重新修改。這時的程式設計師也未必是當初那個程式設計師，導致隱藏的問題產生，產品到使用者手上隨時可能會爆發問題。
高階程式設計師會盡力避免開發重複的程式碼，組裝成公共元件庫是最好的選擇。
4.儘量使你的程式解耦
全球首位計算機博士David Wheeler曾經說過這樣一句話，“電腦科學領域的任何問題都可以通過增加一箇中間層來解決”。這句話詮釋瞭解耦的重要性。網路七層協議的設計，軟體開發的設計中，資料層、服務層和應用層，無不參考這位偉大計算機博士的思想。
生活中隨處可見這樣的例子。共享單車的出現，就是對我們出行的解耦合。你要做的就是在你需要的時候去使用，不需要了解更多的細節，出現問題了也不需要你去維修，只管用就好。
高階程式設計師開發的程式碼，既遮蔽細節，又提高了靈活性。
5.適當的進行重構
重構是改善現有程式碼的設計。在給外部提供介面不變的前提下，隨著時間的推移，在內部重寫、重做和重新架構程式碼。
什麼時間做最好？做的太早，看不出有做的必要性。做的晚，耗費大量的時間週期，會影響當前的專案。
初期的系統架構設計以簡單、易用為主。在創業公司3、5個人一個小隊，開始了一個專案。在人力資源匱乏的條件下，首要任務是先把系統搭建起來，短期實現基礎版。後期隨著需求的增加，系統變得龐大。早期的架構明顯有些弊端，不能跟隨專案進行發展。這時候重構就勢在必行了。
高階程式設計師清楚在什麼時間點進行重構。在不影響外部系統的情況，重新開發，提供更穩定的服務。
6.積累自己的程式碼庫
如果你做了多年的軟體開發，沒有積累自己的程式碼庫，沒有做好筆記。面對新的專案，所有程式碼重寫一遍。無疑了浪費了很多時間。網路上也可以下載到相關程式碼，但隨手的一個小功能，如果在自己的程式碼倉庫裡積累好。也省去了搜尋的時間。
高階程式設計師會積累自己的程式碼倉庫。
7.實踐、實踐、再實踐
有很多原則和道理我們聽過無數遍，但是從來沒有去實踐。如果不經過幾十萬行程式碼的錘鍊。很難達到一個高度。外部環境的支撐很重要。但是，如果沒有這樣的機遇，就需要我們創造條件去尋找。
**開發經驗**
一、對於團隊而言，流程太重要了。（各司其責+節奏）
二、不要炫技，老老實實寫程式碼。（想清楚了再決定用什麼+最好是跟隨成功專案的腳步）
三、架構上實用+適用。（在當前階段達到：開發效率+架構的平衡；並向後展望3-6個月，看看架構能不能適應。）
四、既要有攻城之力，也要有熬戰之氣——BUG。（不瞭解+粗心大意+使用情況各異導致的）
五、自審。（到底是在承擔過去，還是在改變未來）
六、註釋。（為了自己以後維護的方便+為了其他人接手的方便）
七、程式碼結構。（乾淨+整潔）
八、程式碼風格。（好比一家人）
九、安全與逆向。（加固+混淆+程式碼判斷）
十、開發效率。
十一、安裝包體積。
十二、UI渲染效率。（快並穩定）
**Java 程式碼效能優化**
減小程式碼的體積+提高程式碼執行的效率
1、儘量指定類、方法的final修飾符
類指定final修飾符可以讓類不可以被繼承，為方法指定final修飾符可以讓方法不可以被重寫。如果指定了一個類為final，則該類所有的方法都是final的。Java編譯器會尋找機會內聯所有的final方法，內聯對於提升Java執行效率作用重大。
2、儘量重用物件
Java虛擬機器不僅要花時間生成物件，以後可能還需要花時間對這些物件進行垃圾回收和處理。
3、儘可能使用區域性變數
棧中建立的變數，隨著方法的執行結束，這些內容就沒了，不需要額外的垃圾回收。
4、及時關閉流
5、儘量減少對變數的重複計算
6、儘量採用懶載入的策略，即在需要的時候才建立
7、慎用異常
8、不要在迴圈中使用try…catch…，應該把其放在最外層
9、如果能估計到待新增的內容長度，為底層以陣列方式實現的集合、工具類指定初始長度
10、當複製大量資料時，使用System.arraycopy()命令
11、乘法和除法使用移位操作
12、迴圈內不要不斷建立物件引用
13、基於效率和型別檢查的考慮，應該儘可能使用array，無法確定陣列大小時才使用ArrayList
14、儘量使用HashMap、ArrayList、StringBuilder，除非執行緒安全需要，否則不推薦使用Hashtable、Vector、StringBuffer
15、不要將陣列宣告為public static final因為這毫無意義，這樣只是定義了引用為static final，陣列的內容還是可以隨意改變的，將陣列宣告為public更是一個安全漏洞，這意味著這個陣列可以被外部類所改變
16、儘量在合適的場合使用單例（資源的使用+例項的產生+資料的共享）
17、儘量避免隨意使用靜態變數
當某個物件被定義為static的變數所引用，那麼gc通常是不會回收這個物件所佔有的堆記憶體的。
18、及時清除不再需要的會話
19、實現RandomAccess介面的集合比如ArrayList，應當使用最普通的for迴圈而不是foreach迴圈來遍歷
20、使用同步程式碼塊替代同步方法
21、將常量宣告為static final，並以大寫命名這樣在編譯期間就可以把這些內容放入常量池中，避免執行期間計算生成常量的值。另外，將常量的名字以大寫命名也可以方便區分出常量與變數。
22、不要建立一些不使用的物件，不要匯入一些不使用的類。
23、程式執行過程中避免使用反射。
24、使用資料庫連線池和執行緒池。
25、使用帶緩衝的輸入輸出流進行IO操作。
26、順序插入和隨機訪問比較多的場景使用ArrayList，元素刪除和中間插入比較多的場景使用LinkedList。
27、不要讓public方法中有太多的形參。
28、字串變數和字串常量equals的時候將字串常量寫在前面。
29、請知道，在java中if (i == 1)和if (1 == i)是沒有區別的，但從閱讀習慣上講，建議使用前者
30、不要對陣列使用toString()方法
31、不要對超出範圍的基本資料型別做向下強制轉型
32、公用的集合類中不使用的資料一定要及時remove掉
33、把一個基本資料型別轉為字串，基本資料型別.toString()是最快的方式、String.valueOf(資料)次之、資料+””最慢
34、使用最有效率的方式去遍歷Map
35、對資源的close()建議分開操作
**Mysql資料庫32條軍規**
1、不在資料庫做運算,cpu計算務必移至業務層
2、控制單表資料量：int型不超過1000w，含char則不超過500w；
合理分表；限制單庫表數量在300以內；
3、控制列數量：欄位少而精，欄位數建議在20以內；
4、平衡正規化與冗餘：效率優先；往往犧牲正規化；
5、拒絕3B：拒絕大sql語句：big sql；拒絕大事務：big transaction；拒絕大批量：big batch；
6、用好數值型別：tinyint(1Byte)；smallint(2Byte)；mediumint(3Byte)； int(4Byte)； bigint(8Byte)
7、字元轉化為數字：用int而不是char(15)儲存ip；SELECT INET_ATON('192.168.1.200');
8、優先使用enum或set：例如：sex enum (‘F’, ‘M’)
9、避免使用NULL欄位：NULL欄位很難查詢優化； NULL欄位的索引需要額外空間； NULL欄位的複合索引無效；
10、少用text/blob：varchar的效能會比text高很多；實在避免不了blob，請拆表；
11、不在資料庫裡存圖片
12、謹慎合理使用索引：
改善查詢、減慢更新；索引一定不是越多越好；覆蓋記錄條數過多不適合建索引，例如“性別”；
13、字元欄位必須建字首索引
14、不在索引做列運算
15、innodb主鍵推薦使用自增列；
16、不用外來鍵：請由程式保證約束；
17、sql語句儘可能簡單：一條sql只能在一個cpu運算；大語句拆小語句，減少鎖時間；一條大sql可以堵死整個庫；
18、簡單的事務：事務時間儘可能短；
19、避免使用trig/func：觸發器、函式不用；客戶端程式取而代之；
20、不用select *：消耗cpu，io，記憶體，頻寬；
21、OR改寫為IN()： or的效率是n級別； in的訊息時log(n)級別； in的個數建議控制在200以內；
22、OR改寫為UNION： mysql的索引合併很弱智；
23、避免負向%
24、慎用count(*)
25、limit高效分頁： limit越大，效率越低；
26、使用union all替代union： union有去重開銷；
27、少用連線join
28、少用group by：分組；自動排序；
29、請使用同類型比較
30、使用load data導資料：load data比insert快約20倍；
31、打散批量更新
32、新能分析工具
**前端優化**
[內容]儘量減少HTTP請求數
[內容]減少DNS查詢
[內容]避免重定向
[內容]延遲載入元件
[內容]預載入元件
[內容]減少DOM元素的數量
[內容]跨域分離元件
[內容]儘量少用iframe
[內容]杜絕404
[內容]讓Ajax可快取
[伺服器]使用CDN（Content Delivery Network）
[伺服器]添上Expires或者Cache-Control HTTP頭
[伺服器]Gzip元件
[伺服器]配置ETags
[伺服器]儘早清空緩衝區
[伺服器]對Ajax用GET請求
[伺服器]避免圖片src屬性為空
[cookie]給Cookie減肥
[cookie]把元件放在不含cookie的域下
[css]選擇 捨棄@import
[css]避免使用濾鏡
[css]把樣式表放在頂部
[css]避免使用CSS表示式
[js, css]把JavaScript和CSS放到外面
[js, css]壓縮JavaScript和CSS
[js]去除重複指令碼
[js]儘量減少DOM訪問
[js]用智慧的事件處理器
[js]把指令碼放在底部
[圖片]優化圖片
[圖片]優化CSS Sprite
[圖片]不要用HTML縮放圖片
[圖片]用小的可快取的favicon.ico（P.S. 收藏夾圖示）
[移動端]保證所有元件都小於25K
[移動端]把元件打包到一個複合文件裡