1.找到停止遞迴的條件
2.找到每一層遞迴之間的聯絡
問題1：將多層迴圈簡化分析：找出從自然數1 、 2、……、m中任取k 個數的所有組合。 例如m=5，k=3
案例：輸入5 3 的時候
5 35 4 3
5 4 2
5 4 1
5 3 2
5 3 1
5 2 1
4 3 2
4 3 1
4 2 1
3 2 1
這個問題如果暴力列舉的話，是要用多重迴圈的，每一列對應一層迴圈，但是複雜度很大——————>簡化：其實每一層的迴圈都是相似處理方法的迴圈，每一層之間也有一定的聯絡。
在這個問題中:
停止遞迴的條件是：當已經找到了k個數字的時候（這一步可以用計數器來進行記錄）
每一層之間的關係由於是列舉式的列舉，第一位的選擇迴圈是遞減的，為了避免重複，第二位的選擇數應該比第一位小，（你是如何有序的進行排列組合的？）
每一層的輸出：當計數器計數到k的時候，終會輸出，我們需要輸出的資料：之前前面幾層留存的資料，但是在遞迴過程中難以傳遞，——————》可以另外設定乙個陣列，做記憶的作用
關於遞迴與非遞迴一些想法
現在很多公司面試的時候經常會同時考察一道題目的遞迴與非遞迴做法，往往遞迴做法能夠一氣呵成，但是非遞迴方法卻很容易卡殼。我想大概是因為遞迴方法，更符合我們的思維邏輯 也更簡潔。不像非遞迴方法，通常需要我們手動借助其它資料結構作為臨時儲存。但是遞迴方法，在執行的過程中也在不斷的建立資料結構儲存中間量，只...
一些錯誤的想法和錯誤的感悟
記住，ssl只是乙個傳輸層上的封裝協議，傳輸層上的。它代表的語義一定要比傳輸層更具體而比應用層更不具體。怎麼能拿它來封裝乙個具體應用呢？這是典型的主次顛倒，本末倒置，喧賓奪主的極端做法！https只能在ssl之上，難道能在ssl之下嗎？這裡最重要的是資料邊界問題，你是用你的應用協議來定義資料邊界還是...
錯誤處理的一些想法
錯誤處理在程式設計中是很重要的，可以在除錯，發布的時候少了很多麻煩，以往在做軟體的時候總是少了錯誤處理，導致使用者用來莫名其妙，在查詢問題的時候也是沒有頭緒 最近在總結一些錯誤處理技巧，總共有這麼一些方法 1.log log在關鍵的時刻可以救命的東西，因此我一直提議組裡的人多使用log，但是log記...