接下來講一下當時轉換所擬定的進行方向跟流程
- 首先圖片的東西會先偷跑，將服務徹換成直接上圖片相簿後，停止圖片上傳，接下來批次過去的圖片丟給相簿系統，轉換文章內的結果。
- 另外增加一台測試資料庫，將 db2, 3, 9 => db_new 的資料表中。轉換資料庫時，用每個 blog id 為單位進行轉換
- 先轉換超過六個月未更動的站台，再逐漸轉換較新的站台及文章。最後暫最近一個月，最近一週的，最後一天做停止新增文章及評論，將所有最後一天的文章轉換完畢後，切換系統
- 在進行轉換程式的開發時，也同時做吃新的架構的底層程式跟前台程式。合理來說應該轉換完的站台在新的底層程式中應該要可以呈現才對。
- 系統切換時間。系統切換完後，舊的資料也還要保留，觀察是否有未轉完的。留下轉換程式待上線時備份留存。
進行時碰到的狀況
碰到轉換一半 timeout 的，或是一個一個站台轉換的速度實在太慢。後來想到一個方式，先用程式將 sql 的資料全數轉成一行指令進行 mysql dump 的批次處理，組成多個檔案，用 multi process 的方式一次餵許多資料，db_new 還沒有對外服務只對我們的轉換服務，所以可以一方面請網管人員進行監控；另一方面餵大量資料。
上線後遇到的狀況
一開始的設計是將 station.inc 及幾個檔案分散，轉換期間時，想說把這些零碎檔案整合在一起，上線後，發生同時覆寫同一個檔案的狀況，造成沒有寫入完全。加上因為為了要讀取快速，都用 require/include 的方式將檔案讀入，結果造成整個壞了。之後只好用自己寫的 .lock 判斷檔案正在讀寫中
重構的壞處
進行重構時，接下來的功能與需求都沒辦法進行更新了，是故必須等待資料全數移轉及更新後才能夠繼續接新的需求。因為這些事情，後來流量也因為功能沒辦法上線也慢慢的降了下來，雖說不完全是這理由啦！有可能也是大環境所致，Facebook、社群掘起等等，多少拉了很多流量過去
整個重構後的好處
嚴格說來這個不算是重構，而是打掉重練，看過約耳的書都知道，打掉重練其實很傷，從我進公司由一個菜鳥只懂維護別人的程式到後來有意識想把它改善好的時間，我沒有認真想過要做打掉重練，一方面是24hr 的服務不能間斷，另一方面是時間成本也不予許我們打掉，雖然很想重做，但還是沒辦法達成。但扛下這服務的那一年之中，許許多多的未明問題一直陸續浮出，文章消失、人氣消失、留言消失，對於維護的工程師及想要進行更多開發的企劃而言，都覺得非常的力不從心。
公司不是只有寫程式這麼簡單，還有很多的政治因素，還有成本因素，遲遲無法擔當得起打掉重練的大責。或許是我有著處女座的潔僻吧！總覺得這服務還滿髒的，好多髒 code，但希望在下一個人接手時，它是乾淨的，也希望很多企劃們想出來的點子可以實現。所以一直爭取重新打掉的機會，在此很感謝前公司許多的長輩及主管願意讓小妹進行這大案子，現在回想起來真是感念無比。
在進行完整個重構及打掉重練，它總算開發得以進行得更快，許許多多過去想做在部落格系統上的功能也得以一一完成，另外網址列也可以縮短成只有文章 id，不用再抓取文章的建立時間。文章消失雖然在打掉重練後有段時間不太穩定，但經手的工程師至少都可以知道問題所在，能夠快速的將文章從備份找回。
針對過去對資料庫的龐大依賴，全部都用機器去拚，對於公司的成本也可以因此而下降，話說流量也下降了，空間也同時減少。
感謝很多當時幫我的主管們，還有一同參與專案到半夜的同仁們，前期雖然有點渾渾噩噩，但至少努力完成它了，包括一同開發新系統、提供大量轉換點子的主管、監視服務的網管；還有不放棄這服務繼續在此寫文章的網友們，不嫌棄網站總是不穩定，總算昐到一天它是比較穩定且不斷有新功能釋出。還有等待轉換期間的企劃及產品經理，因為舊系統的滯曖，變得開發時期冗長，不過你們都忍耐過來了，還要忍耐重構時不能有任何功能釋出。話說產品經理在這其間還離職了，還有一個企劃也離去。大家都承受著很大的壓力啊！
我後來離開公司去別的地方服務，一直很想拾筆道出過去的重構經驗，這段回憶有心酸也有成長，加上不宜將公司內部的系統架構說太明白，一直沒有寫下當時的寶貴經驗，但這段經驗讓我認知設計模式及系統架構的重要性，一個系統能不能有千萬的成長及負載量完全就看這初始的設計是否得宜，雖然也不能過度設計，但流量的事情誰能知呢~~工程師的工作是該把有可能的狀況分析或解決，這是免不了的。
寫下這篇也是為了感謝當年一起付出辛勞的同仁們，謝謝各位。
[advps-slideshow optset=”6″]
- 谷關溫泉騎馬之旅 - 2024-08-16
- 用 Notion 來回顧一整年的看劇活動 - 2024-01-01
- 如何用 Notion 來規畫新的一年，即將到來的大日子 - 2024-01-01