《Web全栈工程师的自我修养》浓缩笔记（下）
1. 易于上手、难于精通
不同于某些“难于上手、难于精通”的职业，前端这一岗位就像暴雪公司的游戏设计一样：“易于上手、难于精通 ”。
前端技术的“易于上手”导致它在某些技术人员那里不受待见。他们认为HTML与CSS根本都不是程序语言，甚至认为JavaScript是一种功能不全的玩具型语言。所以直到我几年前毕业的时候，大学都没有前端相关的课程和专业。而市场对前端工程师的需求又很大，学校的输出跟市场的要求没有对接上，所以往往出现学生找不到工作，公司又招不到人的现状。
2. 框架 VS 库
一个库是一系列对象、方法等代码，您的应用程序可以把这个库 “链接 ”进来。这个库起到了重用代码的作用，为您省下了重写这部分代码的工作量。
而一个框架是一个软件系统中可重用的一部分。它可能包含子程序、库、胶水语言、图片等一些“资源”，这些资源一起组成了软件项目。框架不像库，可能包含多种语言，某些功能可能通过API的方式让主程序调用。所以框架是一个更加灵活和宽松的名词，在具体的情景中，它可能指一个库、多个库、脚本代码，或者多个可单独运行的子程序的集合。
在出现一些热门框架时，建议开发者先去了解框架的创建初衷，合理使用，而不是盲目收集。
七、向移动端转型1. 为什么向移动端转型
技术是服务于市场的，在市场发生变化的时候，如果开发者不能顺应变化，就有被淘汰的风险，毕竟很多开发者所服务的这个岗位诞生都不到十年，消亡可能也会在十年之内发生。对于目标是全栈工程师的人来说，技术能力更是多多益善。
2. 一定要是自己的产品的用户
风投在评估一个创业项目是否会成功的时候，有一个指标就是创始人是否是自己产品的目标用户。如果不是，那产品很有可能会失败。
在大公司，一些工程师士气低迷往往就是这个原因，成功来得很慢，失败也是。因为大家害怕失败，所以想把产品调整得完美无缺才发布。但是世界上成功的软件都不是完美的软件，而是在合适的时间发布的、刚刚够用的产品。如果它能活下来，在后面的版本中，它才有机会越来越好。
《精益创业 》中有一句话：“客户需求只有在实际使用中才能辨明，再多的前期调研也只能发现客户认为他们想要什么，而不是客户实际上想要什么。因此在不了解客户真实需求的情况下，只会多做多错。”
3. 有哪些方向
iOS原生App
iOS原生App开发的技能树相对比较新，需要学习Objective C这门语言，以及Xcode的一些操作方法——主要是sto ryboard，以及各种官方类库的使用方法。它带来的收益也很高，对于独立开发。AppStore仍然是地球上最好的软件市场，对于团队，在未来5年都不会缺少对iOS开发者的需求。
Android原生App
使用Java编程，如果有Java编程经验，Android原生App是最好的选择，因为用户量和用户比例都在稳定增长。
WindowPhone原生App
现在用户量还很少，除此之外也不知道如何评论… …
WebApp
技术是最简单的，传统前端开发的技能树可以无缝移植，包括 HTML5/CSS3/JavaScript等。应用场景包括浏览器中打开的WebApp、微信中的页面，或者混合模式App。WebApp的好处是天然无缝移植到所有支持Web标准的平台——甚至Kindle。
此外，对于中国开发者来说，微信公众号也是一个巨大的平台。之所以提到微信，是因为微信这个平台在中国的覆盖率几乎跟Android和iOS加在一起一样多，而且微信也有比较成熟的支付方式。
4. 混合模式App
混合模式App（Hybrid App）同时使用Web技术与原生程序语言开发，通过应用商店区分移动操作系统分发，需要用户安装使用。就像混合动力汽车使用汽油和电力两种动力一样，混合模式App使用两种技术制造。
混合模式App对于用户来说跟其他App一样，需要去苹果AppStore或者Android应用商店下载。所以App需要对应的操作系统平台的技术，比如Objective C或者Java制作整体框架。App启动后，它的全部界面或者部分界面中，使用网络视图（WebView）技术来实现。WebView能加载显示网页，可以将其视为一个浏览器，它一般使用WebKit渲染引擎加载显示网页。
混合模式App一些常用的优化方法如下：
- 把WebView的部分或者所有资源打包在App中
缺点：发布包体积会变大 - 把需要加载的资源设置好预先加载
缺点：第一次访问的时候可能因为没有预加载资源而导致等待的时间比较长 - 使用HTML5 Manifest技术实现资源缓存
- 不要把整个App的主要逻辑都是用WebView开实现
要结合原生技术和WebView各自的优缺点，根据不同的场景选择合适的技术。原生技术的优点在于能很好地操作 App存储数据；实现页面间切换、高性能动画、大量数据的界面（比如可以无限滚动的图片流）。WebView的优点在于开发快、技术简单；前端开发者能够利用已有的CSS3和JavaScript知识；页面能够从服务器端更新；能够分享到社交平台；在多个平台上共用等。 - 设计的更像一个App，而不是一个网页
5. 混合模式App开发框架
PhoneGap通过对各个平台底层功能进行封装和抽象，然后通过JavaScript暴露出一致的API，让开发者可以通过JavaScript编写跨平台的原生APP。
虽然看上去“一次编写、到处运行”的愿景很美，但是PhoneGap有这样几个缺点。
- PhoneGap的编程语言其实是JavaScript，这对于非前端工作者来说，学习起来和学习原生的Objective C或Java编程语言难度差不多，想精通JavaScript，相当不易。
- PhoneGap编译的App包大小比一般的会大很多。
- PhoneGap的目标是方便地创建跨平台应用，但是苹果和Google都发布了自己的人机交互指南。有些情况下，iOS程序和Android程序有着不同的交互原则。使用PhoneGap就意味着您的程序在UI和交互上，既不像原生iOS程序，又不像原生Android程序。
- 动画性能不佳。JavaScript终究无法和原生程序比运行效率，当制作一些动画效果，或者有大量数据的长页面的时候，就表现得很明显。
当然，PhoneGap的优势也很明显 。
八、持续集成1.版本控制
SVN
集中式代码管理的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。
在企业内部，使用SVN没有什么问题，服务器压力和内部带宽都能够承受所有员工一起操作SVN。但是在开源世界，这种架构方法就不行了，著名的开源软件的开发人数太多了，因此诞生了Git。
Git
Git是一个分布式版本控制软件，是天才工程师、Linux内核开发者Linus开发，目的是更好地管理Linux内核源码。其第一版于2005年发布，它与SVN最大的不同之处就是基于分布式的理念。
2. 版本控制最佳实践
鼓励频繁的提交
SVN践是频繁地提交，而不要等到代码没问题了再一次性提交。对于可能损坏主干原则的代码，不要直接提交到主干，而是创建一个分支，在分支中频繁提交。
确定分支流程
基本上所有的特性和较大的bug修复都应该使用分支来修改。
定义主干原则，并且坚守它
我们团队的主干原则是“主干对应的代码必须是可以发布并且不会产生bug的”，如果不能保证新增的或者修改的代码符合这一原则，就在分支提交代码。任何人破坏这一原则引起bug，就请大家吃饭。
不要把逻辑的修改和代码格式化操作混在一起
如果您做了一些代码格式化的操作，就单独提交这次修改。比如您去掉了代码中所有的空行，那就单独提交一个 commit，然后再做一些逻辑的修改，再提交。这样可以避免“天哪，所有的东西都不一样了”，出现问题之后更容易追溯。
不相干的代码分开提交
也就是说不要在一次提交里修复两个bug。
保持工作代码库的“干净”
如果您有文件不想也不需要提交，就加入到忽略列表（ignorelist） 。不需要提交的文件包括编译后文件、配置文件和第三方依赖等。这样的好处是，您每次打开SVN提交界面，如果没有修改过任何代码，就会看见一个空的列表 ，如果修改过代码，就显示修改过的代码。这能提醒您不要漏掉任何需要提交的文件。
3. 包管理
为什么需要包管理？
在我们日常工作编写的软件中，可能有绝大部分代码都不是我们自己输入的。我们“依赖”一些第三方的框架或者库。在Web前端开发中，我们依赖各种框架、库、静态资源等；在PHP开发中，我们依赖各种框架、库；在iOS App开发中，我们依赖各种库、模块、资源等。在复杂一点的依赖环境中，您所引入的第三方库也依赖其他的“第四方库” “第五方库”… …如何保证互相之间都不会出现冲突很重要。
如何让我们依赖的资源有条不紊地在一个地方进行管理和更新，而不用重复“搜索、下载、移动”这一系列繁琐的手工操作？这就要引入“包管理”。
Node.js
Node.js的包管理器npm应该是世界上最有名的包管理器。如果没有npm，Node不会有今天的普及度。npm收集了大量优秀的Node.js代码包，然后这些库吸引更多开发者进入Node.js开发的行列，反过来又促成了npm的繁荣，就像鸡生蛋，蛋生鸡一样。
npm如何引入依赖组件？
第一种是在自己项目的根目录里写一个package.json。这是一个json对象，在其中的dependencies或者devDependencies值列出所需要的模块和版本，然后用命令行切换到项目根目录，运行npminstall。通过这种方法，其他人在得到您的代码之后，仅需要一个package.json文件，就可以简单地使用npminstall命令来安装所需要的所有依赖。模块会全部下载到node_modules文件夹。
"dependencies": {
"gulp-util": "2.2.14",
"through2": "~0.4.1"
},因为node_modules文件夹里全都是第三方代码，实际上是脱离于自己项目的代码库的。所以应该在.gitignore或者 SVN的忽略文件列表里忽略掉node_modules整个文件夹，而且所有项目成员也不应该修改node_modules里的任何东西，否则在将来npm安装的时候可能会丢失您的修改。如果发现某个模块有修改的必要，要向原作者提出issue。或者推送请求。
4. 构建工具
首先需要良好的架构
- 有合适的分离粒度
- 最小知识原则
一个组件或者对象不应该知道其他组件或者对象的内部实现细节。在QQ空间中，我们的配色组件跟其他组件是完全分开的，二者没有依赖关系。一个组件或者对象不应该知道其他组件或者对象的内部实现细节。在QQ空间中，我们的配色组件跟其他组件是完全分开的，二者没有依赖关系。 - DRY（不要重复您自己）
特殊的功能只能在一个组件中实现，在其他的组件中不应该有副本。这是我们的一个严格要求。 - 最小化预先设计，只设计必须的内容
- 通过良好的层级，让文件易于找到
- 在代码层面，有一致且可执行的命名规则
从路径名到文件名都有一致的前缀、后缀、版本规则。整个团队有一致的命名风格和注释风格。
Make和依赖关系
Make是一个经典的构建工具，现代很多构建工具（比如Grunt、Gulp等）都参考了它的一些基本原则来设计。 Make的基本模型是：定义一个任务时首先声明依赖关系，然后说明根据这些依赖调用哪些应用程序来生成目标文件。因为每一步都需要使用不同的应用程序调用不同的数据，所以这里面需要设置依赖关系。
另一方面，使用包管理工具可以把项目需要用的第三方包，以及每一个包的特定版本，都集中在一个配置文件中。此后，我们通过一句命令，就可以下载这些包到本地的开发环境。每个软件包都会涉及其他的软件包，软件包里程序的运行需要有一个可执行的环境（要求有其他的程序、库等），软件包依赖关系正是用来描述这种关系的。
所以， “依赖关系”既属于“包管理”，同时又属于“构建工具”。
Grunt和Gulp
Make很强大，而且在全世界范围内几乎所有的计算机领域用了几十年，它的稳定可靠经过了广泛验证。不过从学习成本角度来说，它需要学习者具备一些Linux编程的基础，难度较高。所以，Grunt和 Gulp诞生了，它们都是用 JavaScript来实现的构建工具。
Grunt引爆了前端架构工具的概念，得到了广泛的应用。现在，Grunt的生态环境已经非常庞大，越来越多的开发者着手Grunt开发，为它添砖加瓦。但是Grunt有几个问题 。
- 配置项过多。每一个插件的使用都需要配置输入项和输出项，使用比较繁琐。
- 子任务间的协作基于文件。基于文件的坏处是，后一个子任务必须等前一个子任务的过程完全结束，才能开始它的流程，这样比较慢。而且磁盘读写速度远远慢于内存读写。
所以虽然Grunt有先发优势，但是由于它有几个痛点没有很好地解决，所以又诞生了Gulp。
Gulp的意思是 “大口吸” ，它最初的logo是一杯饮料，上面有一根吸管，很形象地跟它的宣传语相呼应：“基于流的构建工具” 。与Grunt最大的不同就在于，Gulp基于 “流 ”的理念。
Gulp基于Node.js的流的概念，所以前一个任务的输出就是后一个任务的输入。
从语法风格上来讲，编写任务的过程更像是 “编程 ”，而不是 “编写配置” 。Gulp通过对接前一个任务的输入和后一个任务，就像一个管道，二者可以同时进行，不输出在磁盘中，没有多余的中间产物，性能更加高效。
当前，Gulp的社区还远不如Grunt成熟，有些功能的插件，Gulp可能就没有。不过从个人偏好来看，我更倾向于Gulp，它的技术理念更好。
九、理解编程语言1. 全栈工程师最佳实践
通用用途语言 VS 特定领域语言
很多编程语言倾向于通用解决方案，而不是只解决具体问题。这些语言都被设计为可以在任何领域使用，比如C、Java、Python和XML，它们被称为 “通用语言 ”（General Purpose Language， GPL）。我们可以看到用 C编写的所有类型的软件，从游戏到客户端软件，从服务器端软件到手机端软件。
与之相对应的，有些编程语言被设计为特定领域专用，叫做 “特定领域语言 ” （DSL）。DSL的目的是解决特定领域的问题，而不是像GPL一样可以解决任意的软件问题。DSL在计算机软件开发中十分常见，比如前端开发中常见的HTML和CSS就是一种DSL，专用于Web开发。MySQL是一种DSL，专用于操作数据库。Make是一种DSL，专门用来处理Shell脚本操作系统文件输入和输出。
如果您是一个以解决问题为目标的全栈工程师 ，我建议您在考虑发明一个DSL之前先考虑以下方案 。
- 尽量用您熟悉的通用语言来解决问题 ，比如Python、Java或C++。
- 优化您的解决方案，提炼出一种真正精简、优雅的扩展库。
- 开源您的扩展库，根据其他人的贡献来继续优化解决方案。
- 如果想简化配置文件的语法，可以创建一个脚本包装器来专门为库工作，这就是您自己的DSL。
- 如果最后您还是想进一步优化下去，那就发明您的DSL吧。
框架和库拓展了语言
在快速开发中，真正重要的是库，全栈工程师的目标往往是快速解决商业问题，不一定需要长期完美的方案。使用方便好用的框架能大大节省学习成本和开发时间，所以有些时候我们的技术选型步骤是：先选择框架，然后选择语言。
2. 脚本语言的优势
一个误解，Swift是一种语法很像脚本语言的编译语言。脚本语言跟编译语言的差异不在于语法，而在于编译机制。
脚本语言，是指支持用脚本的方式编写程序的语言，它无需编译即可直接在运行时环境中解析。在操作上，它缩短了传统的 “编写编译链接运行 ”过程。脚本语言通常具有简单、易用的特性，而且常常很短小。
相比编译语言脚本语言有更高的开发效率，但是在执行效率上会有所牺牲。由于现在的趋势是硬件成本越来越低，而工程师的人工成本越来越高，所以脚本语言的使用空间越来越大，有一些脚本语言（ Python、Ruby ）已经在成熟的商业网站中使用。
不同的脚本语言有不同的设计原则，但是它们往往有一个共同的目标，就是以简单的方式，快速完成某些复杂的任务。
脚本语言不需要编译
脚本语言的特点是无需编译即可运行，它在对应的运行环境中直接运行，运行时通过解释器来逐句解析。
因为语言跟对应的解释器（或者编译语言跟对应的编译器）是分开的两个概念，所以从科学上讲，只要给定合适的运行时环境和库支持，任何语言都可以作为脚本语言来使用（也就是编写脚本） 。也就是说， “编写脚本”是对语言的一种使用方法 ，而称某种语言为脚本语言是一种工程上的约定俗成的用法，而不是科学上的定义。
而且另一个问题是，无论是脚本语言还是编译语言，最终都需要编译成机器码让机器来执行。比如JS语言 ，在v8引擎中被编译为机器码然后执行，如果是使用Node.js。那么这个机器码可能会被缓存起来，这样的话，跟编译语言就没什么区别了。
脚本语言常常不需要关心清理内存
因为脚本语言的设计目标是快速写出能运行的程序，它更倾向于取悦工程师，而不是优化性能。所以在语法上就忽视内存管理，而该语言的解释器则各显神通，把清理内存垃圾的重担揽在自己的黑盒里面，无需工程师关注。
脚本语言常常会对特定领域优化
脚本语言常常是动态类型语言
脚本语言的抽象层常常更高
脚本语言常常有包管理器
十、全栈游乐场1. VPS
虚拟专用服务器（VPS）是把一台服务器分割成多个虚拟专享服务器的优质服务。每个VPS都可分配独立公网IP地址、独立操作系统、磁盘空间、内存、 CPU资源、进程和系统配置，模拟出 “独占 ”使用计算资源的体验。
比较廉价的选择是虚拟主机（Virtual Host），又称虚拟服务器或虚拟空间。虚拟主机将一台服务器的某项或者全部服务内容逻辑划分为多个服务单位，对外表现为多个服务器，从而充分利用服务器硬件资源。
如果使用虚拟主机，跟其他人共享CPU和内存等资源，这就像是合租。如果其他人在使用卫生间，您就没法用了。虚拟主机的好处是很便宜，国内一些服务提供商提供年费仅几十元的虚拟主机。虚拟并非指不存在，而是指空间是由实体的服务器延伸而来，其硬件系统可以是基于服务器群，或者是单个服务器.
为什么推荐一个全栈工程师买一台VPS自己玩玩？
对网站全貌有所了解
如果采用第三方的托管服务来搭建博客系系统，新建一个账号就可以开始写了，好处是很方便，缺点是在自定义功能上比如绑定独立域名，安装插件和修改路径格式代没那么灵活。
如果有瘾vps搭建一个博客网站就麻烦一些。
- 初始化。linode提供一键安装操作系统，等待几分钟操作系统就安装完成了。
- 安装最新版的Apache。启用Apache的rewrite等模块，WordPress的URL重写会用到。
- 安装MySQL数据库，配置WordPress的数据链接。
- 配置域名和路由。包括访问路由配置，日志配置，网站域名和别名等，启动服务器，查看资源利用等等。
- 当然也不要忘了安全防护和设置自动备份。
看上去很折腾，不过这种折腾是有意义的，因为他那里在操作的过程中理解了web工作原理。
时间就是金钱
推荐使用vps的第二个原因就是稳定。如果您想把精力集中在有用的技术上，而不是服务器无响应或者IP北墙等一些无聊的琐事，那么vps是最有性价比的选择。
部署自己的环境
学习Linux
理解HTTP
通过自己去配置和操作服务器，会让前端工程师也得http有更好的理解。
2. 如何选择vps？
每个人都有不同的需求，不过选择vps的原则都差不多，首先需要考虑的当然是性价比，主要参数是内存、CPU、硬盘和流量。
- 内存一般是vps的瓶颈
- CPU是相对没那么重要的性能指标
- 硬盘的大小和读写速度是关键。
- 还有一个重要的考虑就是客户服务。
关注服务及安全
能力越大责任越大，当你有了安装vps操作系统的能力，您就一定要学会保护自己的服务器。
操作系统的选择
域名解析
一般来说，域名购买商和服务器提供商都提供DNS解析的能力，不过域名在哪里注册和域名在哪里解析是两回事。
因为国内网络环境比较复杂，用户可能来自电信、联通、移动、教育网等网络，所以建议把域名的域名服务器设置为国内的智能DNS提供商，比如DNSPod。DNSPod除了可以根据用户IP来给出最佳的IP以外，还提供额外的功能，比如网站监控等增值服务。
云服务器
十一、高效工程师1. 提速100倍
阅读英文资料
- 英文的技术资料更多。
- stackoverflow有完善的鼓励机制。
- 谷歌的搜索能力非常强。
- 英语世界的语言风格比较严谨。
时间管理四象限
消除重复工作
给自己留出不被打扰的时间
番茄工作法
2. 跨界思考
过去跨界学习的成本很高，大部分人都不敢轻易尝试，但如今互联网时代给我们带来了机遇，每天上网都可以看到其他领域名人写的文章和微博，通过查看这些内容，我们就能对于原本完全陌生的领域有一个感性的认识，时间一久我们就能够在潜移默化中理解另一个领域的从业者的思维方式，当您开始跨界学习之后，就会增加更多的机会。
或许每个工程师会在不同的环境中，跨不同的界，但是在未来，我认为跨界出来的那部分能力才真正定义了“您”。
3. 纸上头脑风暴
4. 使用版本控制和构建系统
十二、学习设计在前面的章节里“如何成为全栈工程师”里，我给有志成为全栈工程师的同学的的第一个建议是“关注商业目标”，第二个建议是“关注用户体验”。而好的设计师优秀用户体验的必要非充分条件。
1. 科学家和工程师
首先，一个事实是：过去的工程师普片不在意设计。有意无意，他们忽视设计的重要性。
知乎网站上有一个帖子，问题是“为什么部分开发工程师不喜欢调节界面UI细节？”。我比较赞同下面这个回答：
我发现程序员大致可以分为科学家和工程师两类，科学家关注技术是否优越，而工程师关注产品是否完美。和科学家类型的程序员合作项目往往是件痛苦的事情，他们太过关注自己手中的的锤子是否先进，却不在意自己敲进去的钉子是否平整光滑不扎屁股，更不要说这可钉子是不是跟其他钉子对齐里。那些“资深”程序员更是如此，那个年代很多用户体验技术不成熟，能做出一个能用的东西已经不易，更不要说做出一个性能还算不错的产品。抱着这个想法走到今天，大多数应该被淘汰的程序员反而做到更高的位置，开始拿这种过时的想法熏陶小弟。（来自陈鑫的回答）
2. 细分不是最佳的解决方案
在传统Web设计流程中，我们也参考里工业化的流水线：按交互设计、视觉设计、前端开发、后台开发的流程来生产一个产品。按照这种细致的分工，设计师就要输出3个以上的页面：手机、平板、超大屏幕的电脑等。设计师在交付设计稿的时候如果有需要调整的地方，3个页面就要重新调整，只要设计发生里调整，就要更改每个对应的样式，大量的人力和时间就浪费在不必要的“流程”中。
我们的解决方案：视觉设计师关注设计模块和整体氛围，只需要给出一份为PC设计的视觉设计稿。让有一定合计理论基础的前端工程师根据拿到的PC设计稿直接创建可以适配多个平台的页面，也就是一个“响应式”的页面。
另一个例子，我们想在页面或者App中创建一些动画效果。在老式Web设计中不会有很多动画，但是现在，页面和App更强调每一个操作都给用户动画反馈，有些是为了更炫，有些是为了给用户操作反馈。但是浙西动画很那在设计稿中体现，这会给设计师和工程师带来很大的沟通成本。
我们的解决方案：让有一定设计功底的前端工程师主动提出自己对动画而见解，做出效果之后再反馈给设计师去确认，优化后的流程十分高效。
3. 设计基础
推荐一本书，Robin Wiliams的《写给大家看的设计书》，本书调理清晰简单易读，一个周末的下午或者每天半小时，持续一周就可以读完。但它的理论会如此深刻地停留在您的脑海里，每次看到不符合这些理论的设计，对应的理论就会迸发出老。
设计的四大基本理论是：亲密性、对齐、重复、对比。
- 亲密：关系亲密的元素要放在一起，关系疏远的元素则要分开。位置的亲密性直接表现出意义的相关性。
- 对齐：左对齐、右对齐、上对齐、下对齐。斜线对齐比较简单，居中对齐很难处理，新手不要尝试。
- 重复：视觉上使用重复的图形和元素、线条和颜色等。比如QQ空间重复使用的换色跟黑色
、微信的绿色、京东的红色等。 - 对比：如果两个元素（的大小或者颜色）不一样，就让它完全不一样，产生视觉冲击力。
所以“设计感”其实是“科学”而不是“艺术”。这些只是理论或者“规则”，规则总是可以被打破的，但是前提是要熟练掌握这些规则。在没有掌握这些规则之前，请遵循规则。
十三、全栈思维1. 有兴趣就够了吗
作者讲了一个把一本英文书籍交给两个很有兴趣做翻译的年轻人的故事，结果由于各种各样的理由延期交稿，延期里也不主动告知，而他们完成的部分也只能算勉强及格，错译、漏译的情况常常出现，可能存在一些能力问题，但他们给我们的感觉却是根本就不上心。
如果想拖延一件事，或者不想做一件事，总是能找到理由。懒惰的终极原因就是您想逃避这件事。对于所有刚开始工作的年轻人，我告诉你们：老板给您的任务，根本不关心您有sm理由，只关心您完成没有。
有人认为兴趣是成功的老师，无法完成某些事情是因为没有兴趣。其实我认为耐心是一种能力，有些人天生缺乏这种能力。在能力不足、困难重重的时候，唯有投入大量的时间才能保住着珍贵的信任。
新人没有经验、知识不丰富，这都可以理解，但是以此为理由输出不合格的产品，那就是自己的问题。
2. 学一点管理
不是每个人都有足够的自律和积极性。虽然作为全栈工程师，我们的学习目标一直是提升个人的技术能力。但是在组织中工作，并不需要特别强的个人能力或者天赋、更需要的是稳扎稳打、虚心学习，不要害怕批评，而应该真诚沟通、珍惜每一次机会，完成每一个承诺。
好的管理者能让平凡的员工做不平凡的事
高效能的管理者并不奢求完美的人才，他能让平凡的人成就不平凡的事业
《卓有成效的管理者》中的核心是5个思维习惯，这5个思维习惯环环相扣，非常经典。
- 有效的管理者知道她们的时间用在什么地方
- 有效的管理者重视对外界的贡献
- 有效的管理者善于利用长处，包括自己的长处、上司的长处、同事的长处和下属的长处。
- 有效的管理者集中精力于少数重要的领域，在这个少数重要的领域中，如果能有优秀的绩效就可以产生卓越的成果。
- 最后，有效的管理者必须善于做有效的决策
每一条都会花一章的篇幅来展开说明，每一章都有些让我醍醐灌顶的部分。比如“有效的管理者重视对外界的贡献”。
重视贡献，才能使管理者的注意力不为本身的专长所限，不为其本身的技术所限，不为其本身所属的部门所限，才能看到整体的绩效，同事也才能使他更重视外部世界。
3. 沟通：被忽视的竞争力
一个事实是，程序员的沟通能力所带来的价值被大大低估来。在我们的招聘流程中，技术能力过关，但是因为沟通能力这一项不过关，而直接被拒绝的面试者比例还是很高的。但是为了避免不必要的争议，大企业的HR往往不会把拒绝的原因传达给应聘者，所以对方也不知道自己为什么会被拒绝。
沟通能力的评判往往是非常微妙和主观的，并没有一份考题能证明您的沟通能力好或者差，只是面试官能根据自己的判断来决定。为了避免无休止的争论，所以刚脆不告诉拒绝原因是最好的。
沟通是软技能
针对目标听众
佛家有一个词叫“度己度人”，就是在帮助别人的过程中，其实也在帮助自己。所以反过来想，作为需求的请求方，最开始就得找到那个很关键的人，对于他来说，帮助您对他是很有好处的。也就是说他能把这件事当作i自己的冠军任务。如果您的要求对于他人纯属累赘，那么他人自然不愿意帮助您了，任您多么会沟通，最终都不管用。
所以，授权给平级的同事的时候，最好的方法就是诉诸对方的利益。如果一件事情可以对双方的KPI都有好处，那么对方也愿意帮助您一起分担这个任务。如果您把不擅长的事情授权给对方，而作为交换，能给对方一些资源，那也是诉诸利益的一个好方法。
其次的方法就是把问题上升到上级领导，让上级领导安排资源，但是这种方法不能经常用，否则上司会认为您不会主动解决问题，只会提出问题。被授权的那一方也觉得您在拿领导压制他，可能会存在负面的情绪。
有方法
麦肯锡的金字塔原理就是，任何事情都可以归纳出一个中心论点，而此中心论点可由3至7个论据支持，这些一级论据本身也可以是论点，被二级的3至7个论据支持，如此延伸，状如金字塔。使用金字塔方法的前提是，您的有一个中心目标。不能是两个，更多更不行，只能是一个。
表达自己的想法
看到这里，这本书就读完了！