其實關於遞迴，我也是比較模糊的，至今能理解和能用的遞迴演算法，基本是靠記憶和經驗，要是讓我自己設計乙個遞迴，估計又得難半天，很早都想總結一下，喜歡瀏覽技術網
站，總是能找到好東西，現在將遞迴演算法總結如下，也不是多麼深刻，多麼高大上，可以說還是拙見吧：
》定義遞迴演算法：（基本思想）
那麼什麼是遞迴演算法呢，遞迴的基本思想是把規模大的問題轉化為規模小的相似的子問題來解決。在函式實現時，因為解決大問題的方法和解決小問題的方法往往是同乙個方法，所以就產生了函式呼叫它自身的情況。
麼多，下面看乙個圖：
這既是乙個最基本的的遞迴函式，函式體是：f(n) = f(n-1)*n;遞迴結束條件就是f(1) = 1;之後逐級返回，求出f(5)，遞迴兩個過程完成。
》遞迴演算法的形象理解：
借用乙個網友的說法：(關於門)
>>遞迴：你開啟面前這扇門，看到屋裡面還有一扇門（這門可能跟前面開啟的門一樣大小（靜），也可能門小了些（動）），你走過去，發現手中的鑰匙還可以開啟它，你
推開門，發現裡面還有一扇門，你繼續開啟，。。。， 若干次之後，你開啟面前一扇門，發現只有一間屋子，沒有門了。 你開始原路返回，每走回一間屋子，你數一次，走到入
口的時候，你可以回答出你到底用這鑰匙開了幾扇門。
>>迴圈：你開啟面前這扇門，看到屋裡面還有一扇門，（這門可能跟前面開啟的門一樣大小（靜），也可能門小了些（動）），你走過去，發現手中的鑰匙還可以開啟它，
你推開門，發現裡面還有一扇門，（前面門如果一樣，這門也是一樣，第二扇門如果相比第一扇門變小了，這扇門也比第二扇門變小了（動靜如一，要麼沒有變化，要麼同樣的變
化）），你繼續開啟這扇門，。。。，一直這樣走下去。 入口處的人始終等不到你回去告訴他答案。
以上的話很好理解，遞迴和迴圈很好的區別開了，總的來說，遞迴，有去還有回；迴圈，有去無回；
》遞迴演算法的應用：
>>遞迴演算法，總的來說就是：《往深處遞->結束條件->歸隊》，但是，在實際應用中也不是說，一定是有去有回，其實還有有去無回，典型的就是分治思想。
遞迴依賴於要解決的問題，有的需要去的路上解決，有的需要回來的路上解決，還有來回的路上都不用解決問題，而是在遞的最後和歸的開始，也就是在最盡頭解決問題。
看幾個例子：
1.回來的路上解決問題：
問題描述：合併兩個有序的單鏈表，使用遞迴的思想；
有序鍊錶合併，思想很簡單，直接看**：
listnode* merge(listnode* phead1, listnode* phead2)
else
return pmergehead;
}
2.去的路上解決問題：
簡單，直介面述乙個例子，比如乙個二叉樹，在某種需要下，需要將二叉樹左邊的一路全部壓入棧中，在去的路上做的就是資料壓棧；
3.在盡頭解決問題：
//遞迴查詢
node* _find_r(node* root, const k& key)
node* cur = root;
if (cur->key == key)
else if (cur->key > key)
else if (cur->key < key)
else
}
遞迴函式的再理解
學習到遞迴函式的寫法時，總是很難深刻理解到背後的設計思想。只知道問題被分解到了，還有乙個出口，外加呼叫自身，最後就能神奇的實現功能。後來，知道函式呼叫是一種棧式結構，每一次呼叫會把當前狀態壓棧，然後繼續往前走，直到呼叫的函式有結果了，再返回去。看似理解了背後的邏輯，但是，對於遞迴的掌握還是僅僅侷限於...
再理解敏捷
2009年1月24日 2008年春，專案做的對敏捷有了點興趣，花了兩個晚上瀏覽了 敏捷迭代開發 管理者指南 理念式的書，看起來比較輕鬆，摘錄一些自己的體會。有些需求在開始的時候是提不出來的，或者說沒法細化的，強行的過渡需求分析是浪費時間的行為，到後來多半還是要改。瀑布 其實royce大大提出的瀑布模...
遞迴之再探
有人說 遞迴就是有去 遞去 有回 歸來 所以遞迴過程可以分解為兩部分，一部分為分解，一部分為求解。具體來說，為什麼可以有去？這要求遞迴的問題需要是可以用同樣的解題思路來回答除了規模大 小不同其他完全一樣的問題。為什麼可以有回？這要求這些問題不斷從大到小，從近及遠的過程中，會有乙個終點，乙個臨界點，乙...