一直都沒想當大神，但心里確實很崇拜那些才思敏捷，博學多能的程序員。以為自己可以做到優秀，但最近發現自己離優秀真的還真有很遠的距離。甚至想到自己編程4年多，都有些羞愧難當。
事情是這樣的。
一個同事負責開發產品的一個新版本，需要我配合修改我之前做的一個模塊。這都沒有問題。他一直是很細心的人，開始給我講了很多他的思路。因為是在原來的基礎上開發新版本，一方面要滿足新功能的需求，一方面就是把原有的代碼重構一下，還要兼容舊的版本。但發現代碼有以下問題。
1.多余的屬性。
在設計的時候有些屬性並不是模型的職能。比如IsChecked，是否選中，當初是提供給做WPF界面的人綁定用的。認為不合理，不能刪掉，只好標記[Obsolete].
2.命名不規范。
比如AddUser（string usernName,string role）和EditUser(string userName,string userType). 這里的role和userType就是一種不規范，本來是同一個東西，為什么要用兩個名字。
3.職責不單一。
作為控制類，負責任務的控制。比如UserApplet 有OnStart,OnStop方法。能夠控制一些任務的執行和停止，而這些任務就不能寫入單個功能函數里面。Login，Logout方法就是登錄，退出。而檢驗用戶是否在線的代碼就不能混入這兩個方法里面。再譬如，有AuthorityManagement這個類負責管理權限方面的。就不能把實現其他驗證權限的方法放到別的地方去。不然東一塊西一塊的搞的很亂。
4.重復的代碼。
最常見的，一個方法有多個重載，有很多相同的驗證。就不能每次復制粘貼。應該讓他們都調用最基層的一個方法。Fool(string name),Fool(string name , string email).那前者就應該在內部調用后者。
5.重復的對象。
因為我們的有的數據持久化是保存在XML和XAML里面的，即使當初存下去的時候是同一個對象，但數據序列化出來后就是一個一個不同的對象。而這種情況，這就需要在加載之后讓他們都指向同一個原對象。
諸如以上的問題，真的叫做改的自己都不好意思。很久之前的代碼，沒有去細看，重構一次還真是干凈整潔了許多。而這些都不是重點，重點是修改的這個過程，我是很被動的，前前后后改了很多次。每次發現一兩個問題，push了一次，然后他發現還是有問題，又要我改。為此我還動過情緒（一時之氣，兩人關系不影響），每次坐下沒多久又叫過去看一下，再改。當時我又着急去做自己負責的其他的工作。所以總的來說，這次修改的效率比較低，對於這個事情的一直沒上心，只想按照他的意思早點改完。但因為沒有去好好理解這個東西，改出來的效果還是很差。真是欲速而不達。而更可笑的是，我之前還寫了《代碼整潔之道》的讀書筆記。有種打臉的感覺，因為主管看到我跑來跑去，還笑了笑，心里很懂那種笑是什么意思。不過可以說是一次印象深刻的整潔代碼實踐。
現在回想，優秀程序員和不優秀的程序之間最大的差別就是態度的問題。工作的態度和學習的態度都很重要。即使后者懂很多技術，不斷學習，如果做事情潦草，會造成更大的資源浪費。如果學習了不務實，那學習也沒有多大的價值，反而容易自負。技術性的東西學了容易運用，你能做的，別人學一學也也能做到，但更重要是編程思想上的差別，人家能做到謀而后動，干凈利落，但你改來改去還是有很多不整潔的代碼。但起碼，知恥而后勇，一切從自己的態度開始。