背景
如果前人認為這是一種學習提高或者檢驗能力的成功實踐。而自己目前又沒有更好的方法，那就不妨試一試。
而不管作為面試官還是被面試者，編碼題最近越來越流行。而兩種角色都需要思考的問題是希望考察什麼能力，通過什麼題目，需要達到怎樣的程度可以說明面試者具有了這樣的能力。
而要找到上面這些問題的答案，比較好的方式除了看一些理論性文章和接受培訓之外，自己動手刷一刷leetcode切身實踐一下不失為一個不錯的方式。而既然要花精力去做這件事情，那就需要解決一個問題：我從中可以獲得什麼提高。以下是個人的一些經驗和感受。
收益
對底層有了更深入的了解和思考
leetcode一些常見題也是平時工作中常用的一些底層數據結構的實現方法。
先舉個大家使用比較多的算法：LRU(最近最少使用)，在Java的實現中實現特別簡單。只是使用了LinkedHashMap這種數據結構。而如果看一些開源包裡LRU的實現，發現也是這樣實現的。實際上動手實現一遍，LRU就再也不會忘了。
再舉個數據結構的例子：字典樹又叫前綴樹。它是搜索和推薦的基礎。標準點的定義是：
字典樹又稱單詞查找樹，Tire樹，是一種樹形結構，是一種哈希樹的變種。典型應用是用於統計，排序和保存大量的字符串（但不僅限於字符串），所以經常被搜尋引擎系統用於文本詞頻統計。它的優點是：利用字符串的公共前綴來減少查詢時間，最大限度地減少無謂的字符串比較，查詢效率比哈希樹高。
因為之前做過搜尋引擎，一直也對這塊很有興趣，所以對它底層知識的補充對個人而言，感覺深度有增加。
養成評估時空開銷的習慣
我刷leetcode必看官方解答裡估算的時間和空間複雜度。這也是作為一個架構師的必備基本能力。
數組、哈希這些因為數據的位置不需要進行查找，只需要算數計算就可以得到，所以它們的時間複雜度是O(1)。
鍊表如果直接在頭部或者尾部插入，因為不需要查找，所以時間複雜度也是O(1)，但是定位的話因為涉及查找，按遍歷查找來算是log(n)。所以對於jdk1.7之前，hashmap底層採用的是數組+鍊表的數據結構。所以如果不算哈希衝突和擴容的話，獲取和插入數據的時間複雜度是O(1)；如果出現了哈希衝突，則插入因為是頭部插入，時間複雜度還是O(1)；獲取時間複雜度因為涉及先查找，所以是O(n)，這個n代表衝突的數量。
對於在有序數據中進行查找，因為可採用二分查找等優化，時間複雜度可降到log(n).
對於遞歸調用，如果遞歸方法內進行2次調用。對於層數n來說，時間複雜度是2的n次方。舉個例子就是一個數等於前面兩個數之和。當然，如果是前面3個數之和，不進行優化的情況下時間複雜度就是3的n次方。
對於一個n*m的二維數組等需要進行嵌套循環遍歷的，時間複雜度是O(n*m)，有個特殊情況是n*m，這時候時間複雜度是n的平方。
對於全排列的情況，時間複雜度是O(n!)。
代碼簡化的方法
我習慣的一種學習方法是先做題，有了一定自己的總結和思考之後，再看書學習別人的總結思考方法。對於刷leetcode相關性高，也比較受認可的書是《Cracking the Coding interview(6th)》，中文版翻譯是《程式設計師面試金典》。這本書對於面試官和面試者來說讀了都會有一定的收穫。
我讀了這本書，對我印象最深的是介紹了兩種代碼優化的方法：BUD和BCR。
BUD
BUD是瓶頸、不必要工作、重複工作 三個詞組首字母的縮寫。
作者提出拿到一道編程題，可先嘗試用暴力解法將題目寫出來，之後找到解法的性能瓶頸，針對瓶頸進行優化，之後再去掉不必要的工作，最後去掉重複的工作。
這個經典的編程優化方法不只可應用於編程，還可應用於整個程序的優化，也是最常規的優化方法。
BCR
BCR是Best Conceivable Runtime的縮寫，意思是想知道自己可以優化到什麼程度，先估算可達到的最優情況。
比如：在一個無序數組中，查找兩個兩個相同的數。直覺來說如果找到這兩個數，最起碼需要將每個數都遍歷一遍，所以可達到的最優情況是O(n)，無論怎麼優化，都不可能比這個更好。所以這就是優化的上限。
這本書裡還介紹了其他的優化方法如：使用額外數據結構、通過構建測試用例、根據題目的限制和提示來尋找線索，大家看這本書的時候可以了解下。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺「網易號」用戶上傳並發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.