[經驗] 連夜趕工隔天交付的程式

這是筆者以前的一次工作經驗，因為進度落後導致熬夜趕工，記錄下來算是學一個教訓，畢竟冰凍三尺，非一日之寒，往往是多個原因堆積出這個結果，如果當中能及早發現，及早改善的話，也許不至於落得這般田地。

公司接到了一個專案，需要提供導覽機硬體、軟體以及控制後台，硬體是一台觸控且配有 Webcam 的 Windows 大電視作為導覽機，需求功能有:

1. 呈現觀光相關的導覽資訊，並且能操作互動
2. 能夠讓客人拍照掃描 QR Code 傳到手機
3. 沒拍照時，記錄操作者的停留時間、性別、年齡等特徵

另外後台是以網站形式配合帳密登入，讓客戶可以:

1. 編輯導覽素材和呈現方式
2. 監控導覽機的狀態，可遠端截圖、重開機
3. 報表
   1. 操作者的統計資訊
   2. 導覽素材的點擊次數統計…等等

當時和另一位同事搭檔，我負責導覽機軟體、Web 網頁呈現導覽資訊和部分後台頁面，畢竟導覽資訊幾乎都是連結到網頁，所以就使用內嵌的方式呈現，網頁讀取完成後，再另外疊上返回按鈕。同事則支援我其餘的後台頁面，素材管理、導覽頁版面編輯，不過因為整個架構主要是我規劃的，前期一直後在測試導覽頁的套件、內嵌Web的效果還有人臉偵測的套件，稍微花比較多時間，所以後期來不及時，才找同事臨時來支援，但這也是兵荒馬亂的開始。

同事臨危受命，邊了解邊時做的情況下，速度和我所想的有些落差，再加上溝通時間不夠，有時做出來後才發現某些地方雙方理解不同，又要花時間修改，若是一開始就適度讓他參與，了解架構和規劃，也許會比較好，而我也因為回答和溝通佔用了不少時間，導致開發時間更少了。

後台網站的部分，兩人會同時開發同一個程式專案，當時還沒有導入版本控制，所以整合程式時，又多花了一些時間在排除合併後的問題，常需要手動複製檔案到線上檢查的工具，才能知道差異在哪邊，現在想想真是太花時間了。

在功能開發好後，我們測試得不夠完全，當時還沒有單元測試的概念，全部都是簡易手動測試，沒有太多時間做 Monkey test，後期讓非開發人員的同事來使用時，常常發現一些莫名的問題，沒那麼容易重現，又因為沒有留Log，要花更多時間測試和找問題。

最後就是每天和同事加班，甚至到了交機前一天，還在寫功能、找問題，一直忙到凌晨3點才算告一段落，勉強有一個可操作版本，可以先應付，後續還是要把一些隱藏問題修掉，真是吃足了苦頭。

現在來看，大部分問題都可以藉由工具或是開發方式加速，也許初期會多花一點時間，但長期來看絕對值回票價，這也是這些工具存在的價值，期許這個教訓能讓我時時警惕，不再重蹈覆轍。