先分享一段今天看到的文章

在程序員心中，他們認為自己是建築師。當他們來到一個新地方，他們想做的第一件事就是推平這個地方，並建造一些宏偉的東西。

程序員對漸進式翻新不感興趣：修修補補、改進、在花壇種上綠植……他們不想做這些事，他們總是想扔掉舊代碼並重新開始，原因並非是認為舊代碼一團糟，而是編程的一個基本法則：閱讀代碼比編寫代碼更難。

我認為最好只看不動：

1. 很多愚蠢的程式，大部分都有其存在的原因。如果自以為最佳化後，客戶就會告訴我原因
2. 以公司的角度:進入維護階段，不應該讓原本正常的功能突然壞掉，理由只是我覺得他邏輯不通
3. 如果真的覺得有問題，那不久的將來一定會發生。那第一時間我馬上就能發現和解決問題
   

剛開始會利用很多時間把每一個點東搞得很清楚之外，然後開始狂改模式改成自己會的程式，以利維護與更新，看著覺得很猛猛的也頗驚奇。

這要看你要如何改，說不定你改了之後別人會覺得 "為何這麼改" 意思跟你想的都差不多!! 但如果你寫法還是以舊有的程式寫法那可能差不了多少。

這麼說好了 "我現在手上有一個正在改版的「台灣的經濟成長率」數據網站新聞都有報導" ，程式真的是有夠久的。

新的網站我修改的方法 >> 將所有的數據的換算從 C# 全數搬到 TSQL 解決掉，而 C# 只有單純將〔資料〕抓出來並渲染到頁面上，而這些資料可以供給其他〔程序〕再被利用。

原本的單一個 page 渲染，舊程序要 500 ~ 600 行(不包括TSQL)，透過改進後 page 渲染，新的程序只要 100 行以內就解決了。但這考驗著 "程式設計師熟不熟悉 TSQL 的處理方式" 不了解的也是會碰到 "為何這麼改" 。懂的人就懂，不懂的我也沒有辦法。

但我改善了

1. 程式裡面只會下 "SELECT" 卻不會透過資料庫的運算來處理相關簡單的換算，像是換算出經濟年成長率、外銷比、佔全體比重 全部都透過 TSQL 算出來，其實非常簡單就完成了。

2. 資料可以重覆被利用，而不是 A 頁面下達了相同的 TSQL 再透過 C# 又重覆處理相同的程式，那 B 頁面又再來重覆處理相同的程式。真的是很累人為何都要做相同的程式呢??

3. 不用 EF 因為也希望 "TSQL 應用邏輯" 可以被繼承下去，因為都沒有技術文件，如果都還是用 EF 就算用 SQL SERVER Profiler 也搞不懂到底在下達什麼語法

重構

呵..個人想法...

1. 重構還不如專案的技術文件與各資料庫與資料表的說明。
2. 重構也不會幫你計算與解決「C# 與 TSQL」內如何改善效率與改進從 500 行程式碼變成 100 行就解決的事情。
3. 重構不會解決「專案的時程」，當你重構全部想好時程就浪費了多少時間。