最近在网上看了一个非常好的帖子《程序员一生必读的书》（我的腾讯微博上有分享该贴子链接，有兴趣就点击进去看看吧），该贴的第一个张图片是一个雷达图， 这张图是由ThoughtWorks（全球软件设计与定制领域的领袖级企业）的资深人士提供的，它将程序员要读的书分为四个类别，每个类别又分为初级、进阶和高级读物，并用黄色三角形点出了强烈推荐阅读的书籍。四个类别包括：
相信这张图会帮助到很多迷茫的职业人，因为好书就像明灯一样会照亮我们的方向，那些大师级的人物将他们的经验分享给我们，真的有如浴春风的感觉。有时候会很感慨国外有那么多厉害的技术作家写了那么多好的作品，而国产技术书籍中的好书真算得上是凤毛麟角。有时候也会问自己，能不能做一个技术作家呢，我想我的修炼还远远不够。 虽然不能够自己写一本好书，但是还是很愿意把自己的读书心得跟大家一起分享，雷达图上的书我读过的约有1/3，下面就把读这1/3的心得跟大家分享。
Code Complete 《代码大全》
Refactoring《重构：改善既有代码质量》
Clean Code 《代码整洁之道》
其实我应该先介绍下面那本书，喜欢下面那本书的原因是书中有很多非常精炼但是有用的Tip，这些Tip可以说是大师级的经验总结；而我个人喜欢这本书可能是因为非技术方面的原因（我喜欢这本书中的插图）。这本书的第一章的第一句话是这样说的：读这本书通常有两个原因：1. 你是一名程序员。2. 你想成为更好的程序员。我们需要更好的程序员。 这本书的每一章都可以总结出一句话或是一张图，就是下面这些：
本书的第一章是关于什么是整洁代码的讨论，引用了Bjarne Stroustrup（C++之父）、Grady Booch（UML的创始人之一）等人当然也Bob大叔（本书的作者Robert Martin）自己对整洁代码的理解。顺便说一下，，上面那张图上的代码应该是保龄球计分程序（你必须佩服我的眼力）。
不管是现实世界还是软件项目中，命名都是一件让人头疼的事情，给小孩起过名字的就知道，你希望把你对孩子的期望包含在这个名字中，你又希望这个名字读起来要好听，至少不至于将来成为别人的笑柄（比如庞光大、魏升京这样的名字），可能你还要考虑族谱的排辈等等。软件项目中的命名情况会更加复杂，简单的说命名的原则是“见名知意”，当然你还需要用各种方式防范命名冲突的问题，不同的编程语言也有自己不成文的像契约一样的命名规则和方式（例如匈牙利命名法），这些可能都是需要考虑的事情。
第三章讲的是函数，说了这么一句话：Function should do one thing. They should do it well. They should do it only. （函数只应该做一件事情，把一件事情做好，而且只由它来做这一件事情），听起来很简单的一句话但是要践行这条原则却并不容易，所以我们的代码中才会有很多的坏味道（上一本书中提到的东西）。事实上，上升一个层次，我们在设计类的时候也应该如此，这是面向对象设计原则中说的单一职责原则（SRP），当我们的代码中出现了冗长的方法或者巨大的类的时候，我们就应该依据职责来对其进行拆分，这样程序的结构才会趋于合理，最终达到“高内聚”的目标。当然，这一章里面还提到很多理念，包括：Command Query Separation（一个方法要么执行某种命令，要么返回查询数据）、DRY（不要重复自己）、Prefer Exceptions to Returning Error Codes（异常优于返回错误码）等。
第四章讲的是注释，有一句话我很喜欢，说的是：Comments Do Not Make Up for Bad Code （注释不是对劣质代码的补救）。事实上好的代码即便没有注释也拥有良好的可读性，但恰当的注释会让代码变得更可读、可维护性更高。
第五章讲的是代码风格。现代IDE（集成开发环境）几乎都有代码格式化代码的功能，你只需要设置好你使用的代码风格就可以了，其实不只是IDE，很多高级的文本编辑工具也能够按照指定的风格格式化你的代码。用什么样的代码风格不是关键，关键是整个项目组的成员应当使用相同的代码风格，让多个人编写的代码看起来像一个人书写的。我个人特别钟爱1TBS（One True Bracing Style，也叫做K&R风格，这种风格是Kernighan和Ritchie两位老师在The C Programming Language一书中使用的代码风格），当然Allman风格（FreeBSD系统的作者之一使用的代码风格）也是很好的选择。
第六章讨论的是对象和数据结构，读完之后的感觉是虽然我们天天都嚷着吼着要面向对象编程，但是很多时候我们都使用了类的退化结构，包括我们开发时经常使用的失血模型和贫血模型（事务脚本模式）都和面向对象的设计理念相违背。我得承认在读这一章的时候我没有太抓住作者的观点，也欢迎大家来帮助我理解这章的内容。
第七章对错误处理（异常）的讲解仍然是非常精彩的，整洁的代码中对错误的处理应当是被分离的关注点（不要跟正常的业务逻辑混杂在一起），而面向对象中的异常机制就是一种在不打乱原有业务逻辑的前提下处理掉程序在运行时发生的不正常状况的手段。这章有两个观点我特别欣赏，一是Use Unchecked Exceptions（非受检异常允许你在适当的地方处理异常，而适当的地方就是异常影响代码执行逻辑的地方，不管做哪种类型的应用，都应该尽可能向用户隐藏异常的发生，除非发生了不可挽救的状况，这才是符合最小惊讶原则的设计）；二是Don’t Return Null（如果一个方法在出状况的时候返回null，那么调用者都要通过频繁的检查返回值来判定是否出错，一旦忘了这件事情就有可能出错，既然null是一种异常状况，那么用抛出异常的方式来代替null明显是更好的做法）。
第八章的内容对实际开发有重要的指导意义，因为我们的项目中不可避免的要使用第三方工具，因此我们需要将这些东西整洁的纳入到我们的系统中，这时就需要考虑系统边界的问题。有的时候我们会千辛万苦的发现系统中的一些bug是来源于第三方工具的，当然我们基本上没有时间去重头学习和研究第三方工具或者自己写代码来实现第三方工具的功能，但是我们至少应该先对第三方工具进行测试。我在以前的项目中，即使用Apache提供的那些著名的第三方工具，我的做法也是先写测试代码对这些工具的可用性和有效性进行证实，当然有的时候可能是过于谨慎了，但这种习惯和做法本身是好的行为。在这种场景下，适配器模式是非常好的设计，它不仅能将不兼容的接口改写成兼容的接口，还能够对通过对第三方工具重新封装来避免边界的变化对系统的影响。
第九章的内容是单元测试。Bob大叔是TDD（测试驱动开发）的倡导者，这一章讲的是如何编写整洁的测试，Bob大叔的答案是FIRST规则（Fast、Independent、Repeatable、Self-Validating、Timely）。
第十章介绍类的设计，最重要的还是SRP。
第十一章是关于系统设计的内容，开篇引用了微软首席技术官Ray Ozzie的一句话：Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test. （复杂要人命，它消磨开发者的生命，让产品难于规划、构建和测试）。这章对于希望了解面向切面编程的开发者是极好的，包括了对依赖注入、代理模式以及AOP的探讨。
第十二章探讨了系统的迭代式演进。
第十三章对并发编程的讨论非常经常，很多开发者都畏惧并发编程，也有的开发者迷信多线程可以解决所有的并发问题，如果你是这两类人之一，本章会教给你真正的并发编程。
第十四章是一个精彩的案例用来讲解对代码的持续改进，你可以自己好好阅读一次。 第十五章到第十七章说的都是重构，相当精彩。你在《重构》中了解过的代码的坏味道及其改进方案这里几乎都能见到它是如何应用的。 总之，这本书从引言到附录都无比精彩，赶紧去阅读吧。 The Pragmatic Programmer: From Journeyman to Master 《程序员修炼之道：从小工到专家》
都可以…孔子的,老子的. 孙子的…都可以
