根據我觀察我周邊的一些.net和C++程序員，我發現一件很有趣的事情。當遇到一些復雜問題的時候，比如說需要分析一大批數據，不同的人會選擇不同的方法。有一些人會選擇使用自己熟悉的編程語言去寫一個一次性的小程序，有一些人會選擇使用腳本語言寫一段腳本去分析，有一些人則會想辦法去用強大的excel去解決問題。
根據我的小樣本觀察，厲害一點的人往往會選擇腳本，或者直接用一些excel公式去快速的得出一個結果。其他人則會選擇使用自己熟悉的語言，比如說C#去寫一個小程序進行處理，最終還是能夠得到結果，不過花的時間可能會久一點，寫的代碼多了一點。但是這些人往往自我感覺良好，因為自己剛剛寫出來一個小程序能夠統計出來這么復雜的數據，心里暗爽。
我並不是想說明寫腳本的人就nb一點，寫代碼的人寫小程序的人就笨一點，也許寫代碼的人寫小程序的人們中也有牛人吧。但我覺得那是一種低效的辦法，因為他們干了很多不需要自己干的事情，而且還很可能干的比腳本語言的實現差。如果是想鍛煉編碼能力的話沒問題，但是如果說從解決問題的角度來說這是一個低效的選擇。寫那種一次性的代碼對於我們其實沒有太大幫助，因為你知道以后不會再用了，所以你很可能寫出來的是一些很低效很搓很難維護的代碼。這樣很可能會養成一些不好的習慣。
我還可以列出很多自己實現的缺點和腳本實現的好處。但是我更想從另一個角度去看待這類問題。我認為那些人花更多的時間去寫了更多的代碼不是因為他們勤奮，而是因為他們"懶"，懶得去思考，懶得去找更高效的方法，懶得去熟悉一門腳本語言，從而失去了變更高效的機會。
所以我認為我們遇到一些問題的時候除了思考怎么解決問題本身以外，還要花點時間問一下自己，我找到的這個方案真的好么？我選擇這個解決方式的原因是因為這個方式真正能夠最好的解決問題還是因為我的知識讓我下意識得去選擇了這種解決方案。如果有更高效的方式，我認為應該毫無疑問得去選擇這種方式。很可能你在這次付出更多的時間和精力去完成這個任務，但是當你以后再遇到類似問題的時候你就可以變得更高效了。
我之前就是屬於那種低效的人，前段時間開始意識到這個問題於是開始去好好地學習一門腳本語言。如果你和我之前一樣也經常為了一些小的事情去寫一些一次性的代碼，我建議你也去學習一門腳本語言來處理類似的事情。
-The End-