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

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

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

Effective Java

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

本书是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/subje...

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/subje...

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/subje...

这本书可谓是涵盖了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/subje...

本书做者的理想很丰满，想一次性得把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/subje...

作后端的确定要和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/subje...

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

亮点：

• 软件测试的“语境驱动法”，在某些环境中颇有效的方法在另外一些环境就没有效果，因此不谈论最佳实践，而是谈论最适合当前特定环境的实践

• 测试的任务是找到最重要的问题，因此要首先测试刚刚通过变动的部分，核心功能，功能完整性，常见使用状况，常见威胁，影响较大的问题，最须要的部分

• 为了测试就必须探索，亦即有目的地漫游，须要三种思索方式，前向思索：根据已知探索未知；后向思索：从怀疑或者想象的东西返回到已知；侧向思索：让本身的工做因为新想法而转移，而后再将探索主题回到主线上

• 因为测试用例是无限的，在时间和预算的约束条件下应该选取少许最有效的测试，一些好的试探法测试包括：边界测试；测试全部错误消息；测试与程序员不一样的配置；运行比较难设置的测试；避免冗余测试；

• 任何产品都会残留一些小缺陷，可是随着小缺陷数量的增长，客户信心会降低，更糟糕的是这些小缺陷的腐蚀做用，长久积累下来最终会致使产品失败，因此小缺陷也值得报告和修改

• 自动化测试有不少优势好比加快测试速度，性能测试（1000个客户连接不可能找1000我的去测）等等，可是手工测试也有本身的优势好比临时变动测试，虚警过滤等等，因此这二者不能互相替换，而是相互补充

• 脚本语言是用来加快人的工做完成速度而非提高机器性能的，因此对于许多自动化测试来讲，脚本语言都是最合适的，测试员能够用脚本语言快速生成测试用例、访问编程接口以及检验结果

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

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

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

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

亮点：

• 当说到“优秀的软件开发人员”时，并非说要精于编码之道，善于解决缺陷，通晓单元测试。相反，所说的“优秀的软件开发人员”，是那些可以把控本身的职业生涯、达成目标、享受生活的人。的确，职业和生活能融洽的人才能称得上“成功人士”，光有任何同样都不完美

• 你所能犯的最大错误就是相信本身是在为别人工做。这样一来你对工做的安全感已然尽失。职业发展的驱动力必定是来自个体自己。记住：工做是属于公司的，而职业生涯倒是属于你本身的。当你为了谋生一头扎进写代码的世界时，其实你和中世纪小镇上开铁匠铺的铁匠没什么差异，转变你的心态，从被一纸“卖身契”束缚住的仆人转变为一名拥有本身生意的商人。在起步阶段就具有这种心态会改变你对职业生涯的思惟方式，将此铭记在心，并积极主动地管理本身的职业生涯

• 尽管咱们为本身的智慧感到骄傲，但咱们依然是情感动物。咱们就像那些穿着西装、打着领带、四处游荡的小孩，伪装本身已经长大，其实任何轻微的伤害都能让咱们号啕大哭，或者大发雷霆，咱们只是已经学会了如何控制和隐藏这些情绪。因此啊，不要以为有理走遍天下，有时候得理也要饶人

• 你可能会惧怕专攻软件开发的某一领域，担忧本身陷入很窄的专业领域，从而与其余的工做和机会绝缘。虽然专业化确实会把你关在一些机会的大门以外，但与此同时它将打开的机会大门要比你用其余方式打开的多得多。从表面上看，身为“专才”后，潜在雇主和客户群都变小了，可是实际上你对他们更具吸引力了。只要你专业能力雄厚，市场没有过渡饱和，与那些自称为“软件开发人员”的人相比，你能更轻松地找到工做或者赢得客户。不彻底赞成做者的观点，T字型人才是我本身的奋斗目标

