重寫的理由

系統執行一段時間後，總會找到重寫的理由，理由大致如下：

有更新更強大的技術出現；

**質量控制不好或原有設計有缺陷，出現了很多壞味道；

原有開發人員流失，新舊交接不好或新人不喜歡維護他人**(又有幾人願意維護他人**呢？)；

政治原因；

但真的必須重寫嗎？原有系統真的就那麼不堪嗎？

話說3年前，還在上家公司，由於公司的不景氣，很多同事離職了，伺服器端的大部分**落到了我的手裡，當時剛剛被play framework和scala折服，男人的本性總是喜新厭舊的，於是，利用業餘時間，用play 1.2 和scala重寫了公司的核心業務模組。

開始只是為了理清原有系統的積累了好幾年的邏輯，經過兩個月的廢寢忘食，終於幾乎重寫了原有系統，**量減少到1/10，邏輯更加清晰，架構更加合理。

於是向外行cto匯報了該工程的存在，cto覺得這是自己的英明領導的偉大體現，竟然力挺該工程，測試後，出現了不少相容性問題，壞就壞在「幾乎」兩個字上，程式可是愛憎分明，毫不將就的。還好我對原有系統比較熟悉(已接觸該專案兩年)，經過差不多1個月的測試、debug，成功上線。

雖然成功的重寫了系統，但其中的辛酸，勞累，其中的風險，還是讓人後怕的。這次成功，純屬僥倖，主要是因為：

業務簡單，且我對整個系統

比較了解；

**量不大；

時間比較充裕；

所以一切還在可控範圍之內，下邊的故事，就是徹頭徹尾的悲劇了。

創業公司都用lamp；

於是，我的工作變成了每天宣講業務，不，是口述業務，然後由專人用叫做php的文法書寫出來......

新系統毫無架構可言，毫無模組可言，毫無設計可言，或許所謂高人，便是無招勝有招吧。

後果可想而知，**量翻了20倍不止，高人果然適合做大工程，只是遲遲無法上線，據說到現在，該系統也沒有上線成功。

這兩天本想重寫現在的某個系統，回想下這段往事，覺得還是重構比較合適，畢竟沒到系統無法承受的地步，如twitter。

衝動是魔鬼，重寫需謹慎！