《Clean Code》读后感

《Clean Code》读后感

WTT整理,仅供参考，希望能够帮助到大家。

最近浅读了《Clean Code》这本书，虽然由于知识水平的有限，很多地方没有理解透彻，但还是令我受益颇多。

毫无置疑，软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关。这本书围绕“代码质量与其整洁度成正比”给出了一系列论述以及行之有效的整洁代码操作实践，“干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好的基础”。

第一章论述了“整洁代码”。虽然我还没有丰富的工程实践经历，但是第一章中提出的一种错误的想法“能运行的烂程序总比什么都没有强”非常熟悉，在以往写简单的练习题时，即使代码量很小，我首要追求的就是 AC 这道题，对代码质量不管不顾，它也解释了这种做法的原因，即：希望快点完成，早点结束手上的任务。然而，制造混乱将会带来巨大的代价，往往混乱的代码在以后的维护中将会越来越混乱，随着混乱的增加，生产力将会降低趋向于零，后果不堪设想。开发者一方面被之前的混乱拖后腿，另一方面背负期限的压力只好制造混乱，程序员太难了。文中提到做的快的唯一方法就是始终尽可能保持代码整洁，可是我又不能让我之前的开发者保持代码的整洁，那这样就导致程序员一方面要忍受之前的开发者制造的混乱，又要努力从现在

开始尽量保持代码的整洁，还是太难了，所以往往糟糕的代码只会越来越烂，但是不能因为困难就制造混乱，我们要做负责任的开发者、程序员，不仅要为我们的 project 负责，也是为后来的开发、维护人员负责。保持代码整洁，停止制造混乱，从我做起。不同的人对整洁代码的定义不同，文中记录了一些厉害的程序员的看法，比如 Bjarne 说“我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏;尽量减少依赖关系，使之便于维护;依据某种分层战略完善错误处理代码;性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱。整洁的代码只做好一件事”，即：“优雅”和“效率”; Grady 的观点与 Bjarne 类似“整洁的代码简单直接。简洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句”。文中还引用了好多人的看法，其中提到的“让营地比你来时更干净”总结出一条很好的规定。

接着，作者从“命名”、“函数”、“注释”、“格式”、“对象和数据结构”、“错误处理”、“边界”、“单元测试”、“类”、“系统”、“跌进”、“并发编程” 等不同方不同层次分别阐述了写整洁代码需要遵守的小技巧，并给出了案例分析，以及 3个 Java项目的剖析与改进过程。

命名方面要做到名副其实，名称应该能答复所有的大问题，它应该告诉你它为什么会存在，它做什么事，应该怎么用;命名要避免误导，必须避免留下掩藏代码本意的错误线索;命名要做有意

义的区分;使用读得出来的名称;使用可搜索的名称，例如用WORK_DAYS_PER_WEEK 比数字 5 好得多;命名应该准确，每个概念对应一个词，不用双关语，添加有意义的语境但不要添加没用的语境。我在我为数不多的编程经历中，就感受到了命名的难度，受限于自己的描述技巧和文化水平都太平庸，命名总是稀奇古怪，没有规范。最近在学习交换的程序时，也深受命名的折磨，也许也是自己对协议的理解不够透彻，总觉得程序里面一些PDU 定义和协议里面的规定不够统一，我就认为程序里面对 PDU 元素定义的名称

应该与协议里保持完全一致，这样清晰明了，对于我这样的菜鸟新手，分析程序里定义的 PDU 一些元素的含义花了我好大力气，深受打击。

关于函数，第一规则是要短小，我一直明白这个道理，但是要做到还是很难;函数应该只做一件事，做好这件事，似乎好像做到这条要求，函数应该就会短小很多，要判断函数是否不止做了一件事就是看是否能再拆出一个函数;函数别重复自己，分隔指令与询问。还有一些规则，由于自己知识水平有限不能理解，只能在以后漫长的学习工作中慢慢体会实践，例如每个函数一个抽象层级、函数参数最理想参数数量是零，其次是一，再次是二，应尽量避免三，在我的认知里还不能理解函数怎么能没有参数，以及使用异常代替返回错误码。

万万没想到，之前都随便写的注释也有讲究，虽然有些规则不明白具体意义，只能在以后的实践中慢慢体会实践。“什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性”，注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败，我很赞成作者解释的理由“注释存在的时间越久，就离其所描述的代码越远，越来越变得全然错误，原因很简单，程序员不能坚持维护注释”。这一章让我印象深刻，注释不能美化糟糕的代码，带有少量注释的整洁而有表达力的代码要比带有大量注释的零碎而复杂的代码像样得多，与其花时间编写解释你搞出的糟糕的代码的注释，不如花时间清洁那堆糟糕的代码。尽量用代码来阐述解释，作者认为好注释有法律信息、对意图的解释、对某些晦涩的参数或返回值的意义翻译、警告、 TODO 注释，千万不要喃喃自语写一些废话注释，能用函数或变量时就别用注释。

关于格式，代码风格和可读性会影响到可维护性和扩展性，作者介绍了垂直格式和横向格式。垂直格式上，应该向报纸学习，名称应当简单一目了然，源文件最顶部应该给出高层次概念和算法，细节应该往下渐次展开，垂直方向上每个函数之间应该有空白行隔开，被调用的.函数应该在执行调用的函数下面;横向格式上，赋值操作符周围加上空格字符，函数名和左圆括号之间加空格，乘法因子之间不加空格，加减法运算项之间用空

格隔开，用好缩进。最后要服从团队规则，要让一组开发者采用团队规则从而软件拥有一以贯之的风格。

写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的“整洁感。这种“代码感”就是关键所在。写代码和写文章等创作很像，其实倒不如把写代码也看成一种创作，在写论文或文章时，你先想什么就写什么，然后再打磨它，初稿也许粗陋无序，你就斟酌推敲，直至达到你心目中的样子，代码也需要打磨直至成为整洁的代码。但是感觉实际工作中，大部分代码调试至通过测试就耗费了大量精力，通过测试后也就没有更多力气来打磨代码了。

在阅读这本书的时候，我感到非常吃力，有没有 Java基础的原因，也有缺乏软件开发一些基本理念的原因，还有缺乏实战的经历，很多应用背景我都理解不了，很多地方对我来说有点晦涩难懂，在今后的学习、工作中，要继续对其中提到的规则进行理解、消化、实践最终变成自己在编程中本能的能力，希望自己能在以后的学习中多多积累软件开发的一些“常识”，能够养成良好的软件开发的习惯，形成属于自己的软件开发思维，我觉得这些大牛程序员就是在长时间的实践中不断思考不断通过思考提升自己的代码质量，然后日积月累形成了属于自己的一套理论。我也希望自己在写代码的时候能够多思考，怎么写更好，怎么写能够既实现功能又整洁、可读性高、可维护性和可扩展性好，这一定需要长时间的学习、实践、思考才能慢慢进