算法的選擇
之前有一種想法，認爲編程中用到的數據結構和算法都是很高深的，那才顯得有水平，以爲牛人們編程時都偏向高深難懂的選擇。也一直想學習看看有哪些高深的算法，但最近的學習改變了我的看法，《程序設計實踐》一書中的看法是其實常用的數據結構都是很簡單的，也就是數組、鏈表、hash表、樹。常用的算法就更少了，排序和查找是最常用的。其中排序也通常是快速排序就把問題搞定了。查找嘛就是二分查找法，但是要求數組有序。常用算法都有標準庫提供的，平時知道怎麼去找到使用方法也就可以了。所以沒必要把數據結構想得那麼高不可攀，給自己心理造成障礙。而且根據《程序設計實踐》一書中的看法，選擇簡單的數據結構和簡單的算法並不丟人，反而是值得稱道的事情，因爲能用簡單的方法解決問題，那就意味着你程序設計會少出錯，容易實現。
數據結構和算法誰是中心？
Robert.Sedgwick的《算法》中說數據結構是算法的副產物，而《程序設計實踐》中認爲其實知道了數據結構，算法就決定了，然後程序結構也隨之決定。這兩種觀點中我不太理解第一種，算法的操作對象是數據結構，難道爲了使用某種算法而專門去設計數據結構？我認爲還是根據問題，對問題進行建模，找出合適的數據結構，最後再根據數據結構選擇合適的算法。對此處有不同看法的讀者，請留言探討下。
關於遞歸
遞歸的思想很巧妙，但是難以理解，我學習了好幾次，終於有所認識。遞歸看起來是自己調用自己，直覺上非常難以想象，但是聯繫到運算過程中的遞歸調用，也是一種調用而已，它每次遞歸時，系統在原來的函數棧上開闢一個棧，這個棧裏有局部變量和保存本次遞歸的運算結果的變量，隨着更多的遞歸，棧一層一層地累積起來，而調用的遞歸函數在程序運行時就放在了代碼區裏、且一直在那裏不動，棧和遞歸函數不在一個地方，因此遞歸本質上不過是函數調用。當遞歸開始結束後，最上一層棧消亡，把結果傳遞給下一層的棧，這樣棧一層一層地消失和往下傳遞運算結果，最終得到了最終結果。如果遞歸達到了10層以上，這事兒也就機器能忍受，人嘛肯定受不了。
遞歸在解決很多重複性的問題上非常有用，比如二叉樹的遍歷，二分查找，快速排序，歸併排序，但是得注意兩點：
- 遞歸的終止條件一定要提供，不然遞歸綿綿無絕期而棧溢出
- 遞歸代碼相比循環會很簡潔，但是遞歸層次太多也會發生棧溢出。