故事是這樣的

筆者有個好朋友 Larry，是某間軟體公司的 PM Team Leader。他曾跟筆者講過某次他們系統超級大升級的故事，令我印象深刻。

偉大的航道

Larry 的公司成立已經快十年了，一直以來業績都不錯。俗話說得好，你錢賺得越多，就會得到越多的需求，同時也就會培養出越大的系統。Larry 他們也不例外。當這個系統已經大到近乎無法維護，或是說，隨便一個新需求來就會動輒得咎，導致開發效率不彰時，大家都覺得，是時候「重構」這個老系統了。重構老系統這麼重要的事，你可以想像首先不可能交給小菜鳥對吧？而且，也不可能只靠一兩個部門就能搞定（他們公司是採依專業分工的 component team 式分組），再加上當時適逢微服務當道，因此，一個重量級的重構專案就此誕生，命名為：「系統 2.0 專案」（先不要管名字了，總之就是一個大重構就對了）。

我的好朋友 Larry 身為 PM Team Leader，很自然的，這個專案的 PM 重責大任當然就落到他頭上了。而此專案的目標就是：「每個 Team 抽 2 ~3 個菁英份子進此專案，由 Larry 負責帶頭，花半年把舊系統的功能搬到新的、前後端分離的、在 Docker 內跑的、微服務架構的系統上。」

波折的過程

一個半年的 Project，從開工到上線要花多久？以各位的經驗我不確定，筆者自己遇過的，就沒有 delay 不超過 3 個月的。

公司為了這個專案，可是投入很多心力的！首先就是整理出一個大大的「精神時光屋」給專案的人用。一個半年的專案，每個 component 要改的範圍大不相同，於是，在大家同時開工三週後， DBA 已經把 DB Migration 的腳本寫完，提前撤退了。「後面開發沒我們的事，我們留下腳本，你們開發完執行一下就好，我們還有別的事要忙」DBA Team Leader 如此說。

前端與後端倒是不受影響，各自安排好自己的工作就開始工作了。一開始都相安無事，但兩個月後麻煩事開始來了。要知道投入這個專案的都是各部門的菁英。菁英抽出去做重構，原 team 的工作量會減少嗎？肯定不會，對吧？於是，留下來的人力要完成一樣多的工作，加班也就是必然之事了。加班不打緊，新的功能在舊系統加上的同時，新系統要不要做一份？很顯然要，對吧？於是，從第三個月開始，Larry 公司的所有開發者，都面臨了「一個功能要做兩次」的窘境。

又過了兩個月，專案團隊開始遭遇一些問題，就是一些舊系統中的邏輯，因為年代久遠，自動測試就不用想了，連他是做什麼的都已經不可考了，但又不敢亂動，畢竟也沒人能保證改了或刪了以後會發生什麼事。眼看 Deadline 越來越近，你猜他們做了什麼決定？沒錯，他們開始 copy-paste：把舊系統的程式碼複製一份放到新系統。

當然，因為新舊系統設計邏輯不同而遭遇的種種障礙，以及因為時間壓力而寫下的種種 workaround，也就不意外了。

進測試了，耶…（？）

好不容易算是把功能「做完」了，想要整包送給 QA 測時，又遇到 DB Schema 不合的種種問題。DBA 老早就「做完」了、撤了，記得嗎？於是又趕忙把 DBA 抓回來處理，同時解了一些前後端因理解不一樣所造成的接口與流程問題。光陰似箭，等 QA 真正看到能跑能測的東西時，又幾個月過去了，這時當初說好的半年早已花完，你覺得老闆會跟 QA 說什麼？

沒錯，就是經典的「趕快測一測趕快上線！」

這麼重要的專案，安排的 QA 肯定也是菁英對吧？身為菁英，怎麼可以真的隨便測，當然要好好跑一跑我半年前寫好躺在抽屜裡的測項呀！跟所有專案一樣，當然是 bug 越測越多，而且，這時 RD 已經「做完」並歸建，再開 bug 單給他們，那手上的工作怎麼辦？

加班囉！

經過又好一陣子的來回修正與重測，好不容易在第八個月結束前，這個「系統 2.0」的測項都跑完，準備上線了。

漫長的上線日

這是一個異常大的專案，Larry 吩咐維運人員，要在清晨人最少時才能停機更新。於是在上線當天的清晨 4 點多，維運人員如文件指示的「斷線、關機、啟動新系統」完了後，就開放了。

不開放還好，一開放警報聲四起！這時才清晨 6 點，維運人員見大事不妙，趕快再掛上維護，並通知睡夢中的 RD 們趕快來公司處理。所幸，RD 不愧是老經驗，馬上抓到問題並修正，但在新舊交接的中間，用戶衝進來造成的那些「髒數據」可就麻煩了。

因為一開始就從沒規劃過資料回復的機制，於是只好手動撈出這些數據，並加以人工計算後回填正確值，雖然還是做了一些臨時腳本以加速，但最後重新開放時，已經又過了 8 小時去了。

找到戰犯了！

事件當下當然大家就專心處理問題，但事後，由於停機 8 小時這件事茲事體大，於是老闆要求大家找個時間討論這整個事件問題到底出在哪。

老闆都說話了，大家也只好乖乖坐下來討論囉。

當然長達 8 個月的重構中間是有不少可以做得更好的地方，但真正「精彩」的還不是這個，而是到底為什麼上線當天會要停機 8 小時。

「其實原因是一個設定檔沒改好，一些值設錯了，導致服務表現與預期不同。這件事也好解決，我們發現問題後，一下子就改完了。」後端 Team Leader 開口了，「但這問題如果一開始部署完有做一些基本測試肯定抓得出來。」

大家一聽有道理，QA 不是說沒問題嗎？而且這麼大的案子上線日，為什麼當時 QA 不派人來測完再開放？

大家你一言我一語，好像找到一根救命的浮木，好死不死 QA 代表這個會議也沒派人參加，在沒有話語權的情況下，會議就得出一個結論：「QA 沒有測。」

可憐哪

可憐的 QA Team，在開發時就被 RD 的拖延壓縮測試時間，又礙於 Deadline，不得不大量加班幫測，最後上線日是 RD 說不用測才不出現的，最後設定檔設錯的也不是他們，卻在一個自己沒受邀的檢討會議上，變成眾矢之的，莫名其妙扛了一個「為什麼不測」的罪名。

圖片來測：Yahoo 新聞網

謎之聲：「可憐哪！」