十二月小弟剛結束手邊的一個從七月延續到現在的案子,在這為期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 的功能打的,覺得直接用講的雖然可以省下打字的時間,還有節省手力,不過事後校稿也滿耗時的。
感覺用說的句子跟用手打出來的風格不太一樣,句子拉得比較長,贅字跟語助詞較多,如果是先寫在紙上再打到電腦又會是另一種風格,挺有趣的。