《编写可读代码的艺术》读后感1500字
代码可读性是衡量代码质量的重要指标，在我看来甚至是最重要的指标，相比较读代码的时间，其实我们绝大多数时间在阅读别人的代码，所以我一直有一个观念，写代码的时候花几分钟时间思考一下，怎样更容易理解一点，可能就能节省别人（或者一段时间后的你自己）后面好几个小时的阅读时间，这是一件非常值得去做的事情。
在我短暂的工作经验里面，很遗憾的是，我碰到的代码基本都是可读性很差的代码，这真的浪费了我很多时间去理解区中的逻辑；更不能接受的是，有些逻辑隐藏很深，很容易造成遗漏引发线上问题；而且这些代码充斥在所有的项目里面，在你搞不清楚的情况下，你也很难对这些代码进行优化或者重构，从而陷入到一种恶性循环。
我也思考过这样的现状的原因，一方面管理层对这个方面的忽视，大部分决策者是无法关注代码这些细节的层面，只能关注到功能需求方面，所以可读性这个问题，基本就是底层开发人员自己的问题了；而另一方面，这些开发人员又没有受到很好的引导（这依赖于一种文化沉淀与传承），受到的基本是来自于业务需求排期的压力，所以自然而然就不会太关注这个事情。在这样一个客观现实下面，你想要做好这件事情，就基本只能依赖开发人员的自我驱动能力以及自身的领悟学习能力了吧，但是当你真正考虑要做好这件事情的时候，你所收获的东西一定会比你想象中的要多得多。
这本书里面提到的一些思想，是现在主流思想很好的总结和提炼。首先是命名，命名可能是最简单也是最有效的提高可读性的方法了吧，一个好的命名能让你的代码读起来就想自然语言一样，也就不需要在写注释了。命名这块平时可以注意多多积累，很多场景是类似的，好的命名也是可以复用的，也可以多一些好的库的接口，多学习参考别人的比较成功的命名。
然后就是注释这个问题，我之前一直有一个观点，真正好的代码其实是不需要注释的，因为代码本身就已经足够清晰了，任何额外的注释都会显得多余，遗憾的是，现实工作中我们碰到的大部分注释就是多余的，设置会误导读者。这本书里面提到一个关于“导演注释”的概念，我觉得非常的贴切，这可能才是我们真正需要的注释吧，作为作者，你当时的想法是什么？你为什么要这么写？为什么没有那么写？你有没有考虑过其他的方案？这样的注释是很有价值的，他不仅能帮助我们理解这段代码的含义，同时还能帮助我们去判断这段代码有没有过时，有没有更好的方案，能帮助我们优化和重构这段代码，这样的注释是有生命力的，这样的代码能不能地成长，不断地变得越来越强大。
然后是控制流程的问题，简化你的逻辑，把代码写短，让嵌套更少。
组织你的代码，把代码分成不同的逻辑块，每块只做一件事情，保持高内聚低耦合。其中有一个观点很有意思，理清楚你的业务需求，不要为了不存在的逻辑去设计一个复杂的系统，增加一些额外的代码。这些问题相对来讲比较高级，不是那么容易做到，需要一定的经验的积累，但是你只要去做，就一定能比之前做得更好。
最后提到和可测试性的关系，很多开发不写单元测试，这是一个不争的事实，其实不是因为写单元测试是一件很困难的事情，很多时候是因为我们的设计得很差导致的，比如到处都是全局变量，依赖关系很复杂，为了写一个简单的测试，需要构造很多复杂的对象，自然写测试就会很复杂，如果在开发阶段就考虑这种可测试性，往往会迫使你去考虑更多的测试相关的问题，而反过来又能优化你的设计。
最后，引用本书中引用的爱因斯坦的话结尾吧，“如果你不能把一件事情解释给你祖母听的话说明你还没有真正理解它”，最好的代码可能能让小学生都能读懂吧！