#0 本程式遞迴生成樹，樹在分叉時可能二叉，也可能三叉...，但不超過16叉，所以果斷用了陣列。
最終完成大概600行，最初估計大半天完成，最終花了三天。
最大感受：一旦資料定型，程式基本結構也定型了 | 自頂向下，化解複雜度控制很有效.
#1 資料型別應用 typedef 實現靈活性
1 typedef int normalint;
2 typedef char element;
#2 運用常量實現一定程度的可配置性
1const normalint elementnumber = 32;
2const normalint indexcount = 32;
3const normalint resultidxcount = 4096;
4const normalint max_target = 32;
5const normalint max_pool_size = 4096;
6const normalint indexover = -1;78
const element datatableover = -1;
#3 對於重新整理陣列資料 eg. 剔除負數->
用了容易編碼的方式（申請同尺寸陣列然後來回交換），有時間的話應該嘗試下in place processing的方法。
同樣非遞迴方式畫出樹我也使用了同樣的伎倆，以後換個方式做。
即便這段**也可以通過傳遞引數，根據引數動態申請儲存器來加以改善.
normalint idx[indexcount];//
indexover
normalint len=1;
for (normalint m=1; index[m]!=indexover; m++)//
m<=index[0]
if (index[m] > -1)
for (normalint m=1; m#4 牢記:c只有一種引數傳遞方式，下面**演示了怎麼通過函式呼叫申請資源、釋放資源的過程
1int allocresourse( int ** p )67
int deallocresource(int **p)
1213
int printarrayelements()
#5 使用指標應謹慎，寫了下面這個函式我明白了間址指標的用途
1int destroytree(tree ** tree)
#6 使用assert
程式完成後，隨著實驗資料變更，由於大量中間資料（達到近40k條目）生成，總會發生陣列越界，雖然一開始也考慮到了這些，但並沒有採取防護措施，只是注釋了可能出問題的地方。其實這是不夠的，最簡單的方法自然就是使用斷言了。斷言的使用並非越多越好，而是只在必要的地方使用，這需要對程式邏輯有清晰的了解。最終檢查下來，只在三個地方新增了斷言，再有問題發生，斷言會自然提示。那麼生產性質程式呢，還是應當改變演算法或者將斷言部分換成相應**。
#7 熟悉偵錯程式
這樣可以實現快速定位問題位置。
#8 調整程式預設棧大小
一方面中間資料的問題，另一方面遞迴帶來的開銷，預設的1mb棧空間捉襟見肘，程式直接棧溢位，在配置項linker中修改成16mb，暫時解決了問題。詳情參閱windows via c/c++第16章。
下圖為visual studio 2012截圖.
#9 應用code analysis來改善**
設定如上圖左下角所示。
開啟後重新編譯程式會生成xml分析結果，還是挺有意思的。根據提示我成功挖出了另乙個bug，該bug被兩重湊巧因素掩蓋（intel處理器小端法&&資料處理順序），此前雖然觀察到了這個現象但沒找到原因，在使用此功能後...晚上突然想到了原因。
乙個專案經理的經驗總結
本人做專案經理工作多年，感到做這個工作最要緊的就是要明白什麼是因地制宜 因勢利導，只有最合適的，沒有什麼叫對的，什麼叫錯的，專案經理最忌諱的就是完美主義傾向，尤其是做技術人員出身的，喜歡尋找標準答案，耽誤了工作進度，也迷茫了自己。以下是本人一些做專案的個人體會，寫出來供大家指點，在討論過程中共同提高...
程式程式設計經驗總結（1）
近頃 総括報告 在近一段時間裡，我主要在進行 様 様 共進電機様開發，在這三個專案的開發過程中，有一些收穫，也產生了一些想法，希望可以和大家交流。我進入小組快 1個月了，從開始的練習模組到現在的正式專案，前後做了快10多個專案模組了，但是依然有bug出現！雖然大家都安慰我說 開始做都有bug的，不要...
如何架構乙個ios專案 個人經驗總結
搞ios開發整整2年多 一直都是寫 為了某個功能去寫 從來沒有仔細的考慮過 如何架構乙個專案 現今天 總結一下 架構乙個專案的基本流程 專案分為三層 ui層 bll 層 common層 ui層 做什麼？首先我會建立乙個 baseviewcontroller類 裡面會做一些比較基礎的 標題 左butt...