RojerChen(ROX) CYH.20110131

從我開始會寫程式到工作以來，寫過或改過了大大小小的程式，每當有機會要把過去的程式拿出來使用的時候，內心常常出現下列兩種OS。


如果是自己寫的程式


『這…真的是我寫的嗎？怎麼寫這麼差啊？現在我已經看不懂當初我在寫甚麼了，乾脆重寫算了。』


如果是別人寫的程式


『這程式當初到底是誰寫的啊？這天殺的函式和奇奇怪怪的功能，這到底是做甚麼用的？與其花時間去了解功能，還不如重寫』




對於開發人員來說『讀別人寫的程式，永遠比自己寫還要來的困難』，這就是為什麼有些公司會規定程式的寫法，函數的命名，最重要的，要寫註解。即使是自己寫的程式，在事隔多年之後，你也沒辦法記住當初思考的邏輯和方法，這就是在專案的運作過程中，需要撰寫一些相關文件的理由所在，畢竟有規格有文件，至少還有一點蛛絲馬跡可以尋找。


去年我們有一個專案要做改版，我們遇到了這些問題：

1. 整個團隊中，只有我熟悉整個系統的架構
2. 整個團隊中，只有我熟悉VB6
3. 包含我，沒有人是前一次案子的開發成員

在專案開始之前，我們有想過，到底要不要花時間和成本來重寫？畢竟VB6這個語言實在太古老了，目前在公司除了我以外，沒人能夠維護舊有的程式，到底要不要花時間改成.NET來跑？在經過一番的考量之下，我們決定還是拿原本的程式來『改寫』，在當時我們是這樣去思考的：

1. 系統範圍：
   
   • 系統範圍是固定的，但是這個重寫的部分如果一改錯，後續資料的呈現等等的處理都會有問題。
2. 時間(品質)：
   
   • 專案時間固定，限時內要把工作完成。
   • 本程式已經RUN了八九年了，如果要改，是否能夠保持原本的品質？
3. 成本、資源(公司)：
   
   • 人力的部分沒辦法調整，況且在這段期間內，我們部門還有其他案子要做，人力吃緊
   • 能否尋求外包支援？這個工作項目很難獨立分割出來，況且在處理的過程中，需要不斷的溝通，採取外包未必是個好方法。

想當然，最後我們並沒有把程式全部『重寫』，畢竟要這樣做花的成本太高，時間上也不充裕，如果當初要把部分的功能重寫的話，那想必這個案子就無法在時限內完成了。


在本章節中，我覺得有一個地方說得很對，如果你是系統的維護人員，能做的就是把程式『改寫』而不是『重寫』，畢竟你是維護人員，你不知道在過去開發與測試的過程中，因為遇到了哪些問題之後，程式碼加上了不少雜七雜八的功能，而這些功能都是過去花了不少時間、精力與測試後產生出來的東西，如果把它丟掉，就等於把過去的智慧也一起丟掉，這也就是為什麼有些系統是用古老的語言來寫的，因為沒人敢保證換了新版的之後，不會出問題，會更有效率，如果公司肯花那樣的時間人力和成本的話。


不然你花了時間加班，產出了一些無法預期的BUG，客戶不滿意，老闆收不到錢，簡直是瞎忙一場，而且到最後錯都怪在你身上的話，就只能哭哭了。