序
經過一段時間終於有機會再把它拿出來拜讀了！這本由 Robert C. Martin（Uncle Bob） 所撰寫的著作，為 《Agile software development principles patterns and practices.》（敏捷軟件開發）一書的前傳。而無暇的程式碼（Clean Code）究竟表示的是什麼？我想推薦序一文做了非常良好的解釋：
“God is in the details.” -Ludwig Mies van der Rohe 「神就藏在細節裡面。」
在推薦序中，James O. Coplien 引用了建築大師 Ludwig Mies van der Rohe 的這句名言來開場。描述程式開發，如同是在處於建築行業一般，我們在開發程式中每個環節，其實就如同在蓋房時所堆砌的一磚一瓦一樣，要成為建築大師、優良的程式開發人員，我們必須小心謹慎地對待每個角落。好比在 變數命名 議題上，我們總是對待變數得像是對待自己的小孩一般，不會隨意取下它們的姓名。
但真正在面相專案中的程式開發時，我們是否會受到時程開發、臨時需求變動等等需求，而影響到了這些想法？還是能像日本維護的優良方針（Total Productive Maintenance）中，身美（Shutsuke）概念一樣 保持堅守自身的信念？
身美（Shutsuke）在日本維護優良方針中表示，在工作實踐的過程中，能夠遵守紀律、並無時無刻的反省自身在任務上是否能有改善之處。
我想就 James O. Coplien 所引用的另一句丹麥諺語所說的一樣：
丹麥諺語：
“Ærlighed i små ting er ikke nogen lille ting.” 「在小事情上誠實不是一件小事情。」
當我們在小事都能夠堅守信念時，在大事上就不致馬虎了。有夢最美希望相隨
為什麼我們需要無瑕的程式碼？
在寫得非常精闢的序文之後，隨即進入了第一章節 無瑕的程式碼，而第一章正是描述為什麼我們會需要無瑕的程式碼。
在實際開發過程中，比起撰寫真正提交出去的程式碼，我們更多時間是花費在閱讀之前的程式碼，我們從閱讀之前專案中留下來的程式碼，來暸解前開發者的思維與開發架構；或是來維護前幾個月、甚至是幾週前由自己所撰寫的程式碼。我們總是盡可能模仿裡面的味道，再來烹飪出類似的料理，好讓後續接手維護的人員，能夠品嘗到一手好菜。
有時候並非是因為我們擁有強大的閱讀能力，而是厲害的開發者能端出五星級的料理，讓其他人輕易讓品嚐其中的滋味。
如果我們若不這麼做、迫於專案時程關係，或是不慎端出了臭味道的料理怎麼辦？有些經驗的程式開發者可能已經透過了惡劣的環境來學習過了。如前面所說，我們花費在閱讀程式碼的時間已經隨著專案的大小，長得越來越大，閱讀時間也可能從短短的幾分鐘，進化到弄了一小時才解決，而越雜亂的程式碼也將花費更多的時間來去維護。
童子軍原則：讓你所到之處，離開後比原先來得更加乾淨
如同營地一般，某個專案中的程式可能已經歷經了一段風霜。不論當初撰寫專案的人是誰，我們所及之處的程式碼，最終應該都必須保持乾淨，在將來後續維護時，才不會受到歷史的阻礙。
當然，你也可以選擇重構或死亡，但在不重構的前提下，我們還是能做很多事的。
重新解構再重構
標題中所提到重新解構再重構的意思是：這系列的文章拜讀，不會只是閱讀書本的心得文章而已，我所希望的是能藉由自己的思維將其內容重新解構再重構，透過這樣的方式訓練自己的思維，組合出屬於我自己的脈絡。
其中，解構的部分並不會打亂整本書的章節，因為我認為作者這樣規劃有其中的含意，而且如果我這麼做的話，也就喪失了許多原書的大脈絡；因此，解構的部分會縮小至章節的內容，讓整個系列的文章有如每個原書章節中的再譯版本，希望使有閱讀過此書的讀者也能夠有新的讀書體驗。
當然，如果你從來沒看過這本書的話，我仍然很推薦你一定要看過一次原書。
而在下一章開始，此系列文章將會從程式中最重要的部分－－命名（naming）部分，開始講起！