滿是補丁的專案

[lighthouse07992000]

    再看這份投影片以前，我自己在想到”程式開發”時腦袋的畫面是：實驗室中幾個工程師坐在用夾板隔開的位置上，桌上堆滿著個人的物品，各自看著自己的電腦螢幕，手指不時快速的敲動鍵盤。

    會有這樣的想法是因為大學三年級在專題的時候，自己的感受差不多就是這樣。雖然一個小組內有三個人，但因為每個人的程式能力、負責區塊、善長領域和對專題本身的熱誠度都不同，在實做的階段可以說一直是”個人做個人的”，只有在每個禮拜meeting的時間才會把每一周自己的進度提出來報告，其他時間頂多透過聊天室互傳對方的程式碼執行看看，加上並沒有明確訂定詳細的程式架構、流程和時間表，使得最後在合併各自負責區塊的時候碰上很多難題也耗費了許多時間，差一點趕不上交件日期。

    而在事隔一年後的現在來看當時寫的程式碼，有些部分已經看不大懂，只記得當時後為了趕期限，拼命的翻書、查資料找解決方法，拼拼湊湊的造就出像一塊滿是補丁的破舊衣服。

    因此大致看過投影片的前段就發現，我們在溝通的部分近乎0，只有一個禮拜透過一兩個小時的meeting和聊天室互傳訊息來得知大家的進度。如果能夠以Face-To-Face的方式溝通，一定會減少許多花在合併程式碼的時間。

    而在事先的準備上，也只有初步的討論分工、程式語言和平台，缺少像投影片中所說的”軟體設計圖”這類可以在實作時參考並遵循的工具，在沒有設計草圖和虛擬碼幫助釐清的結果，就是在最後合併時碰上許多困難，而且我們三個人各自都多寫了很多用不到的文件和程式碼，浪費了許多時間和精力。

    最重要的一點，在專題後期因為程式需要和伺服器、資料庫之間做連結，在出現許多bug時沒有利用test code或JUnit，只是依靠人工加入printf、cout、log等程式碼來逐行檢查，非常耗時費工且沒有條理，如果能夠利用投影片中所說"測試帶動開發”的方法，逐次建立好Unit test並持續整合，想必會有更好的效率和產出。

    說起來簡單，但我知道自己原本沒有這些習慣，一時之間要將這些方法套用到所寫的每一份程式是很難的，得下很多功夫並且督促自己確實執行，再加上重複得閱讀這份投影片中的重點，一定能有很多的進步和收穫。