歡迎回來，這篇文章我們來回顧一下之前我們所講的鏈表的基礎知識。關於鏈表，到目前爲止，我們做了 4 道題目，相應的文章鏈接我也放在這裏了，有空你可以去看看：
可以說，鏈表最基礎的知識點都在這幾道題目裏得到了體現。如果你觀察仔細，你會發現，按着上面的順序，這幾道題目，或者說這幾篇文章剛好對應着鏈表的增刪改查。也就是我們平時所說的 CRUD。說到這裏，可能有些小夥伴按捺不住了，會說，"CRUD 還用你講？怕我平時搬磚搬不夠？"
確實，不知道從什麼時候起，CRUD 變成了一個程序員自我調侃的負面詞彙。常常能聽到這樣的話，“工作了幾年，平日裏都在 CRUD，技術根本沒有提高”，“基本上都在 CRUD，自我成長受限” ... 當然了，這種話平時和朋友同事們調侃幾句倒沒什麼，但如果真當真的話，那可就太片面了。
首先，單說 CRUD 這個詞其實太寬泛。幾乎只要和數據相關，都會涉及到 CRUD。從宏觀上來看，一個 APP 除了 UI 界面以外，剩下的不就是對數據的存取和整理嗎？只是說，在不同的場景和需求下，這個東西的難易程度有天壤之別。比如，有每秒千萬級的請求，如何更好地去做 CRUD？讀寫同時存在的業務場景，CRUD 如何更好地去加鎖？如何更好地去加事務？很多時候，難的事情和簡單的事情的區別僅僅在於需求和場景，跟事情本身並沒有太大的關係。
其次，做任何事情，不管事情的難易程度如何，都有做的好與不好之分。有的人口口聲聲說 CRUD 簡單，甚至覺得這東西有點侮辱自己的智商，但寫出來的東西卻 bug 頻出，三天兩頭要返工。而有的人寫 CRUD 代碼，把所有的情況考慮的滴水不漏，碼出來的代碼過了 5 年，甚至是 10 年後，都還一直在跑。同樣的事情，不同的結果，這之中反應的更多的是一個態度的問題。還有就是，再簡單不過的事情，你想要做得出類拔萃也並非易事。
上面這幾道題目，可能經常刷題的朋友會覺得非常簡單，毫不誇張地說，基本上 3 分鐘做完一道題。但我想問的是，做題的時候，你究竟是在思考問題，還是在把自己腦子裏背好的答案給敲出來？既然你都知道題目的答案了，談何難度呢？
另外，基於我面試別人的經驗，我可以很負責任的說，上面這幾題對於那些沒怎麼系統刷過題的人來說，可能並不簡單。我就不止一次地用 反轉鏈表 這道題目來作爲面試題，發現做不出來的大有人在。印象深刻的是在某次面試中問一個大哥這道題目，他項目經歷非常豐富，交談當中我也覺得他各方面都挺不錯，給我印象挺好。在算法上就想着走走過場，沒想太爲難他，於是就讓他反轉一個單鏈表。在我感覺，他是沒咋系統刷過題，前前後後，我各種補充說明，各種提示，他各種確認加修改，硬是把一道算法題盤成了系統設計的架勢。最後弄出來的代碼算是把樣例跑過了，不過他整出來的 4，5 個指針也算是把我給整懵逼了。到了給評價的時候，還真把我難住了，不知咋給，最後給了比較中立的評價。
當然了，關於面試，以後有機會我會出文章詳細說說。這裏主要還是想告訴大家，題目在你看來的難度，其實很主觀，也很可能並不真實。我們做題的目的是學習那些有跡可循的解決問題的方法，還有就是學習那些思考問題的模式與角度，而不是去爲了做對一道題目而做題，這除了自嗨，並沒有實際的意義。
扯遠了，回到鏈表上面來，鏈表的基礎其實就是鏈表的 CRUD。其實大多數情況下，學習一個數據結構，最先學的都是 CRUD，比如說哈希表，你最先學的肯定是如何存取，不會一上來就對着哈希函數開整。有了基礎，下一步，我們就得思考如何更好的 CRUD，比如說在某一場景下，如何更有效率地 CRUD？這個光靠了解單一的數據結構是不夠的，得橫向對比，比如這裏我們就屢次拿鏈表和數組作對比：
| 數組 | 單鏈表(含尾指針) | |
|---|---|---|
| 從尾部插入 | O(1) | O(1) |
| 從頭部插入 | O(n) | O(1) |
| 查找 | O(1) | O(n) |
| 從尾部刪除 | O(1) | O(1) |
| 從頭部刪除 | O(n) | O(1) |
總的來說就是，鏈表修改更快，數組查詢更快。到底該用哪個，這個得取決於應用場景。當然了，這兩個數據結構還可以結合起來變成高階的數據結構，比如後面我們會講到的 哈希表。
接下來，我們會嘗試着去解決一些鏈表當中的難題。如果之前的內容你都理解透徹了，你會發現，這裏所謂的難題，其實只是我們講的那些方法的靈活應用+花樣組合。當然，如果你對之前的內容理解的還不夠透徹，最好是在不看答案的前提下，把之前文章中提到的例題給做一遍。畢竟，飯得一口一口喫，路得一步一步走呀！
本文分享自微信公衆號 - 五分鐘學算法（CXYxiaowu）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。