• 你固然能够改善你的弱点，但最好了解自身的强项是什么而且充分发挥本身的优点。专业人士对本身的能力和弱点有着良好、精准而又客观的自我评估。与做者共鸣，我以为木桶理论不是很靠谱，由于许多人成功并非依靠本身是全才，而是把本身的长处发挥的淋漓尽致

• “伪装本身能成功”就是这样起做用的。你说服本身的身体和心里去努力，使梦想成为现实。“伪装本身能成功”是不自信的对立面。你要在作任何事情的时候都充满自信，即便是在本身的能力远远不到的时候，由于你有一种本身可以克服一切障碍的信念

• 对技术虔诚的一大问题是，咱们中的大多数崇拜某项特定的技术，只是由于本身熟悉这种技术。咱们很天然地会相信本身选择的是最好的，然而这会让咱们常常忽略任何反对意见。咱们不可能充分了解现存的全部技术，从而给“哪项技术最好”做出最英明、最睿智的判断，因而咱们倾向于选择咱们了解的技术并先入为主地认为它是最好的。因此个人策略是多了解，选合适的工具来解决问题

• 若是你想成功，你必需要学会收起本身脆弱的自尊心，勇敢走出去，别惧怕让本身出丑，别在乎本身站在大庭广众之下可能会哑口无言，别在乎别人看了你的博客后以为你彻底错了而且很蠢，别在乎别人会嘲笑你，别太在乎别人怎么看本身，拼尽全力去克服这些困难，克服掉那些不适感，让本身变得更加优秀

• 若是想提早掌握全部知识，那只是在浪费时间，由于真正重要的内容会湮没在那些细枝末节中。要关注重点，确实须要了解更多细节时，能够利用参考资料来弥补这些不足。有多少次你从头至尾仔细阅读一本技术书籍，却发现本身实际用到的也只是书里介绍的技术的一小部分。感受找到知音了，若是你看过我前面几篇文章，你也应该知道我就是这么作的，有好多书其实我并无读完，诸葛亮的观其大略啊，哈哈 :-D

• 将本身学到的知识教给别人。要想肯定你确实掌握了某些知识，这是惟一的办法； 同时，在你将本身所学介绍给他人时，这也是查缺补漏的好办法。在这一过程当中，你要切实剖析并理解本身所学的知识，将其内化到本身的思想；同时，你也要用可以让他人理解的方式精心组织这些信息。 以我我的的经验来讲，在我开始“乐为人师”以后，我不只在职业发展和专业成长上有了巨大飞跃，个人理解能力也更上一层楼。整体来讲就是，要想给别人讲清楚，首先本身得搞明白，因此不只是“乐为人师”，写博客也有这个好处。

• 要进入专一模式，必需要克服将本身的思绪集中于单一任务时的那种痛感。除非你彻底享受完成这项任务，不然这种痛感一开始会很强烈。可是， 这正是关键所在。你必需要意识到，这种痛苦和不适只是暂时的，不会持续好久。强迫本身进入专一模式，达到专一的临界点。在我看来，天然世界中无论是物理仍是人的心理、思惟，都存在惯性，因此咱们要专一，就得首先强迫本身进入专一，过不久，就天然专一了，这个和习惯养成是一个道理，好比早起，最开始多是一种痛苦，但但到了后来也就是一件很天然的事

• 最好不要多任务并行，由于这会打破专一，下降效率，可是现实不容许你单任务，你能够这样：批处理琐碎任务，好比不要来一封邮件就处理，这样经常打断你的工做，专一不够，可是等一段时间一次性处理邮件，就好得多；将不费脑的任务和费脑的任务并行，好比跑步的时候能够听一些书进行学习

这本书的亮点太多了，难以列全，我读完事后有种找到知音的感受，并且经过书中的介绍我找到了我一直想有但却没找到的应用kanbanflow，是一款用于任务管理与计时的很是棒的应用。因此我在这里强烈推荐你们看一下，而后结合本身的实际状况，把这些点运用起来，助力本身成为一个更好的“人”。

后记

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