看了年初寫的總結，主要還是在於環境的搭建，底層的支撐。所做的事，大部分是從無到有的過程。這次繼續參與專案，基本上是在搞業務層的東西。當然，除了研發外，還在做專案管理方面的工作。

由於精力分散了，不能花很多心思專門深究一項技術。很多時候，在寫程式碼時被各種事干擾。
1、利用FFMPEG將h.264轉成AVI封裝格式的視訊檔案，然後傳輸到FTP伺服器上。雖然網上文章很多，但都不符合專案應用。因為轉換後的視訊不能存放到磁碟上。FFMPEG支援FTP協議，但官網上說使用FTP協議會有問題。本質上還是FTP伺服器對seek的不同表示的問題。無奈只好將轉換的視訊放到記憶體中再進行傳輸。從開始搞到最終解決，耗時2周多吧，中間還雜著部門一些任務。
2、FTP模組。這個模組是我大約4年前寫，但經過多人之手，有些程式碼已經無從追蹤根源了。這次有個不嚴謹造成的Bug。別人修改後，把我的超時時間單位由秒改為毫秒，但註釋沒改，同時刪除了原有的send和receive函式的超時機制。後來我參考自己寫的程式碼加進去，但沒有留意到時間單位。後期測試發現裝置開啟FTP後有概率卡死，就是因為超時時間單位引發的，原本是5000毫秒變成了5000秒。另外新學到的是實現FTP的主動模式。原有程式碼只有被動模式，但專案需求方硬要加上主動模式，於是也學習了一下，做了些筆記。不過，實踐發現，在傳輸時，還是被動模式相對好一些。
3、漢字編碼問題。關於漢字編碼，幾年前就有接觸，但工作上似乎不太需要，就沒再研究了。只是在做漢字疊加時，研究過freetype，瞭解過unicode。這次又遇到了。sqlite資料庫使用UTF8編碼，而之前一直使用GB2312，查詢數字和英文無問題，但當查詢漢字時，就發現精準度不高。為了解決問題，使用UTF8，而由此帶來的相容性問題，又花費了很多時間實現。以後再遇到涉及漢字的東西，就要打起十二分精神。不過編碼問題不是我解決的。我遇到的問題是傳輸帶中英文字元到FTP伺服器儲存為TXT檔案時會出現亂碼，這還是無意中發現的，最後使用UTF8編碼解決。測試驗證後發現M$系統中的notepad都會有這問題。當儲存的TXT有liantong、lanlu這類拼音的漢字時，會有亂碼。不要問為什麼會發現，誰叫我遇到“藍魯”的車牌呢。
4、除了上面的，就沒有學到新技術了。由於人手問題，工程裡很多模組都粗略過了一遍，當然不很熟悉，但至少，人家反映有問題，我也能大概知道是哪裡有問題。無論怎樣，也算對公司的架構有了解了。而在專案過程中，還遇到了一些已有工程架構程式碼的隱藏的bug。在驗證、解決過程，也鍛鍊了我的能力。在業務架構誕生之時，我還在寫外設介面，和業務程式無緣，後來慢慢發展，我還在寫外設介面。如今主刀的人，要麼走了，要麼在做其它事。還好，最後能找到原因並解決。
5、再要說一點的就是，感謝粘人的各位同事，有問題第一時間問我。我也迫於面子和壓力，要迅速做出反應，或是當面回覆，或是自己看程式碼或百度後回覆。這鍛鍊了我的分析問題能力。當問題發現時，第一時間要確定環境、條件，比如是在什麼系統出現的，做了什麼步驟後出現的，有概率出現還是必現，有無日誌。其次，要初步定位涉及到的模組，因為不確定問題出在哪裡，各方面都有可能，比如上位機、網路傳輸、裝置端業務層、裝置底層驅動、裝置硬體問題，等等。定位後，再進一步排查、除錯，直到問題解決。當然，有些問題最後的結果可能會讓人吃一驚，因為可能是一些小疏忽造成的。但往往要花費大量時間排查，如果記錄了，積累了，就成為屬於自己的經驗了。

對於專案管理，我做得很差。還是人手問題，我的主業是研發，其次才是專案管理。為此沒少挨有關方面的抨擊。如果要說學習到的東西，就是各種開會、各種扯皮都提高我的應變能力和找藉口能力。另外我驗證了公司流程制度的權威性(寧可花時間也要按流程走，但時間又怪到專案經理頭上)，也驗證了某些部門在公司地位的不可挑戰性(只要某些部門驗收不合格，就無法結項)。

說歸說，事實上無論怎樣，我還是從中學到不少東西，感謝公司的這次機會。

李遲 2015.9.3晚