Clean Code读后感精选
《Clean Code》是一本由Robert C. Martin著作，Prentice Hall PTR出版的Paperback图书，本书定价：$35.44，页数：464，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《Clean Code》精选点评：
●公司力荐书目
●一个有故事的老男人
●先往短里改……抽象层什么的以后再说……
●还可以，有写启发
●fish like coding
●球球我的同事们都读一读 代码整洁靠大家 快乐工作你我他
●Josh recommended.
●实际重构的两章（serialDate跟CommandArg跳过了）。 怎么保持良好的代码结构，提高可读性还是需要多练习。
●公司搬砖要求读
●翻了翻以前的代码"这代码能看?"。实践后有种当时从代码不加空格改到加空格时候的感觉。
《Clean Code》读后感(一)：细节决定成败
距离第一次看鲍勃大叔的"敏捷开发实践与模式"那本书已经有好多年了, 与那本书相比, 这本书相对来说更强调细节, 如果前一本书强调从大的方面, 比如从设计上, 从方法学上如何写出好的程序, 那么这一本书则是来强调从类的结构, 方法的布局, 变量的命名上阐述如何写出好的代码. 这本书基本上可以和kent back的"实现模式"那本书相提并论, 不过在有些理论上让我们从其他的方面看到了为什么, 如何写出好的代码. 另外这本书也让我明白了很多长期以来一些让我很纠结的原则, 比如一个方法只应该做一件事, 那么一个函数里面包含多个步骤, 每个步骤都做一件事, 那么多个步骤加在了一起岂不是做了多件事么？ 而鲍勃大叔很好的解释了这个问题: 处于一个方法中同一抽象层级的多件事可以认为是一件事. 只有一个方法中同时处理了处于不同抽象层次的事物才违反了这个原则.
《Clean Code》读后感(二)：任何好的code都是不断修改完善的过程
以前以为好的code就像李白的斗酒诗百篇，王羲之的醉酒兰亭序，是一挥而就的产物。但读完此书的大部分篇章才发现，文章给人最大的感触就是所有的好的code都是经过不断的refactor，不但的修改，一步步的达到最终的效果。记得一位同事说过，其实我们开发的过程，大概只有四分之一的时间是用来完善设计文档中的功能，然后四分之三的时间都是用来不断的修改，重构直到完成我们最终的状态。
这本书更像是一本programmer的枕边书，点很细，很实用。尤其在提高整体的代码质量上具有非常显著的效果。值得不但的品读，而且完全是目录就可以作为一个一个的tips来指导高质量的程序开发。
比如在对于函数的说明上：
1. Small.
2. Do one thing
3. One level of Abstract per function
4. Replace some switch construct statement with abstract factory method.
5. Function parameters( Common one or two).
6. Have no side effect.
7. Prefer exception for return error code(error code is an old-fashion way!)
8. Don't re-invent the wheel!!! most refactor process lie in.
值得说明的是，书的粒度比较细，虽然有很多Design层面的东西，但也往往是为了说明一些更细节的问题。有时也会发现书中的很多principle显的太多，太难以掌握，但其实随着经验的增长，代码量的增加，渐渐会发现有很多原则本质上是相同的，就比如repeat这个原则，当我们真正的做到，do one things and keep the function small, 很多时候也就能降低代码重复率了。再者对于one level of abstract per function 和抽象工厂模式，很多时候在一些代码中如果我们不用抽象工厂模式就会在程序逻辑中引入了对象构造本身的工作，而这另一方面就会导致程序逻辑中显的混乱，比如不再是do one thing, 或者不再是on the level abstract level.
再者，比如书中提到了AOP经典模式的应用，log4j, transaction process等都可以通过如俄罗斯套娃般的proxy reflection来解决。然和深入的分析了proxy的实现方法，这些都给人一种焕然一新的感觉。
《Clean Code》读后感(三)：这都是为了自己好
我一直觉得自己是没脸称自己是个程序员的，但是人渐大每当别人问起”做什么的”的时候，我只好把“写代码”这三个字抛出来，大抵能换到一点对方惊叹和虚荣心的满足，当然在真正的程序员们面前是从来没有得逞过的。
工作两年以来我也试图努力看过《重构》，《代码大全》等书来提升自己，但从来没有现在这本《Clean Code》这样醍醐灌顶，让我满脸羞愧决定痛改前非。
当时在高铁火车上蛋疼翻开的时候，这书关于代码细节的强调就让人耳目一新，它完全不提倡也不支持能运行的代码是基础的论调，论到“神蕴藏于细节当中”以及举例日本管理者强调认真的日常工作发挥的作用之巨大都是当头一棒，不过想想也是，会看这本书的程序员们应该多少抱着提高代码质量的打算吧。
不过肯定最重要的就是，如果你认真对待你的工作（或者说你的代码），那么代码也会给你巨大的回报。也就是如果你不了解为什么要写高质量的代码和重构的重要性，看再多这种“宝典”也无济于事。这也许就是我过去两年未能取得充分进步的原因吧。
不可否认这个世界就是有“代码感”很好的人，还有更多我这种思维混乱，经常随心所欲写代码的人。也曾经以为写代码只不过是一种手段，甚至有那种通宵噼里啪啦打字的良好感觉的时候，但其实回过头一看，那些烂代码自己都不愿意再多看一眼，大程作业、毕业设计混过了就混过了，甚至有时会拿同年龄的人还有人不会写代码而我还凑活作为逃避的理由呢！
后来运气好，进了一个大公司开始写游戏的客户端。被直属上司骂了好几次，“你告诉我你为什么要这么写这段？！”，“为什么不先看看别人写的部分”，“你自己跑过没有？凭什么让测试为你加班”……才开始领悟到原来写代码是要用“脑子”的！
不要嘲笑我为什么以前没有想到“写代码”是要用脑子的，其实我学习能力很强，反应也快，每次交代的任务还是完成地挺快，但也许正是因为这些掩盖了我代码质量很差的后果。每当需要在模块上添加新东西的时候，我也是自己修改自己的代码，有的时候觉得写得烂了就重构也不会花太多时间（当然辛苦的还是测试）。而往往动手太快，想得太少导致了最后我离职后，同事打开我曾经自己都看不下去的一个臭名昭著的炼制装备的模块苦不堪言，在这里默默地鞠个躬。
当然我不可能真的写代码不动脑子，否则也写不出来了=_= 但脑子动得太少是绝对的。其实我一直也对到底应该花多少力气在某些细节上面深表疑惑，也就缺乏动力改掉各种不良习惯。有些公司可能牛人很多，流程规范，我不敢说ex公司的坏话，但是仔细想来似乎还欠缺很多，很多事情还是全靠程序员的个人责任感在维持。
如今遇到这本书，仿佛又回到了刚参加工作哪会儿战战兢兢的感觉，“把东西做得漂亮点儿”绝不只指UI和视觉效果，变量名取得好听点，仔细琢磨；类与函数的权责划分得清楚点，就算只有自己用，“头上三尺有神明”，老天爷也会奖赏你的！毕竟效率高是最甜美的果实。
《Clean Code》读后感(四)：写点干净的代码
说实话，我一直在琢磨<clean code>这本书的目标人群到底应该是谁。对于在校学生，甚至刚刚工作了一两年的fresh coder，这本书的价值并没有想象的高。原因比较简单：clean code这本书的大部分内容是建立在作者大量编程实践之后的回溯和反思，类似于经验提炼式的总结。如果读者没有一定的实践功底，很容易忽略很多看起来像常识一样的细枝末节，而往往那些细节才是写出clean code的关键。从另一个角度上说，看书的时候讲究一个悟字，悟来自于自身的经验与作者讲述内容的碰撞，碰撞后产生深层次的交流和记忆。如果只是填鸭式的说教，那么效果自然不会理想。扯了这么多，我来说说书中让我印象深刻的观点。
语义的准确性。在代码的可读性和随意性上，作者显然坚定的站在了前者的立场上。作者认为，每一行代码都像是写文章的每一句话，你要时刻考虑将来的读者（包括你自己）阅读时的体验。变量命名是否准确，语义是否通达。相信我，这不是一件容易的事情。有多少程序员真正愿意敲出"daysSinceCreation"作为变量名，当他可以简单的用"d"之类的变量名混过去的时候。记得曾经有一次面试一位dev-2 level的程序员的时候，算法题不是很难，但是细枝末节很多。面试者不慌不忙的敲代码，长而准确的命名所有变量，完成后代码读起来一气呵成，令人印象深刻。自己给出的review中重要的一个加分点就是他的代码中有"very nice long variable names".
函数的有效组织。无论是早期的过程性语言还是目前工业界主流的面向对象语言，函数都是最核心的组成部分。甚至在面试的时候，函数也是实现算法/解决问题的基本单元。作者的主要观点还是很有意义的，比如函数的参数最好不要超过两个，否则阅读者的记忆成本会大幅增加（深有体会，最讨厌的就是在函数调用和签名之间来回确认）；函数中不要传递flag参数，比如doSomething(false)；工作的小组里面确实有函数这么写，时间长了也算是能理解，但确实是ulgy code。还有一个Interesting point就是每个函数只应该处理一个抽象层面的事务，宁愿要很多很多的small function也不要一个clunky big function。这个嘛，愿望是好的，但总感觉有点过于理想化。我并不认为写一堆一两行的函数组合起来会有多好的阅读性。其实只要一个函数的长度适中，阅读性好，那么函数内的抽象层次并不一定要卡死，灵活和可读性应该是要兼顾的。
对于comment和format，选择性的看吧，我总觉得fresh graduate最喜欢改这些东西。并非说这些细节不重要，只是我认为还有太多太多更重要的事情需要程序原来关心。
系统设计。终于到了系统设计，这才是个人最关心的章节，可惜作者虽然说了很多大的概念，比如seperate of concern, dependency injection, TDD等等，但是都没有展开说。聊seperate of concern，作者拿启动服务时各种依赖的初始化作为例子，意在说明初始化的问题就应该在初始化的时候搞定，而不应该用lazy initialization在程序中动态初始化依赖。我个人是赞同这个观点，当代码中大量充斥lazy initialization的时候，调试和阅读代码就完全是悲剧。但更重要的是如何在系统功能的分配上实现seperate of concern, 作者蜻蜓点水般跳过，可惜。究竟怎么在系统层面上实现clean code，看来还是要靠自己的日积月累，并非读一本书就可以达标的。
综上，这本书值得一读，但是过于推崇，大可不必。