后端好书阅读与推荐（续二）

后端好书阅读与推荐系列文章：
后端好书阅读与推荐
后端好书阅读与推荐（续）
后端好书阅读与推荐（续二）

几个月又过去了，又读了几本书，同时为了深切体会到某些书里面的要点还专门做了一个小项目，这里就把读书与小项目过程中的一些心得体会记录一下。

Effective Java

Effective java 中文版（第2版） (豆瓣) https://book.douban.com/subject/3360807/

本书是Java领域的经典之作，作者提出了几十个经验法则，能够优雅健壮的解决我们日常编程可能会遇到的大部分的问题。

本书亮点遍地是，挑一些代表性的：

• 学好一门自然语言有三件事：语法、词汇、习惯和高效的用法；学好一门编程语言也类似的，我们要了解语言的核心，掌握常见的数据结构与API，同时为了效率要掌握一些最佳实践。
• 静态工厂方法一般来说可以比构造器更好的控制对象的生成，比如生成特定子类类型（根据名称判别）、生成时机、数量（单例、缓存）等，但是要注意规范命名，以便于使用者不必去猜静态方法的用处（因为静态工厂方法并不如构造器那么特别）。
• 用对象池来避免创建对象需要对象池里面的对象是重量级的才行（如创建代价较大），因为维护轻量级对象池的代价甚至大于即时创建的代价。
• 自己在管理内存的时候尤其容易发生内存泄漏，所以要确保不仅你知道这个变量不被引用了，还要让JVM知道；另外，还可以好好利用软引用和弱引用来保证内存不足时变量可以被回收的问题。
• 不要使用 public 域，而应该使用 private 域加 public 和 getter 这样就保留了将来灵活修改内部数据表示的能力，如果直接用 public 域，那么将来要修改内部表示，那么调用者也必须修改其调用方式，这显然不利于重构维护的。
• List 优先于 Array 因为泛型是不可变的，而数组是协变的。而且数组是具体化的，只有在运行期才会检查元素类型约束，但是因为泛型擦除，所以在编译期就检查元素类型，这样就能提前发现错误。
• 参数有效性检查，对于public方法，应该检查并throw 异常，对于未被导出的方法，检查时应该用assert，既能起到检查效果，又能减少开销；对于类的可变组件还要选择性的进行保护性拷贝，避免破坏类本身
• override 方法的选择是在运行时动态决定的，总是选择最具体的方法；overload 方法选择是在编译时静态进行的，完全基于编译时类型
• 对于集合或者数组这些 容器 类，宁愿返回一个长度为0的容器而不要返回null，避免客户端忘了检查而抛出空指针异常，如果担心性能问题可以把这个长度为0的容器声明为静态常量（因为它是空的，所以可以自由共享），避免每次新建容器带来的性能消耗（其实很小）。这个在应用中很常见，比如web中展示列表之类的，如果在Service中返回null，那么Controller中还要检查，不然前端渲染时foreach列表时就会报空指针异常，但是返回一个长度为0的容器，就可以避免检查，空与不空统一处理了
• 精确的计算尤其是货币不要使用float或者double，因为要让一个浮点数精确的表示0.1（或者10的任何负数次方，另外，任何进制都有不能表示的数）是不可能的，而因该使用BigDicimal(数量大，精确控制小数点)、long或者int（性能较好）。题外话，如果让用户损失了钱，即使是一分钱，都会让你的应用失去用户的信任，所以该精确的地方一定要足够精确
• 一般都要通过接口来引用对象而不是类，如 List<String> l = new Vector<>(); 不要用 Vector<String> l = new Vector<>();，因为这样就可以在想换实现的时候修改一行代码就行了 List<String> l = new ArrayList<>(); 代码中的其他部分并不会收到影响。为什么要换实现呢？可能新的实现提供了更好的性能，更多的功能等等
• 多线程中，Thread既可以充当工作单元，又可以充当执行机制，但是最好要把这两者分开，用Runable和Callabe作为工作单元（task），用executor 封装的thread来作为执行机制（不要直接使用thread），这样职责划分代码更清晰

