SpecFlame項目總結

標籤：

       SpecFlame是我自研究生階段加入浙大GAPS實驗室以來所做的第一個實戰性質的項目。該項目我負責的部分的期間為2015年7月13日~2015年8月30日。項目的目標是通過Kinect fusion強大的建模功能，根據其掃描的人體特徵，自動化地產生適合不同人的眼鏡。下面我將對我參與該項目的曆程進行介紹，並總結其中的經驗教訓。

       7月13日，還帶著點畢業時淡淡憂傷的我再一次來到杭州，正式開始了自己的研究生生涯。我接到的任務是繼續ZS學長之前做過的眼鏡項目，重寫並按照新的演算法實現該項目。

       第一周（7月13~7月19）的時間裡，我主要是在閱讀老項目的代碼。通過學習MFC機制，我大致上對該項目所採用的產生眼鏡的流程有了初步的瞭解。但有一個地方其實是存在問題的，那就是我並沒有一開始就嘗試編譯運行程式，而是自己悶頭讀代碼。這樣做實際上很不利於我對具體功能的實現和代碼的理解。

       在第二周（7.20~7.26）的時間裡，我接到了導師交給我的具體開發工作單位：先初步實現一個基於四面體網格的鏡框，並寫一個簡單地介面來顯示它。因為我六月份剛剛學習了DirectX11編程，因此打算用DirectX+QT來實現。由於我對QT中實現DirectX並不是很熟悉，因此做這個簡單的工作實際上花費了我不少時間。並且，可能由於我和導師都屬於性子比較急的類型，我在和導師的溝通過程中經常存在一些障礙，導致我做出來的效果往往並不是導師想要的，為此還被挨了好幾頓批。當時心情也比較鬱悶，自己也在反思今後如何能夠更準確地理解導師真正的想法。

       在第三周（7.27~8.1），我的工作狀態漸漸步入正軌，利用STASM演算法得到了人臉的特徵值，並將kinect fusion的功能成功整合到了項目中。

       第四周（8.3~8.9），我嘗試計算特徵點，並產生了眼鏡的鏡片和鏡框。在計算特徵點的過程中，我遇到了一個很詭異的bug：計算的特徵點和利用kinect掃描出的mesh始終對不上。當時我調了很久的bug都沒能搞定，直到導師提醒我應該和舊項目的代碼進行替換，去確定到底是哪方面的問題。通過這麼做，我發現原來舊項目和我的項目所利用的Kinect fusion程式是不同的，舊項目的Kinect fusion程式修複了image和depth圖片對準的bug，而我採用的版本則沒有修複這個bug，這就是導致特徵點和mesh偏差問題的原因。

       之後，我開始設計產生鏡片和鏡框的代碼，vertex的構建並沒有花費多少時間。比較麻煩的是normal的計算過程，因為我當時並沒有按照標準的流程（頂點->構建四面體->產生四面體的法向量->計算頂點的法向量）來做，而是通過頂點間的位置關係來強行計算normal，這樣做的難度就要大很多了。再加上我採用的都是一些比較原始的Debug方法（單步觀察資料），導致我遲遲找不到問題存在的原因。導師建議我利用一些debug工具，將normal在映像中顯示出來。我利用這種方法調試了一天多，最終終於確定了問題存在的原因，也使得光照徹底沒有問題了。

　　第五周（8.10~8.16），周老師來看了我目前的效果，表示對我的介面設計不滿意，並總結了七條需要進行修改的list。其中一條便是將DX的版本轉成OpenGL版本。而由於我之前寫的代碼太過於耦合，使得我光是完成這一條就花費了自己很長時間。（期間還經曆過一次電腦崩潰，當時沒有備份代碼把我嚇得不輕，幸虧代碼被我搶救出來了>.<）。

　　後來，感覺項目就越做越崩，舊的bug沒有完全消除，導師對自己新的要求又一個接一個，壓力也越來越大，每天幾乎都要忙活到淩晨3、4點。然而即使如此，仍然不斷遭到導師的批評，當時自己的心情也是極度的鬱悶。最後，由於項目比較緊急，實驗室最終讓任老師來接手我的項目。我最後就做了一些代碼交接的工作，這個項目我負責的部分就算是暫時告一段落了。

      總體來說，我這次項目做得還是比較失敗的，這在一開始讓自己感到非常沮喪。自己本科做項目的時候，可能因為難度並不是很大的原因，儘管在做的過程中也遇到了很多困難，但最終還是和隊友們一起將它們克服了。而這算是我第一次失敗的項目。經過反思後，我總結了這幾條經驗和教訓：

      1、在聽取別人要求的時候不要急，要儘可能準確地把握住他想要的，必要的時候需要將他的需求複述給他聽，以儘可能地防止誤解他的意思。

      2、在寫代碼的時候，要遵循一定的代碼規範，盡量讓自己的代碼可讀，耦合性不要太高。要時刻記住自己的代碼不僅僅是給自己看的，之後可能會有很多人接手自己的代碼，你希望你接手的項目代碼是一團漿糊嗎？

      3、要學會藉助一些Debug工具來協助自己更有效率地debug。所謂“代碼能力強”，不僅僅指你手速快，實現地快，更看重你代碼的品質，以及你debug的能力。（所以說，我現在越來越覺得只會搞ACM的人並不能算是真正地會寫代碼）。

      4、在做項目的過程中，並不是說一定要用最新的技術，最酷炫的實現，而是應當與團隊大部分成員使用的開發工具相契合。比如我一開始用DX11去實現，但實際上以這個項目所需要的渲染要求，OpenGL固定流水線完完全全夠了；但由於我使用了DX來做，反而導致導師有很多不錯的代碼實現不能分享給我，一定程度上延後了項目的進展。

      5、在項目過程中，有一些工作，做了之後可以使之後寫代碼更加方便。對於這樣的事情，不要嫌麻煩，只要有時間就可以去做。正所謂“磨刀不誤砍柴工”，你做這樣的工作提高的效率將遠遠壓過做它所花費的時間。

      6、做事情不要再“差不多”，要以一個處女座的標準來要求自己，對自己狠一些，這樣才能逼迫自己真正地得到成長。

      7、代碼應當做好備份，哪怕是本地備份也行，不要再出現電腦崩潰代碼沒存的局面。當然最好能使用一些版本管理工具（例如git）來輔助。

      總而言之，就是今後要漸漸學會更加聰明、更有效率地去做事。反思一下之前做項目以及做事情的過程，自己確實就有點“漩渦鳴人流”的感覺：“憑藉著自己的皮厚屬性和大量的九尾查克拉，不管三七二十一衝上去一陣猛幹”。也許在本科階段，由於做得項目難度並不是很大，用這種方式還能應付；但隨著自己學習的深入，這樣做就會凸顯出很大的問題。從這個方面來講，我這個“漩渦鳴人”應當向技術流的“宇智波佐助”、“宇智波鼬”包括“卡卡西”學習，去學習他們做事的方法，提高自己的工作效率和靠譜程度。

      在研究生階段，在縱深專業領域的同時，我需要給自己定下一個學習計劃，閱讀一些有關代碼規範以及軟體工程方面的書籍（例如《Code Complete》、《Design pattern》等），並儘力將它們融入到自己的編程思想中，真正提高自己寫代碼的能力。這個目標我會時刻記在心裡，並在研究生階段開始著手實施。

SpecFlame項目總結