雖然本書所提供的實例、代碼均源於java，但是不管我們是使用什么編程語言，編寫出"好代碼"對於一個想成為優秀的程序員都應該是最基本的。
良好的方法命名、適宜的注釋、短小的方法、各種環境下的變量命名等等，這都是大師在多年編程中總結下來的經驗之談。
在網上經常會看到很多牛人是這么說的：“項目要注意可擴展、靈活性”、“要為以后的需求變更提供好的接口”、“要靈活使用設計模式”等等，仿佛各種各樣的項目功能，在設計之初就已經是如此完備，能應付各種各樣突如其來的需求變更，能一下子構建出如此完備的功能，更是我們這些新手所不能及，所崇拜的。
然而通讀本書之后，我得到的體會則是一開始編寫完成的功能都是丑陋的並不可能如此完備，不可能想的如此周到。能編寫出如此功能完備的代碼，也是要經過多次修改，隨着需求的不斷增加而完善的。作為一個優秀的程序員，對於“壞味道”的代碼不會置之不理的，他們總會花更多的時間去編寫“好代碼”。他們在編碼過程中不僅僅是完成任務，更多的時間花在編寫“好代碼”，最終就會出現我們所見到的更具可擴展、靈活性好，能更好的應對未來的需求變更。
可能會有不少人反對這些說法，項目在趕工階段時間是那么的寶貴，然而就開發而言，其實真正開發的時間大約占開發總時間的30%，而絕大部分的時間都是花費在無限的BUG修改、需求變更、測試上面，也許我們多花10%的時間在構建“好代碼”上面，換回來的卻是不一樣的。
也有人會有這樣的想法，對於老板來說，能按時完成公司要求的任務就行，然而時間緊迫的情況下，我們花費如此之多的時間在將“壞味道”代碼改造為“好代碼”上，老板也不會贊揚，反而會對我們的編碼效率、能力有着大大的懷疑。這種情況的確是大多數程序員不得不對“壞味道”代碼置之不理的原因，然而大家有沒有想過，我們對“壞味道”代碼置之不理，將來要回來面對並收拾爛攤子的仍然是我們自己（可能有人會暗中慶幸自己已經離開，這些爛攤子有其他人去處理）。
如果當初我們多花一些時間去編寫“好代碼”，在今后的修改當中，會給我們帶來不少省心的事情，編碼也是熟能生巧的，我們花費更多的時間在編寫“好代碼”上，對於“好代碼”我們的經驗也會更多，在開發當中，也能讓其他人感覺到“好代碼”所帶來的各種好處。對於其他的同事而言，“好代碼”能讓他們迅速理解代碼所代表的意思，更清晰的了解到功能所起到的作用，各個函數之間的關系。
就像大師舉的例子，寫一篇文章，先寫一個草稿，然后一遍遍的修改，最后得到一片好的文章一樣，“好代碼”猶如好文章，賞心悅目、條理清晰、方便閱讀等。
“好代碼”並非一蹴而就的，而是經過一次次重構、迭代產生的，正如編程不僅僅是一門技術，更是一門藝術。雖然我們不可能一下子就通過重構編寫出“好代碼”，但是隨着長時間的不斷練習，每一次的編寫過程當中，我們都能有所體會，經驗也會越來越多，那我們離編寫“好代碼”的優秀程序員也越來越近。
這是我個人在閱讀完該書的想法，有不足之處希望各位指出，謝謝!