相信程序猿們敲代碼時都經歷過這種階段。一開始，懷着極大地誌向，打算把代碼寫的儘量優雅，各個方法清晰易讀。但隨着時間的推移，項目的逐步增長，發現代碼越寫越亂，自己花費了大量的時間在代碼的調試上，經常是改了一處，卻牽扯到其他衆多地方，級聯的錯誤，而導致你把大量的時間花費在回憶自己先前的邏輯與代碼調試中，而陷入了“焦油坑”中。經過了這個過程，心中唯一想做的就是儘快把這份代碼寫完，早些擺脫這堆臭代碼，先前的志向種種早已不復存在了。
樂觀的以爲自己在下一個項目中，再次從零開始編寫代碼，只要多注意，就能夠寫出一個好的代碼，殊不知卻永無改進，下一次，仍然一團糟！
看來，我們需要一些手段，一套好的方法，來幫助我們構建出更好的代碼。
1、 善用單元測試工具、而非僅使用控制檯的輸出
我想是因爲軟件測試課，教我們各種測試的方法，黑盒、白盒、單元測試、功能測試、系統測試…大量的測試，一個完備的測試有語句覆蓋、路徑覆蓋、分支覆蓋、條件覆蓋…讓我們對測試充滿了恐懼，程序的開發者，能不接觸就少接觸吧！
正是這種方式，讓我們失去了改善代碼開發效率、擺脫無盡的調試過程的有力武器。意外中接觸到了TDD（測試驅動開發），嘗試了裏面教我們的“在編寫代碼前先寫好測試用例”的方式來進行項目開發。初期，我們應該都是使用控制檯的輸出語句來進行正確與錯誤的判斷，但這種方式有幾點的弊端：1、輸出語句與主代碼相雜糅，導致代碼不乾淨。2、往往在某個功能實現完畢後，便刪除了這些測試方式（輸出語句），他們難以被複用。3、我們需要人工驗證輸出的結果是否與我們預期的相符合，如果多次調試，勢必耗費大量時間。
需要一種方式，將我們的測試與主體代碼相分離，並且其他的存在不會對主體代碼產生干擾，如果還能夠減少我們人工驗證的工作量那就更好了。Java提供了JUnit的測試框架，這是由kent beck（極限編程之父）與他的同時共同開發出來的一套測試框架。提供給我們十分方便的通過測試套件進行單元測試。我們只需在完成某個功能或者寫完某個方法後，在相應的測試類中添加測試方法，便能夠對所實現的功能進行測試，通過斷言來驗證匹配輸出與我們預計的結果是否吻合。這樣，我們在對程序做任何的修改之後，都能夠通過運行測試用例及時發現bug，對其跟蹤。而不是在改了代碼一段時間後，發現修改的代碼引發了一系列的問題，而需要耗費大量時間修復。編寫測試，雖然增加了一部分時間，但能夠減少大量的程序調試時間（這話是前輩說的，但我親身體驗過）。並且讓自己的思路更清晰，何樂而不爲呢？
推薦資料：《Agile Java》，上網下了他的電子版，雖然只有前四章，但對TDD有了大體的瞭解。
《重構：改善有效代碼的設計》，第四章也有提到測試驅動開發。
《測試驅動開發》Kent Beck寫的，沒看過，應該不錯。
編寫測試不是爲了應付交差，而是讓自己更有效率的開發，記住，在值得的地方寫測試，將力氣花在大頭上。“編寫不完善的測試用例並實際運行，好過完美測試的無盡等待”。
2、 重構不是因爲你的代碼很糟，而是讓你的代碼更棒
記得我和一個同學推薦《重構》這本書時，他回覆我說，“你說我的代碼需要重構，是說我的代碼寫的很爛麼？”雖然他出於半開玩笑的態度說這句話，但可知他對於重構，並無意識，覺得重構是針對爛代碼而言的。
其實，重構的意義，不僅僅是對不好的代碼內部結構的調整。畢竟沒有人在做項目時，能夠寫出一首完美、無需變動的代碼。那麼，在代碼需要調整的時候，如何既能夠保證代碼的可讀性，又能夠保證代碼的正確性進行結構的修改呢？面對一個不具有很好的擴展性的代碼，如何能夠最大的利用原有代碼，去添加方便的新功能？
在開發階段引入重構，習慣性的重構自己的代碼，讓他更具可讀性、變得更易修改，這樣，在你今後需要修改代碼或者引入新功能的時候，更有效率。清晰地代碼也減少了你沉溺於尋回早期設計思路的泥藻。回到最初，你一開始不就希望能夠寫出一份設計清晰、方便閱讀的代碼麼？
開始編碼前的設計是必不可少的，但如果一味的期望前期的設計能夠完美的呈現於最終的代碼中，難度難免有些偏高，並且設計的成本風險也很大。重構的方式就猶如迭代的開發方式的細化，能夠讓我們不斷對整體的設計進行調整，讓他能夠達到一個最佳位置，以最好的方式呈現。
掌握測試的方式，就像是讓外界的人幫助監察自己的不足，及時發現，及時告知。掌握重構的方式，就像是及時審視自身，發現自己身上的不足、缺點，繼而進行改正。內外兼顧，才能夠做的更好。
掌握好這兩個武器，我想，當自己穿梭於代碼中，也能夠遊刃有餘了吧！