最近讀了一本書，名字大家都看到了：《代碼整潔之道》，之前一直只是聽說過這本書的大名，卻一直沒有進行拜讀，最近想起來了就想著看一看，不看不要緊，看了之后就像吃了炫邁，根本停不下來。。。雖然這本書已經出版了十幾年的時間，但里面的理論到現在為止也不過時。

有人也許會以為，關于代碼的書有點兒落后于時代–代碼不再是問題;我們應當關注模型和需求。確實，有人說過我們正在臨近代碼的終結點。很快，代碼就會自動產生出來，不需要再人工編寫。程序員完全沒用了，因為商務人士可以從規約直接生成程序。扯淡!我們永遠拋不掉代碼，因為代碼呈現了需求的細節。在某些層面上，這些細節無法被忽略或抽象，必須明確之。將需求明確到機器可以執行的細節程度，就是編程要做的事。而這種規約正是代碼。

看這本書的那種感覺很奇妙，有時感覺作者說地真對！有時感覺作者罵地真對！有時感覺作者諷刺地真對！還有時看到作者列出的真實代碼中的錯誤示例，再看到作者寫出的優化后的代碼，內心不禁在想：太妙了，代碼本應這樣啊！

沒錯，代碼本應該是整潔的，也本應該是好理解、易擴展的！我們常說的設計模式也并不是一種炫技，而是幾十年來的老前輩們總結出來的經驗，是為了讓你的代碼更好維護的，是一種理所應當。

在工作中遇到爛代碼的可能性是 100%，即使是很厲害的大佬寫的代碼，在不知情的情況下讓你去看，看了一會后都會得出以下結論：“寫的啥玩意啊，看都看不懂，亂七八糟的語法糖，考慮過后面工作的人么？什么設計模式，什么各種模塊，直接寫一塊不好么？” 假設的可能有點夸張，但也都是人之常情。有時工作中遇到的爛代碼是假的，可能是由于當前自己的技術水平不夠，不理解；當然還有一部分可能真的是爛，但是這種情況下還是要做出一些改變！

現在讓大家看幾個月之前自己寫的代碼可能都會覺得寫的一團糟，用當前的眼光來看可能會有更好的方式或方法來實現，如果你有這種想法的話，請付諸實踐！不要等，哪怕是一個單詞的拼寫錯誤、一段本不應該寫兩遍的邏輯、一段沒有進行格式化的代碼。。。。亦或者是比較大規模的代碼改動，改完之后可擴展性會更強，維護起來會更加容易。千萬不要等，不要忍受當前的爛代碼，代碼本就是一直在重構的一個過程，沒有哪段代碼從出來就不改。下面這段話是書里的內容：

我們都曾經瞟一眼自己親手造成的混亂，決定棄之而不顧，走向新一天。我們都曾經看到自己的爛程序居然能運行，然后斷言能運行的爛程序總比什么都沒有強。我們都曾經說過有朝一日再回頭清理。當然，在那些日子里，我們都沒聽過勒布朗(LeBlanc)法則:稍后等于永不(Later equals never).

當然很多人會說：“項目中的屎山代碼，我能在上面雕花已經很厲害了，還要干什么，即使我知道那塊寫的不好，但我也不會去動，因為現在它處于一個穩定的狀態，如果我去修改了之后，出了問題全是自己背，吃力不討好！”這也確實是很多人的現狀，考慮的也不無道理，但在這里咱們單純從代碼的角度來看，從寫代碼的初心來看，早早的就背道而馳了。

代碼格式不可忽略，必須嚴肅對待。代碼格式關平溝通而溝通是專業開發者的頭等大事。 或許你認為“讓代碼能工作”才是專業開發者的頭等大事。然而，我希望本書能讓你拋掉那種想法。你今天編寫的功能，極有可能在下一版本中被修改，但代碼的可讀性卻會對以后可能發生的修改行為產生深遠影響。原始代碼修改之后很久，其代碼風格和可讀性仍會影響到可維護性和擴展性。即便代碼已不復存在，你的風格和律條仍存活下來。

我有代碼潔癖，看不了沒有格式的代碼，看著有的項目中一個函數幾百行甚至更多，里面各種重復邏輯，if/else不知道嵌套了多少層，表面看是邏輯復雜，再轉念一想，為什么不用工廠、或者寫一些別的類來簡化下邏輯。這時肯定有人會站起來反對：“明明很簡單的邏輯，非得使用什么設計模式，搞得一團亂還看不懂。。” 如果只是一個if/else，或者邏輯比較簡單肯定沒必要，但是邏輯復雜的情況下光if/else也足夠將人搞暈，且當需求改變時代碼變得難以維護。

我之前一直覺得寫完代碼格式化是正常的，是基本操作，但是工作中發現好像不是一個基本操作，格式化并不涉及到專業能力，而是態度，連格式化都懶得做，你說你寫出的代碼經過了嚴格的測試。。。。想起之前上學時老師經常說的一句話：作業會不會是能力問題，而做不做就是態度問題了。

說這些并沒有什么惡意，僅是這本書的讀后感，讀完后就好像和作者已經是相識多年的老友，相視一笑。