寫代碼，這個是每個程序員(無論是菜鳥，還是大牛)都會的技能和幾乎每天都做的事，如同廚師會炒菜、民工會碼磚一樣；雖然都會，但看其代碼就可以大概知道此人技術咋樣，最起碼可以看出其代碼寫的好與差。——好的代碼就像是好的文章，讓人一看就感覺：思路清晰，作用明確，實現簡潔...，所以說寫代碼是門藝術，想成為高級程序員就必須掌握好這門藝術。此文要跟大家分享的就是我對練好這門藝術的核心技能："代碼重構"的看法！
"代碼重構"並不是像算法那樣深奧，需要你有相應的'硬件'(數學等方面知識)支撐，是你從開始學習編程就可以也應該鍛煉的技能，這也就是我此文想要說的核心：將代碼重構成為一種習慣;是的，你需要把代碼重構培養成為一種習慣，因為只有這樣，你才會將代碼重構融入到你寫的每段代碼中，並且會認為就應該如此做。寫這篇博客是有緣由的：看到公司做開發的同事寫的代碼，感覺一方面是編碼風格上不同、有點兒各樹一幟——公司在開發上不是沒有規范，而是大家沒有把規范落實、去遵行，更況且規范比較粗略，這就導致在看或維護別人寫的代碼時，經常會感覺跟自己的編碼風格差異比較大，閱讀起來比較費勁，甚至頭疼、有想抓狂的沖動。規范對於團隊開發相當重要也是必須的，要不然也不會有很多大公司(像華為)都有自己比較嚴格和細致的開發規范，其作用也毋庸置疑：能提高團隊開發的效率，確保編碼風格上的一致性，降低維護的成本...——想想看，當一個團隊中大家都遵行規范，這個規范可以小到類名或變量名的命名規范，也可以大到模塊文件夾目錄結構，如規定：全局私有變量統一以'_'開頭，模塊對外提供的服務類，都統一放在service文件夾下...，如此這樣你在看別人寫的代碼，就跟看自己寫的代碼一樣(如果規范粒度越細，其相似度就越高，可能就難分你我了)，也能比較方便快速的看懂代碼的意圖和找到需要的類或方法；另一方面，"代碼重構"做的並不夠好，即使是經驗比較豐富的程序員，其代碼中充斥着一些重復的代碼段，為此在開會時我提出我們應該注意"代碼重構"，並詢問他們對其看法，其答復基本上是：開發時時間比較緊，不想花那點兒時間去進行"代碼重構"。然后，我就問"那樣是不是導致你們在維護自己的代碼時，連自己都會感覺頭大和費時間"，他們的回答是肯定的。其實，不想去做"代碼重構"的編碼，在以后維護中，你會花更多的時間去做當時用個一兩分鍾就可以搞定的事，而當你把"代碼重構養成一種習慣"后，"代碼重構"就不再是你認為的"額外的事"，你會很自然也感覺必須要這樣做。
"代碼重構"並不是說你對設計模式比較熟悉才可以，因為不少程序員可能熟知各種設計或開發模式，但並沒有認識到"代碼重構"的重要性，也更沒有將其成為一種習慣。就我自己而言，雖然我對設計模式知道的很少，也不會'得心應手'的去使用，但我一直(大概是工作一年后到現在)以'確保自己寫的代碼里沒有重復的代碼段'這個基本原則規范自己的編碼，也同時要求和提醒着自己：要保證每行代碼或每個變量都有意義，沒有多余的，並保持每行代碼都不可隨意改變順序以呈現編碼思路的清晰邏輯。
最后，我想說的是：你應該在工作中多想和考慮，如：如何讓自己的代碼寫的讓別人用起來簡單易用...，不要只會'寫代碼'，也更不要盲目的追求技術上的狂熱將代碼寫的生澀難懂，增加了復雜度，好的代碼應該是：清晰、簡潔高效的實現。程序員，其實你可以做的更好！