于君泽等
在我看来，好的程序员应该是“工型人才”。所谓“工型”，是指从下到上的能力提升过程。具体来说，就是先要具备完成完整应用的能力
包括：线上运维，成为熟手，这是下面的一横；在某些领域足够深入，成为高手，这是中间的一竖；在达到更高的水平之后，兼通很多领域，比如业务、产品、项目管理、测试、运维、团队组织，成为驱动者和领导者，这是上面的一横。
每个人的成长都是不断打怪升级的过程，既要掌握技术和工具，又要学习方法和理论、积累实战经验，更要思考和沉淀。先进技术只是工具，最终目标是解决问题
有朋友问，写书的时间从哪里来？其实，因为热爱，不觉疲惫！写作是让自己梳理思路的一个机会。
一名画家若擅长使用多种类型的画笔，就可以创作出多种类型的艺术画作；一名程序员若掌握多种类型的编程语言，在解决问题时就可以有多种选择。
关于编程的书，大概有入门类、工具类、实战类、进阶类、原理类等，可以根据自己的知识程度进行选择，切勿盲目选择。
5．教是最好的学 通过写博客来学习也是非常棒的一种学习方式，这对于新技术的学习十分有效，还可以通过技术分享、线下会议及线上教学等方式将自己学到的知识分享给他人，这就是教学学习法。
教学学习法有如下好处。 ◎ 迫使自己更深入地了解更多的知识。 ◎ 在教学的过程中会加入自己的理解。 ◎ 可以回头翻看教学的内容。 ◎ 可以加深记忆。
对于在上线前发现代码缺陷，还有一种十分重要及奏效的方法，那就是代码审查（Code Review）
“懒惰”的程序员会尽量使自己的代码既实用又有很好的可读性，这样可以节省后面的很多维护成本；还会尽力完善代码中的注释及文档，以免别人问自己太多问题，更擅长使用各种工具，从方方面面提升自己的效率。
Maven和Gradle之所以能够赢得众多程序员的青睐，主要是因为它们在依赖管理、冲突解决、项目构建、项目结构管理和插件机制等方面的出色表现。
在很多大公司中，程序员们的分工越来越细致，从一开始的全栈开发，慢慢区分出运维工程师、开发工程师和测试工程师。慢慢地，开发工程师又区分出前端开发、后端开发和移动端开发。后端开发同样可以区分出业务开发、中间件开发；同样是业务开发，又可以深入地划分成不同业务领域的开发，比如电商业务开发、支付业务开发、游戏开发，等等。
分工的细致化，程序员更要积极主动地去了解其他人所做的事情，只守着自己的“一亩三分地”，被动地工作，是无法成为一个优秀的程序员的
空杯心态并不意味着要否定自己过去，而是怀着一种放空的态度融入新的环境，对待新的工作和事物。
别怕犯错，最重要的是从错误中学习到什么。
需要注意的是，别怕犯错，不等于不敬畏错误。别怕犯错，鼓励的是别害怕尝试，别害怕犯高级错误，有很多低级错误还是要尽量避免的。
如果没有很好地管理时间，那么留给写代码的时间可能就很少了，这也是很多程序员在晚上6点下班后才开始写代码的原因。
总之，要主动管理起自己的时间，不要让自己处于被动中。
◎ 对于紧急但是不重要的事情，首先想办法看看能不能把它们变成不重要也不紧急的事情，如果还是无法改变，则可以考虑和同事分担。 ◎ 对于不重要也不紧急的事情，不要做！
对于需求，先通过讨论解决，解决不了再用代码解决。这才是正确的顺序。这不是指程序员要尽最大努力减需求，而是要对不合理的需求说不。
在阿里巴巴，技术项目都是需要做设计评审的，这一方面是让合作方了解上下游之间的依赖关系，更重要的是让开发者彻底想清楚所有流程，这样才能在开发时按照自己的设计按部就班地实现。
张一鸣曾经公开谈到自己做事从不设边界。他在负责技术时，若遇到产品上有问题，也会积极地参与讨论并构想产品方案。他说：“你的责任心，以及你希望把事情做好的动力，都会驱动你做更多的事情，让你得到更大的锻炼。”
不设边界，看起来吃亏且多做了事情，但成长最快的是自己。
2017年8月，JCP执行委员会提出将Java的发布频率改为每6个月一次，并且该决定将在Java 9正式发布之后开始实行，新的发布周期严格遵循时间点，将在每年的3月和9月发布。2019年3月，Java 12正式发布
笔者认为，要想比其他人更加高效地学习，就只需做到如下三点：管理好自己的目标、利用好碎片时间，在同一时间只做一件事
黑天鹅寓意不可预测的重大稀有事件，它在意料之外，却又改变着一切。人类总是过度相信经验，殊不知其实一只“黑天鹅”的出现就足以颠覆一切。
泰坦尼克号沉没、9·11事件、美国的次贷危机、2008年中国的雪灾，都是比较典型的黑天鹅事件。
“黑天鹅”存在于各个领域，无论是金融市场、商业、经济还是个人生活，都有它的踪迹。最近几年发生的几个IT领域相关的黑天鹅事件如下。
◎ 2015年5月27日下午5点左右，某支付平台出现网络故障，导致账号无法登录，无法完成线上支付。后经证实，该故障是由于杭州市萧山区某地光纤被挖断导致的，这一事件造成部分用户无法使用该支付平台，其影响辐射到全国范围内的各个领域。
我们要当心被自己思想的丝线束缚。无论是泰坦尼克的沉没，还是中兴被制裁，如果业界没有类似的案例，那么几乎无从借鉴。
有时我们太看重自己知道的事，却没发现我们不知道的事比我们知道的事更有意义，所以只有反常地思考一切，才有可能发现更多的“我们不知道的事”。
“墨菲定律”是一种心理学效应，由爱德华·墨菲（Edward A. Murphy）提出。它的原句描述为：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人做出这种选择。
◎ 会出错的事总会出错； ◎ 如果你担心某种情况会发生，它就更有可能发生。
墨菲定律告诉我们：事情往往会朝着我们所能想到的不好的方向发展，只要存在这种可能性。所以，无论是开发人员还是测试人员，都需要谨记墨菲定律，莫存侥幸心理，要把自己的系统设计得足够强壮。
黑天鹅事件告诉我们要走出经验主义，不要将自己知道的东西太当回事，我们不知道的事比我们知道的事更有意义。
该电商网站的开发人员第一时间排查问题，发现在几分钟前有一次代码发布，在快速回滚后功能恢复。他们通过代码审查，发现在本地发布中只有一行代码改动，即在数据的分页查询中，某开发人员将pageSize从10改成了50。
导致该故障的因素有很多，下面进行简单分析。 ◎ 这个默认设置当初是一个“临时方案”，但是一直没被改过。这就是技术债的问题。
◎ 如果不仔细阅读代码，就无法发现这个默认设置，因为这个故障在任意文档中都没有记载，并且没有被其他开发人员提到，更重要的是，在上线前未经过代码审查。这就是人、流程与文档之间的博弈问题。
◎ 在代码上线之前未经过测试。开发人员认为这只是一个很小的改动，不会有什么问题，所以就直接发布了。这就是质量意识淡薄的问题，也恰巧印证了墨菲定律：未经过测试的功能往往存在问题。
开发人员第一时间对机器的堆栈进行Dump（转储），发现ThreadLocal中的一个对象占用了大量的内存。在分析代码时，他们发现在ThreadLocal中保存了一个Map作为本地缓存，在这个Map中保存了很多缓存对象，
某天中午，开发人员收到大量的线上告警，提示某些机器的负载超过了500。开发人员便赶紧登录线上机器，使用top命令查看了CPU的情况，发现CPU消耗接近100%!，(MISSING)于是又通过shift h命令查看线程的情况，发现并没有CPU消耗较高的线程，消耗量基本在0.7%!左(MISSING)右，但线程总数看起来很多。
开发人员通过ps -eLf |grep java -c命令统计了线程总数，发现一共有700多个线程，所以又连续执行了几个jstack命令查看线程堆栈，发现其中有600个线程处于RUNNABLE状态，并且都在执行HashMap的get方法。根据经验，基本可以断定问题是由于在并发场景下错误使用HashMap导致的。
故障发现和故障处理是很多公司都比较重视的两个环节，故障复盘却被经常忽视
6.7.1 什么是故障复盘 “复盘”原是围棋术语，本意是对弈者在下完一盘棋之后，重新在棋盘上把对弈过程摆一遍，看看哪些地方下得好，哪些地方下得不好，哪些地方可以有不同甚至更好的下法等。这种把对弈过程还原并且进行研讨、分析的过程，就是复盘。
这其中的最主要原因是很多人对故障复盘存在误解，认为故障复盘的目的就是“分锅”和“甩锅”。不可否认，自我反思与相互批评是故障复盘中很重要的一个环节，但是，这并不是故障复盘的最终目的。故障复盘的最终目的其实是通过对已经产生的故障的反思，进行总结及优化。
笔者认为，故障复盘主要有如下目的。 ◎ 对已发生的故障进行总结，避免再次出现同样和类似的问题。 ◎ 找出团队的强弱项，优化人员分工和办事流程。 ◎ 尝试找到更好的问题解决办法。 ◎ 进行经验总结，分享沉淀，引起大家的广泛重视。
◎ 在故障复盘之前，相关人员应对本次故障的背景有基本了解。 ◎ 在复盘过程中不批评、不表扬，就事论事，只陈述事实。
阿里巴巴高级运维专家胡杨曾经总结过一套“RASA”理论，RASA即Review（回顾）、Analyze（分析）、Summary（总结）和Action（行动）
◎ 必须是明确的项，要有明确的行动点，不能是大而空的规划。 ◎ 必须可落地，能够切实改善既有问题。 ◎ 必须可验收，有明确的验收标准。 ◎ 必须承诺验收时间，并且要在原则上按照承诺的时间完成。
应急处理原则如下。 ◎ 应该第一时间恢复系统，而不是等彻底解决问题后恢复系统，要快速止损。 ◎ 在明显造成资金损失时，要第一时间升级、快速止损。
◎ 当运维负责人不能在短时间内解决问题时，必须进行升级处理
1．定位故障 在定位故障时，我们可以通过系统最近发生的变化，以及系统层、应用层和中间件层监控来定位故障，例如： ◎ 系统最近是否上过线？ ◎ 依赖的基础平台是否升过级？ ◎ 依赖的系统是否上过线？ ◎ 是否有线上营销活动？ ◎ 网络是否稳定？ ◎ 业务量是否有变化？
对系统层一般监控如下指标。 ◎ 系统的CPU使用率。 ◎ 平均负载（Load Average）。 ◎ 内存（Memory）。 ◎ 网络与磁盘I/O。 ◎ SWAP使用情况。 ◎ 线程数。 ◎ 文件描述符（File Description）等。
对中间件层一般监控如下指标。 ◎ 数据库的负载、慢查询、连接数等。 ◎ 缓存的连接数、占用内存、吞吐量、响应时间等。 ◎ 消息队列的响应时间、吞吐量、负载、堆积情况等。
“主管”这个人设被赋予了大量的标签和职能，其修炼并非一朝一夕即可完成，与其自身的思考深度及机遇也有很大关系。
满意的工作从两件事开始，一是有明确的目标，二是有实现这一目标的可操作性步骤。
有明确的目标可激励我们采取行动，让我们知道自己该做什么；有可操作性步骤可确保我们立刻朝着目标前进。我们需要对自己在做的事情有一张明确的阶段性画像，这张画像一定是自己内心所向往的。
业务人员往往会犯这样的错误：只关注业务实现，对算法和组件只停留在“用”的阶段，不会深入了解算法、网络传输协议和组件实现思想等更进阶的内容。
根据在目前工作中所用到的技术体系去深入学习，这样才会具备技术主管的主要技能：追求最优化的实现，剖析问题的本质及整体业务架构。
简单概括一下：管理的核心，就是利用组织的资源把事干好，从而达到组织的目标。
8.4.1 确定在做的事情符合自己的目标 在谈论高效时间管理之前，我们必须十分清楚自己的目标是什么，并且在行动及时间安排上始终瞄准自己的既定目标。从另一个角度来说，最糟糕的时间管理，就是花费很多时间做毫无意义的事情且做得十分圆满。
承诺和一致性原理指的是，人一旦做出承诺，所做的行动都会跟承诺的事保持一致。
1．彻底理解需求 所谓“知之为知之，不知为不知，是知也”，很多人在跟老板沟通时，为了保持在老板心目中的聪慧形象而放弃提问。然而，因为认知、信息来源和立场不同，老板在需求描述时给出的信息，不一定是所有人都能完全理解的，所以要敢于提问，理解、确认直至彻底理解需求，千万别带着疑问上路。
一言以蔽之：及时汇报传递信息、发现工作中的问题不光是为了减少公司损失，也是为了让领导更了解你，因为领导通常会思考如下问题。
（2）简单扼要地表达。尽量用简洁的语言将自己需要汇报的内容表达出来，这样有利于领导获取信息，所以建议在汇报前罗列好汇报清单，而不是在汇报中组织汇报清单。