读完这本书，结合前面的设计模式、代码整洁之道、重构几本书，我感觉可以总结一点：每一个段特定的代码（类、函数）其实都是分为作者和调用者，代码之所以写的烂，是因为好多时候我们自己一个人同时充当了作者和调用者，所以忽略了我们作为作者应该怎样写代码才更有利于别的调用者调用，达到可复用、低耦合、易重构的效果，所以我们在写一段代码的时候不要想当然的就把某个功能随意的放在某段代码实现，而是要好好分割功能实现和调用，分清自己作为作者和调用者的界限，才能避免当局者迷。

本书也比较老了，08年的，所以很多问题都被Java7/8/9解决了，比如

• List<String> tempList = new ArrayList<>(); 泛型实例化类型的自动推断简化了代码
• interface 的 default 方法打破了接口不允许实现的规则，所以书中提到的抽象类比接口更易于演变的理由似乎不再成立
• Java 8 的方法引用可以很方便的实现策略模式，而不需要再书中提到的（但是思想依然相同）宿主类、匿名类

但是这些并不影响我们阅读，我们只需要看书的时候结合Java的最新特性来看就行了，况且本书主要讲方法、经验，而不是语法，所以新与旧影响并不是特别大，不过实在受不了的话也有好消息，第三版好像2017.12就要出来了，引入了Java7/8/9的最新特性。这本书属于那种没事可以翻一翻的书，因为做得越多，对书中的经验体会就越深，就越能够应用自如。

MongoDB In Action

MongoDB实战 (豆瓣) https://book.douban.com/subject/19977785/

MongoDB 我是作为几乎的初学者来看这本书的，因为之前看了点基础知识就直接用在了项目里，边用边学，虽然快速，但是难免心里有郁结，因为没成体系。这里准备用这本书来系统的学习一下。
这本书内容相当丰富，从历史讲起，介绍了mongodb的基本概念，设计实例最后还讲了一些高级用法如复制与分片，性能调优等，既有开发者视角，也有DBA视角，读完收获颇丰。

亮点：

• MongoDB相对于关系数据库的优点有：可存储无Schema数据，读写吞吐量高（键值存储简单），扩展方便（自动分片，主从复制，主节点若发生故障从节点自动转为主节点），数据模型直观（一般不需要join连表查询）；相对于其它NoSQL如redis的优点有支持即时查询（redis只支持主键查询）。这也是为啥MongoDB能在关系数据库已经如此成熟的今天还能打下自己一片天地的原因
• MongoDB应用场景：WEB应用如日志和实时分析（原子更新和固定集合，提供稳定的计数器和日志自动过期的功能），敏捷开发（因为无模式），缓存（完整的对象表示和简单的键值存储通常能获得比MySQL更高的查询速度）
• shell可以很容易的查看任意方法的实现，只要输入不带括号的方法就行（这是js的特性）比如db.user.save就可以看出save其实就是对insert和update一个简单的封装，根据主键是否存在进行操作选择。
• 所有的MongoDB驱动都主要有三个功能：检查对象ID若无则生成（id可保证唯一，由4字节时间戳，3字节机器ID，2字节进程ID，3字节进程局部计数器组成，所以MongoDB一般不需要一个单独的字段来记录存储时间了），把语言特定的文档描述转换为BSON，使用MongoDB的网络协议通过TCP套接字与数据库通讯（安全模式决定了通讯是否可靠）
• 选择嵌套还是引用（正规化与否）的关键是判断读写比，选择嵌套优点是查询只需要一次就可以查完，简单快速，但是如果要修改就需要在每个出现嵌套信息的地方进行修改，但是如果确定修改的频率较低，或者嵌套对象不出现在父对象以外的其他上下文，那么嵌套就足以成为合理的设计。此外，如果信息量很大那么不适合用嵌套，应该用引用，可以避免或者推迟分片的到来。比如博客应用中文章的评论就非常适合嵌套
• 更新有两种方式，一种是通用性更新：从数据库获得完整对象，然后修改这个对象，然后保存，另一种是针对性更新:直接按条件修改数据库中一些对象的某些字段。前者的好处在于通用，可以将前台传来的表单无论修改了那个字段都可以直接保存，无需更多拼凑，修改任何字段的方法都是相同的，便于统一处理，后者的好处在于性能更好，因为节省了许多不必要字段的传递，而且允许原子性更新，比如inc
• 稀疏索引用于：不是所有文档都要用unique索引，这样可以避免某一类型数据（比如缺了一个字段）无法多次插入；集合中大量文档都不包含被索引的键，用稀疏索引可以节约内存
• 复制可以提供：冗余能够达到容灾或者挽救误删数据的效果；故障迁移可以在紧急情况下切换节点；简化维护工作，比如可以在主节点以外进行大开销操作如备份或者大数据的索引构建；均衡负载，读写分离
• 分片可以解决某一类型数据过大，不能单机存储的问题，同时能保持高性能读写。MongoDB自动分片策略应该可以替换大多我们自己手动分片的做法
• 书中还提出了许多最佳实践，比如常见的设计范式一对多、多对多、树形结构，这些都对我们在设计应用时有较大的参考价值

