• 流程圖也好，大體思路圖也行，甚至隨手演算的過程都可以，總之一定要把思路理清楚了，思路不清的后果就是代碼越寫越亂，最后只能全部推倒重來，事先不畫圖省下的時間遠遠比不上最后重寫所浪費的時間。

• 以前刷題的時候，也知道命名規范的重要性，只是沒想到會如此重要。之前我的代碼風格還算不錯，不過一開始寫的時候還偷下懶，省掉一兩個單詞之類，有時心急了還直接用原來的命名方法，用下劃線分割單詞（Kinect的API里都是用大小寫分割單詞的），這樣寫的弊端就是代碼也是越來越亂，而且一旦有事中斷了幾天，回來再看代碼就發現看不懂了，于是又簡單粗暴推倒重來。所以一定要有一套自己的命名風格，而且不要為了省事少些那一兩個單詞，敲個長變量名所帶來的是代碼的高可讀性，多耗費的時間遠遠小于以后推倒重來所浪費的時間！

• 到處都是注釋，反而大大降低了可讀性，一眼看去全是綠的，頭都暈了，開發中期我就被自己那么多的注釋弄得看見綠代碼就想吐，后期只注釋主要功能，提高抽象程度，代碼反而變得清晰有邏輯。所以那種基本每行都有注釋的風格，我并不認同，當然，我說的是代碼基本僅供自己一個人看的情況。

• 有一次就是，我做了個比較微小的改動，結果怎么調都不對，也已經忘了改動之前是什么狀態，簡直是有種欲哭無淚的感覺。還有就是進行一個大的改動之后，突然發現之前的那個版本才是對的（哭）。有個版本控制機制的話，這種情況應該能避免很多。

• 之前在知乎上看到一個貼，講的是新手應該怎樣進行開發，提到的一種思路就是進行迭代開發。一開始可能什么都不懂，然后著手做了一部分之后，就對項目有了個大概的輪廓，然后推翻進行新的一輪開發，這時又對未來該怎么做有更清晰的了解，這樣不斷迭代把項目逐步推向成熟。我是迭代了4次之后出了目前這個基本完成的版本，不過在寫的時候沒刻意考慮過用這種方法，之所以迭代了4次是因為上面提到的種種原因導致推翻重來（捂臉），不過現在看來這種方法好像真的很合理。
  

• 因為操作要在投影上進行，所以需要先識別出投影是畫面中的哪一塊，這里用的算法比較簡單，先投一副純色圖像出來，然后利用投影區RGB值近似的原理，找出投影的左下角和右上角之后就確定了投影的區域，這樣做的缺點是投影區只能是矩形而且不能太歪。其實有時間的話，可以試一下利用9*9的矩陣來找出所有屬于邊緣的點，然后渲染所有邊緣點，也就找出了整個邊緣，這樣可以適應任意形狀。

• 因為用手指來調用鼠標進行操作，而接觸屏幕的地方又是手指的指尖，所以需要識別出指尖。

一開始我是基于Kinect中BodyIndex這個數據源來尋找指尖，首先定位出腕關節在哪，然后根據腕關節的位置向上尋找復合指尖特征的點，可以說效果很好，識別非常精確和穩定，而且能同時識別出5個指尖，這部分是我在假期里完成的，本來以為來到學校后將程序根據投影儀調整下就差不多可以用了，然而到校測試后才發現一個致命的問題，就是當手臂貼近墻壁時，整個手臂的BodyIndex數據都丟失了。因為微軟似乎認為，如果某個點要是屬于人體的話，那么它和背景的深度差至少要有二三十厘米左右（正好是人體的厚度）。這個問題讓我失眠了幾晚上...不過也是在失眠的時候想出了現在用的解決方法。ds

• 因為想達到手指指哪，鼠標就點擊哪的效果，所以必須把手指在投影上的位置，映射成鼠標在電腦里相應的位置，這個其實簡單推導一下就可以得出。
  

  黑色框為投影屏幕，大寫的X和Y代表的是屏幕的寬和高，紅色框為電腦屏幕，假設人的手指在的位置，如果想將鼠標也映射到同樣的位置，那么就有??的等比關系成立。這里投影屏幕的寬和高在上面第一步中獲取，而電腦屏幕的寬和高，實際上是不需要考慮分辨率的，因為在鼠標的坐標系下，電腦的寬和高都被分成了65535個單位，所以寬和高可以視為65535。根據這些，就可以算出的值來。

• Kinect是帶有深度攝像頭的，也就是說它能夠知道畫面中的每一點到它的距離。似乎是利用三組紅外發射器來實現，所以也就要求物體不能是反射材質，不然會獲取不到距離。因為能夠知道屏幕的距離，也能知道手指的距離，所以如果手指距離屏幕足夠近，那么就可以判斷為點擊。但是，屏幕有可能不是絕對垂直的，Kinect也有擺歪的可能性，同時深度數據也不是100%精確，所以在計算屏幕距離時，需要考慮一個容錯值，在這個范圍內都被視為屏幕，在這里我設置的值是10cm，雖然看上去很多，但是實際效果還不錯。但是，這也帶來一個很嚴重的問題，就是手指在離屏幕的位置小于10cm的時候，也被視為了屏幕，這時候指尖就丟失了，手指變成了手指中部（因為手指不是完全平行于墻面的，而是有一定角度，所以指根的地方距離屏幕更遠），這就會產生很不穩定的現象，至今沒有解決。