《Clean Code》讀后感
品味完一本名著后，大家心中一定有不少感悟，為此需要認真地寫一寫讀后感了。是不是無從下筆、沒有頭緒？以下是小編整理的《Clean Code》讀后感，希望對大家有所幫助。
最近淺讀了《Clean Code》這本書，雖然由于知識水平的有限，很多地方沒有理解透徹，但還是令我受益頗多。
毫無置疑，軟件質量，不但依賴于架構及項目管理，而且與代碼質量緊密相關。這本書圍繞“代碼質量與其整潔度成正比”給出了一系列論述以及行之有效的整潔代碼操作實踐，“干凈的代碼，既在質量上較為可靠，也為后期維護、升級奠定了良好的基礎”。
第一章論述了“整潔代碼”。雖然我還沒有豐富的工程實踐經歷，但是第一章中提出的一種錯誤的想法“能運行的爛程序總比什么都沒有強”非常熟悉，在以往寫簡單的練習題時，即使代碼量很小，我首要追求的就是AC這道題，對代碼質量不管不顧，它也解釋了這種做法的原因，即：希望快點完成，早點結束手上的任務。然而，制造混亂將會帶來巨大的代價，往往混亂的代碼在以后的維護中將會越來越混亂，隨著混亂的增加，生產力將會降低趨向于零，后果不堪設想。開發者一方面被之前的混亂拖后腿，另一方面背負期限的壓力只好制造混亂，程序員太難了。文中提到做的快的唯一方法就是始終盡可能保持代碼整潔，可是我又不能讓我之前的開發者保持代碼的整潔，那這樣就導致程序員一方面要忍受之前的開發者制造的混亂，又要努力從現在開始盡量保持代碼的整潔，還是太難了，所以往往糟糕的代碼只會越來越爛，但是不能因為困難就制造混亂，我們要做負責任的開發者、程序員，不僅要為我們的project負責，也是為后來的開發、維護人員負責。保持代碼整潔，停止制造混亂，從我做起。不同的人對整潔代碼的定義不同，文中記錄了一些厲害的程序員的看法，比如Bjarne說“我喜歡優雅和高效的代碼。代碼邏輯應當直截了當，叫缺陷難以隱藏；盡量減少依賴關系，使之便于維護；依據某種分層戰略完善錯誤處理代碼；性能調至最優，省得引誘別人做沒規矩的優化，搞出一堆混亂。整潔的代碼只做好一件事”，即：“優雅”和“效率”；Grady的觀點與Bjarne類似“整潔的代碼簡單直接。簡潔的代碼如同優美的散文。整潔的代碼從不隱藏設計者的意圖，充滿了干凈利落的抽象和直截了當的控制語句”。文中還引用了好多人的看法，其中提到的“讓營地比你來時更干凈”總結出一條很好的規定。
接著，作者從“命名”、“函數”、“注釋”、“格式”、“對象和數據結構”、“錯誤處理”、“邊界”、“單元測試”、“類”、“系統”、“跌進”、“并發編程”等不同方不同層次分別闡述了寫整潔代碼需要遵守的小技巧，并給出了案例分析，以及3個Java項目的剖析與改進過程。
命名方面要做到名副其實，名稱應該能答復所有的大問題，它應該告訴你它為什么會存在，它做什么事，應該怎么用；命名要避免誤導，必須避免留下掩藏代碼本意的錯誤線索；命名要做有意義的區分；使用讀得出來的名稱；使用可搜索的名稱，例如用WORK_DAYS_PER_WEEK比數字5好得多；命名應該準確，每個概念對應一個詞，不用雙關語，添加有意義的語境但不要添加沒用的.語境。我在我為數不多的編程經歷中，就感受到了命名的難度，受限于自己的描述技巧和文化水平都太平庸，命名總是稀奇古怪，沒有規范。最近在學習交換的程序時，也深受命名的折磨，也許也是自己對協議的理解不夠透徹，總覺得程序里面一些PDU定義和協議里面的規定不夠統一，我就認為程序里面對PDU元素定義的名稱
應該與協議里保持完全一致，這樣清晰明了，對于我這樣的菜鳥新手，分析程序里定義的PDU一些元素的含義花了我好大力氣，深受打擊。
關于函數，第一規則是要短小，我一直明白這個道理，但是要做到還是很難；函數應該只做一件事，做好這件事，似乎好像做到這條要求，函數應該就會短小很多，要判斷函數是否不止做了一件事就是看是否能再拆出一個函數；函數別重復自己，分隔指令與詢問。還有一些規則，由于自己知識水平有限不能理解，只能在以后漫長的學習工作中慢慢體會實踐，例如每個函數一個抽象層級、函數參數最理想參數數量是零，其次是一，再次是二，應盡量避免三，在我的認知里還不能理解函數怎么能沒有參數，以及使用異常代替返回錯誤碼。
萬萬沒想到，之前都隨便寫的注釋也有講究，雖然有些規則不明白具體意義，只能在以后的實踐中慢慢體會實踐。“什么也比不上放置良好的注釋來得有用。什么也不會比亂七八糟的注釋更有本事搞亂一個模塊。什么也不會比陳舊、提供錯誤信息的注釋更有破壞性”，注釋的恰當用法是彌補我們在用代碼表達意圖時遭遇的失敗，我很贊成作者解釋的理由“注釋存在的時間越久，就離其所描述的代碼越遠，越來越變得全然錯誤，原因很簡單，程序員不能堅持維護注釋”。這一章讓我印象深刻，注釋不能美化糟糕的代碼，帶有少量注釋的整潔而有表達力的代碼要比帶有大量注釋的零碎而復雜的代碼像樣得多，與其花時間編寫解釋你搞出的糟糕的代碼的注釋，不如花時間清潔那堆糟糕的代碼。盡量用代碼來闡述解釋，作者認為好注釋有法律信息、對意圖的解釋、對某些晦澀的參數或返回值的意義翻譯、警告、 TODO注釋，千萬不要喃喃自語寫一些廢話注釋，能用函數或變量時就別用注釋。
關于格式，代碼風格和可讀性會影響到可維護性和擴展性，作者介紹了垂直格式和橫向格式。垂直格式上，應該向報紙學習，名稱應當簡單一目了然，源文件最頂部應該給出高層次概念和算法，細節應該往下漸次展開，垂直方向上每個函數之間應該有空白行隔開，被調用的函數應該在執行調用的函數下面；橫向格式上，賦值操作符周圍加上空格字符，函數名和左圓括號之間加空格，乘法因子之間不加空格，加減法運算項之間用空格隔開，用好縮進。最后要服從團隊規則，要讓一組開發者采用團隊規則從而軟件擁有一以貫之的風格。
寫整潔代碼，需要遵循大量的小技巧，貫徹刻苦習得的“整潔感。這種“代碼感”就是關鍵所在。寫代碼和寫文章等創作很像，其實倒不如把寫代碼也看成一種創作，在寫論文或文章時，你先想什么就寫什么，然后再打磨它，初稿也許粗陋無序，你就斟酌推敲，直至達到你心目中的樣子，代碼也需要打磨直至成為整潔的代碼。但是感覺實際工作中，大部分代碼調試至通過測試就耗費了大量精力，通過測試后也就沒有更多力氣來打磨代碼了。
在閱讀這本書的時候，我感到非常吃力，有沒有Java基礎的原因，也有缺乏軟件開發一些基本理念的原因，還有缺乏實戰的經歷，很多應用背景我都理解不了，很多地方對我來說有點晦澀難懂，在今后的學習、工作中，要繼續對其中提到的規則進行理解、消化、實踐最終變成自己在編程中本能的能力，希望自己能在以后的學習中多多積累軟件開發的一些“常識”，能夠養成良好的軟件開發的習慣，形成屬于自己的軟件開發思維，我覺得這些大牛程序員就是在長時間的實踐中不斷思考不斷通過思考提升自己的代碼質量，然后日積月累形成了屬于自己的一套理論。我也希望自己在寫代碼的時候能夠多思考，怎么寫更好，怎么寫能夠既實現功能又整潔、可讀性高、可維護性和可擴展性好，這一定需要長時間的學習、實踐、思考才能慢慢進步逐步提高。不要僅僅只是追求實現功能，這只是最基本的目的，我覺得隨著自己的進步，可以提高對自己的要求，寫混亂的代碼即使實現了功能也要丟棄它，還希望自己有一天能有能力把我負責的程序都能進一步規范一下。看了這本書，程序員的工作在我心中又上升了N個階層的難度，讓我明白自己還有很多基礎知識需要學習，還需要大量實踐實戰，默默給自己加油。
【《Clean Code》讀后感】相關文章：
clean的反義詞08-10
Unit 11 Could you please clean your room?說課稿11-04
《名人故事》讀后感-讀后感06-23
高老頭讀后感作文-讀后感04-12
父親的病讀后感-讀后感04-12
《童年》讀后感_讀后感700字09-13
童年600字讀后感-讀后感06-19
《童年》700字讀后感-讀后感06-19