看这本书有点不爽的一点就是用ruby写的，这一门语言我没怎么接触过，但是却因为老板让我部署redmine而留下了痛苦回忆，真的是我用过的框架里面部署最麻烦的，所以一直也没有兴趣去了解这门语言，但是还好大部分语言的语法都是相似的，并不是很影响我看这本书。
另外还有一点就是 MongoDB 版本3和2差别较大，最明显的就是验证方式，需要及时更新。

Pro Git (Second Edition)

Pro Git (Second Edition) (豆瓣) https://book.douban.com/subject/26208470/

Git也用过挺久了，但是每次遇上问题都是直接搜索，这样解决问题是快，但是同样不成体系，所以用这本书站在使用者的角度进行学习，时间有限，后面还有关于原理的部分我就省略没看了。

亮点：

• 版本控制系统（VCS）可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等
• 集中化的版本控制利于项目共享，权限管理，但是受中央服务器的单点故障影响特别明显，而分布式版本控制系统每一个用户都有一个完整的仓库，对单点故障免疫，还可以根据需要设定不同的协作流程，比如层次模型式的工作流
• Git支持离线操作，保证文件完整性，一般只添加数据所以不容易误删（但是也使得彻底清除文件比较费劲，比如误上传了密码文件）
• Git 有三种状态，你的文件可能处于其中之一：已提交（committed）、已修改（modified）和已暂存（staged）。已提交表示数据已经安全的保存在本地数据库中。已修改表示修改了文件，但还没保存到数据库中。已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中
• git add 是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。将这个命令理解为“添加内容到下一次提交中”而不是“将一个文件添加到项目中”要更加合适
• 对一个线上项目要添加新功能时应该新建一个新功能分支，如果线上项目出了问题，应切回线上分支，然后创建一个紧急分支来修复，测试结束过后切回线上分支，合并这个紧急分支，然后推送到线上分支，最后切回新功能分支，做完后测试，在切回线上分支，合并新功能分支，推送到线上分支。这是项目开发的最佳工作流实践
• 与他人合作的最佳方法即是建立一个你与合作者们都有权利访问，且可从那里推送和拉取资料的共用仓库，仓库最好放到服务器上方；Git服务器可以自己搭建，还可以自己搭一个对应的网页查看器如GitWeb，也可以使用开源的功能全面的Git服务器比如GitLab，最简单的做法是使用第三方托管如Github
• 集中式工作流类似于subversion：一个中心仓库，可以接受代码，所有人将自己的工作与之同步，模式简单，应用广泛；集成管理者工作流：每个开发者拥有自己仓库的写权限和其他所有人仓库的读权限。这种情形下通常会有个代表`‘官方’'项目的权威的仓库。要为这个项目做贡献，你需要从该项目克隆出一个自己的公开仓库，然后将自己的修改推送上去。接着你可以请求官方仓库的维护者拉取更新合并到主项目，维护者可以将你的仓库作为远程仓库添加进来。主要优点是一方都可以按照自己节奏工作，适时的合并；司令官与副官工作流：是多仓库工作流程的变种。一般拥有数百位协作开发者的超大型项目才会用到这样的工作方式，例如著名的 Linux 内核项目。被称为副官的各个集成管理者分别负责集成项目中的特定部分。所有这些副官头上还有一位称为司令官的总集成管理者负责统筹。司令官维护的仓库作为参考仓库，为所有协作者提供他们需要拉取的项目代码，只有当项目极为庞杂，或者需要多级别管理时，才会体现出优势

这本书作为工具没啥好挑剔的，它讲的全面、细致，看完再练练，把git常见功能弄熟悉就好，繁杂琐碎的功能可以先不看，遇上问题了再来查阅。
ps:github上有对应的中文版。

Spring In Action

Spring实战（第4版） (豆瓣) https://book.douban.com/subject/26767354/

这本书可谓是涵盖了Spring整个体系的概要书，从spring mvc 到 spring security 再到 spring boot，几乎涵盖了我们平常开发能用到的所有组件，读完就可以从整体上把握spring，但是其中的每一个主题都可以单独成书，值得好好研究，这本书就相当于是开个好头吧。

亮点：

• Spring框架是以简化Java EE应用程序的开发为目标而创建的，主要使用pojo替换重量级的ejb，目前已经成为Java web事实上的标准
• Spring可以做很多事情，为企业级开发提供给了丰富的功能，这些功能的底层都依赖于它的两个核心特性，依赖注入（dependency injection，DI）和面向切面编程（aspect-oriented programming，AOP）
• 为了达到Spring最根本的使命：简化Java开发，Spring采取了以下4种关键策略：基于POJO的轻量级和最小侵入性编程；通过依赖注入和面向接口实现松耦合；基于切面和惯例进行声明式编程；通过切面和模板减少样板式代码。
• 通过DI，对象的依赖关系将由系统中负责协调各对象的第三方组件在创建对象的时候进行设定。对象无需自行创建或管理它们的依赖关系，依赖关系将被自动注入到需要它们的对象当中去；借助AOP，可以使用各种功能层（日志，审计，安全等）去包裹核心业务层。这些层以声明的方式灵活地应用到系统中，你的核心应用甚至根本不知道它们的存在
• Spring的配置风格是可以互相搭配的，所以你可以选择使用XML装配一些bean，使用Spring基于Java的配置（JavaConfig）来装配另一些bean，而将剩余的bean让Spring去自动发现。建议是尽可能地使用自动配置的机制， 显式配置越少越好。当你必须要显式配置bean的时候（比如，有些源码不是由你来维护的，而当你需要为这些代码配置bean的时候），推荐使用类型安全并且比XML更加强大、类型安全并且对重构友好的JavaConfig。最后，只有当你想要使用便利的XML命名空间，并且在JavaConfig中没有同样的实现时，才应该使用XML
• 大多数的JSP模板都是采用HTML的形式，但是又掺杂上了各种JSP标签库的标签，使其变得很混乱。这些标签库能够以很便利的方式为JSP带来动态渲染的强大功能，但是它也摧毁了我们想维持一个格式良好的文档的可能性；Thymeleaf模板是原生的，不依赖于标签库，它通过自定义的命名空间，为标准的HTML标签集合添加Thymeleaf属性。它能在接受原始HTML的地方进行编辑和渲染。因为它没有与Servlet规范耦合，因此Thymeleaf模板能够进入JSP所无法涉足的领域
• ControllerAdvice最为实用的一个场景就是将所有的@ExceptionHandler方法收集到一个类中，这样所有控制器的异常就能在一个地方进行一致的处理。 例如， 我们想将DuplicateSpittleException的处理方法用到整个应用程序的所有控制器上
• Spring Security从两个角度来解决安全性问题。它使用Servlet规范中的Filter保护Web请求并限制URL级别的访问。Spring Security还能够使用Spring AOP保护方法调用——借助于对象代理和使用通知，能够确保只有具备适当权限的用户才能访问安全保护的方法
• 对于Spring data，简单的查询直接在自定义的repository接口中继承JpaRepository，然后用findByUsername这种命名风格的方法就行，如果所需的数据无法通过方法名称进行恰当地描述，那么可以使用@Query注解，为Spring Data提供要执行的查询，更复杂一点的可以继承自定义的类（并非真的继承，而是命名加上Impl后缀，Spring Data自己会合并所有的方法），然后自定义查询方法
• Java消息服务（Java Message Service ，JMS）是一个Java标准，定义了使用消息代理的通用API。在JMS出现之前，每个消息代理都有私有的API，这就使得不同代理之间的消息代码很难通用。但是借助JMS，所有遵从规范的实现都使用通用的接口，这就类似于JDBC为数据库操作提供了通用的接口一样。Spring对JMS的支持，包括JmsTemplate（同步）和消息驱动POJO（异步）
• Spring带来的主要益处就是简化Java开发，Spring Boot让这项任务变得更加简单。从Spring创建以来，Spring Boot大概是Spring领域中最令人兴奋的事情了。它在Spring之上，构建了全新的开发模型，移除了开发Spring应用中很多单调乏味的内容

这是一本“XX大全”类的书籍，下一本书也是，这种书最适合刚进入一个领域的时候看，因为能提供很多参考，利于我们进阶的学习。

深入分析Java Web技术内幕

深入分析Java Web技术内幕 (豆瓣) https://book.douban.com/subject/25953851/

本书作者的理想很丰满，想一次性得把Java web 全部搞定，从基本的http，dns协议，到底层的编译原理、jvm与类加载技术，到中层的servlet，到上层的框架spring，几乎能用到的知识点都讲到了，但是由于这个面实在太广，很难真正的深入讲解，但是本书对于了解整个Java web的体系还是非常有好处的，这也是作者多年工作的积累和经验，非常值得了解和学习。

亮点：

• 从用户输入含域名的URL到浏览器呈现结果会发生如下几件事：域名解析成IP，首先浏览器检查缓存，若无则检查操作系统dns缓存，若无则检查本地dns服务器LDNS，若无则检查根域名服务器，最终得到IP,找到对应服务器；服务器根据请求相应结果，可能有多台（群）服务器进行负载均衡，最终给用户指定一个特定的服务器，服务器会检查缓存，有的请求是缓存在分布式缓存里，有的是静态文件缓存，有的还需要去数据库取数据；浏览器得到结果后可能还会发现有静态文件比如css,js,image等，如果浏览器没有缓存则又会发起另外的http请求这些资源，可能在cdn上，可能直接在服务器上，最终得到结果渲染页面并缓存起来，为下一次渲染加速
• 文件访问一般涉及到数据从磁盘到内核空间，内核空间到用户空间（内核空间可能会使用缓存机制）；直接IO是指应用程序跳过内核直接访问磁盘，比如数据库，通常可以结合应用层缓存和异步IO方式提高效率；内存映射是指操作系统将内存中的一段区域与磁盘中的文件关联起来，可以减少从内核缓存到用户空间缓存的数据复制操作，因为这两个空间的数据是共享的
• 网络IO优化方式：减少网络交互次数，比如客户端和服务端都设置缓存，将多个js或css合并一次发送，多个sql语句合并起来一次发送给数据库；减少网络数据传输量，比如数据压缩，协议简单化；减少编码，尽量以字节形式发送，减少从字符到字节的过程
• 大型网站一般不采用单独的cookie或者session，而是采用分布式session框架，客户端只需简单的发送sessionid即可，服务端的session是分布式存储的，与真正的应用服务器分开，避免均衡负载session不一致情况的发生；同时，每个请求携带一个唯一的crsf_token存入session，既能防止跨站攻击，也能防止表单重复提交

这本书还有个优点就是遍布全书的设计模式讲解与实例分析，不得不说作者知识面很丰富，估计如果能把这本书提到的点都精通了就是真正的“架构师”了吧。

Linux命令行大全

Linux命令行大全 (豆瓣) https://book.douban.com/subject/22226727/

做后端的肯定要和Linux打交道，比如程序日志好几百兆，怎么快速找到需要的分析内容？访问突然变得缓慢，怎么检查是带宽问题还是内存问题还是CPU问题？这些常用操作及其对应命令都可以在这本书里面找到答案，对于Linux系统的日常使用和管理，提升工作效率起到很大的帮助作用。

亮点：

• Windows中每个存储设备都有一个独立的文件系统树（C盘，D盘），而Linux中只有一个文件系统树，不同的设备只能选择性的挂载到这个树中的某个位置
• 虽然使用图形界面可以很轻松的实现简单文件操作，但是对于复杂操作命令行的优势就太明显了，比如根据文件夹中特定类型的文件是否存在及其更新日期来决定是否把文件复制到该文件夹中，这个用图形界面你就只能一个一个的手工选择然后对比，但是命令行就一句 cp -u *.file destination 轻松搞定“insert or update when newer”的功能
• 当rm与通配符搭配使用时，通常结果影响较大，应该先用ls对通配符进行测试，检查是否真是需要删除的文件，确认后再按↑ 并用rm替换ls
• 硬链接是最初的链接方式，局限性在于不能引用自身文件系统以外的文件，而且无法引用目录，它与文件本身没区别，删除它也不会删除文件，除非该文件的所有链接都删除完了；现在提倡使用软链接（符号链接），它克服了硬链接两大不足，与指向的文件几乎没区别，可以进行修改，但是删除软链接对指向文件没影响
• kill命令并不是杀死进程，而是给进程发送信号，不过通常都是杀死进程的信号，但是也有继续运行、窗口改变等“非杀死”的信号
• 通过rsync命令同步本地与远程系统上的目录，该命令能检测两个目录之间的不同，以最少量的复制动作完成两个目录之间的同步，与其他复制命令相比，显得既快又经济

这本书没啥问题，就是相当的基础，微观，偏重于细节和使用，可以放桌上随时查阅，想要稍微深一点或者更宏观审查Linux的可以看这

软件测试经验与教训

软件测试经验与教训 (豆瓣) https://book.douban.com/subject/1139061/

即使不是专业的软件测试人员，开发者也应该学习一些软件测试，毕竟写完代码你自己总得保证基本能运行吧，最开始可能可以手动运行，但是心里能有底吗？还是得写好单元测试，才能更有底气的把代码交给别人运行，所以看看这本书来了解一下软件测试中的一些好的经验。

亮点：

• 软件测试的“语境驱动法”，在某些环境中很有效的方法在另一些环境就没有效果，所以不谈论最佳实践，而是谈论最适合当前特定环境的实践
• 测试的任务是找到最重要的问题，所以要首先测试刚刚经过变更的部分，核心功能，功能完整性，常见使用情况，常见威胁，影响较大的问题，最需要的部分
• 为了测试就必须探索，亦即有目的地漫游，需要三种思索方式，前向思索：根据已知探索未知；后向思索：从怀疑或者想象的东西返回到已知；侧向思索：让自己的工作由于新想法而转移，然后再将探索主题回到主线上
• 由于测试用例是无限的，在时间和预算的约束条件下应该选取少量最有效的测试，一些好的试探法测试包括：边界测试；测试所有错误消息；测试与程序员不同的配置；运行比较难设置的测试；避免冗余测试；
• 任何产品都会残留一些小缺陷，但是随着小缺陷数量的增加，客户信心会下降，更糟糕的是这些小缺陷的腐蚀作用，长久积累下来最终会导致产品失败，所以小缺陷也值得报告和修改
• 自动化测试有很多优点比如加快测试速度，性能测试（1000个客户链接不可能找1000个人去测）等等，但是手工测试也有自己的优点比如临时变更测试，虚警过滤等等，所以这两者不能互相替换，而是相互补充
• 脚本语言是用来加快人的工作完成速度而非提升机器性能的，所以对于许多自动化测试来说，脚本语言都是最合适的，测试员可以用脚本语言快速生成测试用例、访问编程接口以及检验结果

这本书类似于程序员修炼之道，都是作者的经验之谈，我本人由于测试经验相对较少，所以还需要在以后的工作中慢慢体会，并且时常翻看才可能做到融会贯通。
ps,要想学习软件测试的基本理论知识还得看这本书：软件测试的艺术。

软技能：代码之外的生存指南

软技能 (豆瓣) https://book.douban.com/subject/26835090/

软件开发者首先是作为一个人，其次才是软件开发，这本书不教我们怎么写代码，而是教我们关注生活中的其他方方面面，针对职场人士，尤其是软件开发者，提出了一系列可以让人更接近成功，过得快乐的tips，包括很多方面比如学习，自我营销，理财，人际关系还有健康。

亮点：

• 当说到“优秀的软件开发人员”时，并不是说要精于编码之道，善于解决缺陷，通晓单元测试。相反，所说的“优秀的软件开发人员”，是那些能够把控自己的职业生涯、达成目标、享受生活的人。的确，职业和生活能融洽的人才能称得上“成功人士”，光有任何一样都不完美
• 你所能犯的最大错误就是相信自己是在为别人工作。这样一来你对工作的安全感已然尽失。职业发展的驱动力一定是来自个体本身。记住：工作是属于公司的，而职业生涯却是属于你自己的。当你为了谋生一头扎进写代码的世界时，其实你和中世纪小镇上开铁匠铺的铁匠没什么差别，转变你的心态，从被一纸“卖身契”束缚住的仆人转变为一名拥有自己生意的商人。在起步阶段就具备这种心态会改变你对职业生涯的思维方式，将此铭记在心，并积极主动地管理自己的职业生涯
• 尽管我们为自己的智慧感到骄傲，但我们依然是情感动物。我们就像那些穿着西装、打着领带、四处游荡的小孩，假装自己已经长大，其实任何轻微的伤害都能让我们号啕大哭，或者大发雷霆，我们只是已经学会了如何控制和隐藏这些情绪。所以啊，不要觉得有理走遍天下，有时候得理也要饶人
• 你可能会害怕专攻软件开发的某一领域，担心自己陷入很窄的专业领域，从而与其他的工作和机会绝缘。虽然专业化确实会把你关在一些机会的大门之外，但与此同时它将打开的机会大门要比你用其他方式打开的多得多。从表面上看，身为“专才”后，潜在雇主和客户群都变小了，但是实际上你对他们更具吸引力了。只要你专业能力雄厚，市场没有过渡饱和，与那些自称为“软件开发人员”的人相比，你能更轻松地找到工作或者赢得客户。不完全同意作者的观点，T字型人才是我自己的奋斗目标
• 你当然可以改善你的弱点，但最好了解自身的强项是什么并且充分发挥自己的优势。专业人士对自己的能力和弱点有着良好、精准而又客观的自我评估。与作者共鸣，我觉得木桶理论不是很靠谱，因为许多人成功并不是依靠自己是全才，而是把自己的长处发挥的淋漓尽致
• “假装自己能成功”就是这样起作用的。你说服自己的身体和内心去努力，使梦想成为现实。“假装自己能成功”是不自信的对立面。你要在做任何事情的时候都充满自信，即使是在自己的能力远远不到的时候，因为你有一种自己能够克服一切障碍的信念
• 对技术虔诚的一大问题是，我们中的大多数崇拜某项特定的技术，只是因为自己熟悉这种技术。我们很自然地会相信自己选择的是最好的，然而这会让我们经常忽略任何反对意见。我们不可能充分了解现存的所有技术，从而给“哪项技术最好”作出最英明、最睿智的判断，于是我们倾向于选择我们了解的技术并先入为主地认为它是最好的。所以我的策略是多了解，选合适的工具来解决问题
• 如果你想成功，你必须要学会收起自己脆弱的自尊心，勇敢走出去，别害怕让自己出丑，别在意自己站在大庭广众之下可能会哑口无言，别在意别人看了你的博客后觉得你完全错了并且很蠢，别在意别人会嘲笑你，别太在意别人怎么看自己，拼尽全力去克服这些困难，克服掉那些不适感，让自己变得更加优秀
• 如果想提前掌握所有知识，那只是在浪费时间，因为真正重要的内容会湮没在那些细枝末节中。要关注重点，确实需要了解更多细节时，可以利用参考资料来弥补这些不足。有多少次你从头到尾仔细阅读一本技术书籍，却发现自己实际用到的也只是书里介绍的技术的一小部分。感觉找到知音了，如果你看过我前面几篇文章，你也应该知道我就是这么做的，有好多书其实我并没有读完，诸葛亮的观其大略啊，哈哈 :-D
• 将自己学到的知识教给别人。要想确定你确实掌握了某些知识，这是唯一的办法； 同时，在你将自己所学介绍给他人时，这也是查缺补漏的好办法。在这一过程中，你要切实剖析并理解自己所学的知识，将其内化到自己的思想；同时，你也要用能够让他人理解的方式精心组织这些信息。 以我个人的经验来说，在我开始“乐为人师”之后，我不仅在职业发展和专业成长上有了巨大飞跃，我的理解能力也更上一层楼。总体来说就是，要想给别人讲清楚，首先自己得搞明白，所以不仅是“乐为人师”，写博客也有这个好处。
• 要进入专注模式，必须要克服将自己的思绪集中于单一任务时的那种痛感。除非你完全享受完成这项任务，否则这种痛感一开始会很强烈。但是， 这正是关键所在。你必须要意识到，这种痛苦和不适只是暂时的，不会持续很久。强迫自己进入专注模式，达到专注的临界点。在我看来，自然世界中不管是物理还是人的心理、思维，都存在惯性，所以我们要专注，就得首先强迫自己进入专注，过不久，就自然专注了，这个和习惯养成是一个道理，比如早起，最开始可能是一种痛苦，但但到了后来也就是一件很自然的事
• 最好不要多任务并行，因为这会打破专注，降低效率，但是现实不允许你单任务，你可以这样：批处理琐碎任务，比如不要来一封邮件就处理，这样常常打断你的工作，专注不够，但是等一段时间一次性处理邮件，就好得多；将不费脑的任务和费脑的任务并行，比如跑步的时候可以听一些书进行学习

这本书的亮点太多了，难以列全，我读完过后有种找到知音的感觉，而且通过书中的介绍我找到了我一直想有但却没找到的应用kanbanflow，是一款用于任务管理与计时的非常棒的应用。所以我在这里强烈推荐大家看一下，然后结合自己的实际情况，把这些点运用起来，助力自己成为一个更好的“人”。

后记

不知不觉，已经读了20多本书了，我发现这个习惯非常利于我看书和消化，我准备把这个系列继续下去，将来就不只是后端书籍了，方方面面的书我都可能看，也会写，写到80岁，哈哈。