十二月小弟剛結束手邊的一個從七月延續到現在的案子，在這為期5個月的工作過程中，個人也有不少收穫，在這裡寫篇文章記錄一下。

溝通：

這次的案子是在不同的平台間移植，工作上沒遇到太多技術問題，在對方公司原有架構上，把平台相關的程式碼換成目標平台的程式即可， 撰寫的程式碼不超過300行，只花大約一週半的時間，相關的程式碼就已經寫完了。
後來之所以會拖這麼久，一個原因是對方公司的程式碼還在不斷的更新，而我們必須將這些更新都整進我們的程式中，並且還要在機器上測試過。
這次真的是見證軟體工程，最重要的是團隊間的溝通，少了溝通再怎麼會寫也沒有用，整合上很多問題， 諸如架構、測試、環境設定、測試硬體，都是由我的頭頂上司出面，多多溝通就解掉了，溝通的能力有時比技術能力還要重要。

架構：

整個過程中不斷撞牆的部分，在於整個Project 的開發過程中幾乎看不到架構設計的概念，感覺上就是東改一些西改一些，沒有一個系統性的規劃； 甚至到現場準備產品發佈的前兩週，突然出現架構的大幅修正，我們整合的部分當然也要收進去，也因此在週末加了一天班(yay。
後來在言談中得知，對方公司的確沒有架構工程師這個職位，那個<架構的大幅修正>只是某個資深工程師這麼寫，其他人看看覺得不錯，其他專案也就跟著這麼做。
對方公司也算台灣有點大的硬體廠，軟體部門的狀況卻是如此，幾乎接近各程式設計師各自為政， 知道了還是覺得有些心寒，不知道更上面的廠商狀況會不會好一點？

開發過程中，我自己也犯了類似的錯，應對方要求，我們這邊要整合兩個不同平台的程式碼，我竟然把所有的程式碼放在同一個檔案， 再用編譯macro 隔開，這當然不符合軟體工程的概念，只要加上更多平台，程式碼必定會增長到難以維護。
後來反省，的確是我的經驗不足才會這樣寫，真是幾年程式寫下來，軟體架構的概念還是沒練成，也難怪要成為架構工程師，都要先經過好幾年的軟體工程師的訓練。

測試：

這是專案中移植的目標平台，使用了一家中國廠商提供的SDK，無奈這家廠商有點兩光， 通常會送有問題的程式碼過來，文件也寫得不清不……啊不對是通常沒什麼文件。

一開始在做整合的時候，因為sdk有問題的關係，我們的程式碼執行不定時間就會造成其他的process crash，從log 上來說就是系統上某process （而且每次的process 還不一定一樣）segmentation fault 了，跟這篇文章 描述的有 87 % 像
當下無論是我們亦或對方公司覺得是自己的錯，但程式碼怎麼看都沒有問題，無奈它又是個不穩定的錯誤，在實際環境上測試非常花時間，在這個問題上面就花了近一個月的時間。
後來是利用一支之前用過的測試程式，可以用迴圈不斷執行核心功能，透過執行這條測試時也會crash，確認問題是出在核心功能而不是其他地方。

實際測試需要手動碰觸控螢幕，測試程式只需要用終端機執行，透過測試程式才能快速的註解掉可能有問題的部分， 再測試會不會crash 來判定問題在哪，最後才定位出問題出在對方的sdk中，回報上去才拿到修正這個問題的新版sdk 。
覺得就算沒有要用到TDD，在專案中維持一些簡單的測試，光是簡單的回歸測試都能預防開發中可能的問題， 就算真的出問題找不到在哪時，也能利用測試來定位錯誤。

能力：

這次發覺，自己的能力和對方公司的工程師比起來並沒有差太多，一些方面可能還超前對方。

很多工具例如 git 的使用，如何透過Format patch同步兩個git repository 的狀態 （當然對方公司內部是用svn ，所以這部分比較勝之不武），shell script 一些工具，我也比對方公司的工程師知道多一些些，工作的效率自然更高
我個人是認為，對方工程師雖然有較長的工作經驗，卻沒有－亦或沒有辦法－持續的和外圈技術圈交流，學習和知道一些最新的小工具： 例如我在Code & Beer 聊天中知道的 autojump
一些無名的小工具能大幅提高生產力，卻未必能大紅大紫，是在小眾的技術圈中流傳，多多交流還是能有效擴展自己的見聞。

工具：

這次也學到，平時多多熟悉一些工具的使用，用到的時候可以發揮很大的助益

案子的結尾，有機會跟對方公司的工程師一起到客戶現場去準備產品上線，到現場是個很新奇的經驗，但工作環境實在不太好， 程式碼不讓我們用版本控制就算了，連網路也不讓我們使用，遇到問題都只能問男人。

沒辦法查網路的時候真的是在比底力，平常有沒有熟悉shell 工具和程式語言這時立分高下。
我們又被現場公司雷：他們的環境裡有他們自己的設定，造成我們的code 放上去，clean 重build 的時候， 把他們的設定移除，造成機器當掉，又是感覺起來是我們的程式有問題
其實只要把他們的設定再裝一次就解決掉了－但從沒人告訴我們，為了抓這個問題花了兩個工作天， 大部分時間都在比較build log，在不同版本間進退，也因此用到不少 shell 工具。

我整理記憶上用得上的工具：

  • 一套版本控制系統，至少要能做到在兩台機器上同步，我是用 git
  • 至少一款diff 工具，我是用 vimdiff
  • 檔案關鍵字的搜尋工具：shell grep
  • 找檔案工具：shell find
  • 簡單的 shell script，一旦發現到有重複性的工作，可以的話就盡快改寫成shell script，可以加速工作的效率。

上面這些除掉網路還要能熟練地使用。

總結上面五個，這五個月來接這案子的小小心得，記錄一下。

註

這篇有不少篇幅都是用Google Doc， Voice Typing 的功能打的，覺得直接用講的雖然可以省下打字的時間，還有節省手力，不過事後校稿也滿耗時的。
感覺用說的句子跟用手打出來的風格不太一樣，句子拉得比較長，贅字跟語助詞較多，如果是先寫在紙上再打到電腦又會是另一種風格，挺有趣的。