程序員，其實你能夠作的更好

　　寫代碼，這個是每一個程序員(不管是菜鳥，仍是大牛)都會的技能和幾乎天天都作的事，如同廚師會炒菜、民工會碼磚同樣；雖然都會，但看其代碼就能夠大概知道此人技術咋樣，最起碼能夠看出其代碼寫的好與差。——好的代碼就像是好的文章，讓人一看就感受：思路清晰，做用明確，實現簡潔...，因此說寫代碼是門藝術，想成爲高級程序員就必須掌握好這門藝術。此文要跟你們分享的就是我對練好這門藝術的核心技能："代碼重構"的見解！

      "代碼重構"並非像算法那樣深奧，須要你有相應的'硬件'(數學等方面知識)支撐，是你從開始學習編程就能夠也應該鍛鍊的技能，這也就是我此文想要說的核心：將代碼重構成爲一種習慣;是的，你須要把代碼重構培養成爲一種習慣，由於只有這樣，你纔會將代碼重構融入到你寫的每段代碼中，而且會認爲就應該如此作。寫這篇博客是有原因的：看到公司作開發的同事寫的代碼，感受一方面是編碼風格上不一樣、有點兒各樹一幟——公司在開發上不是沒有規範，而是你們沒有把規範落實、去遵行，更何況規範比較粗略，這就致使在看或維護別人寫的代碼時，常常會感受跟本身的編碼風格差別比較大，閱讀起來比較費勁，甚至頭疼、有想抓狂的衝動。規範對於團隊開發至關重要也是必須的，要否則也不會有不少大公司(像華爲)都有本身比較嚴格和細緻的開發規範，其做用也毋庸置疑：能提升團隊開發的效率，確保編碼風格上的一致性，下降維護的成本...——想一想看，當一個團隊中你們都遵行規範，這個規範能夠小到類名或變量名的命名規範，也能夠大到模塊文件夾目錄結構，如規定：全局私有變量統一以'_'開頭，模塊對外提供的服務類，都統一放在service文件夾下...，如此這樣你在看別人寫的代碼，就跟看本身寫的代碼同樣(若是規範粒度越細，其類似度就越高，可能就難分你我了)，也能比較方便快速的看懂代碼的意圖和找到須要的類或方法；另外一方面，"代碼重構"作的並不夠好，即便是經驗比較豐富的程序員，其代碼中充斥着一些重複的代碼段，爲此在開會時我提出咱們應該注意"代碼重構"，並詢問他們對其見解，其答覆基本上是：開發時時間比較緊，不想花那點兒時間去進行"代碼重構"。而後，我就問"那樣是否是致使大家在維護本身的代碼時，連本身都會感受頭大和費時間"，他們的回答是確定的。其實，不想去作"代碼重構"的編碼，在之後維護中，你會花更多的時間去作當時用個一兩分鐘就能夠搞定的事，而當你把"代碼重構養成一種習慣"後，"代碼重構"就再也不是你認爲的"額外的事"，你會很天然也感受必需要這樣作。

      "代碼重構"並非說你對設計模式比較熟悉才能夠，由於很多程序員可能熟知各類設計或開發模式，但並無認識到"代碼重構"的重要性，也更沒有將其成爲一種習慣。就我本身而言，雖然我對設計模式知道的不多，也不會'駕輕就熟'的去使用，但我一直(大概是工做一年後到如今)以'確保本身寫的代碼裏沒有重複的代碼段'這個基本原則規範本身的編碼，也同時要求和提醒着本身：要保證每行代碼或每一個變量都有意義，沒有多餘的，並保持每行代碼都不可隨意改變順序以呈現編碼思路的清晰邏輯。

      最後，我想說的是：你應該在工做中多想和考慮，如：如何讓本身的代碼寫的讓別人用起來簡單易用...，不要只會'寫代碼'，也更不要盲目的追求技術上的狂熱將代碼寫的生澀難懂，增長了複雜度，好的代碼應該是：清晰、簡潔高效的實現。程序員，其實你能夠作的更好！