简介

精彩点评

• 

  fy云端☁

  推荐

  对于想明确下成长方向的，书整体讲得挺不错的，对于想要提高专研技术的，本书还是太宽泛了

• 

  海东

  推荐

  做技术多年，随着年龄渐长，很多程序员都会有这些疑惑，我也经常被别人咨询过这些问题： 做了很多年的程序员到底要不要转管理，转做管理有前途吗？ 转做管理后到底怎么带团队？ 这些困惑都因为——年龄是职场生存的一条重要法则。 程序员薪水虽高，但光鲜的外表下，背后的苦衷只有自己知道。三十多岁本该是一个人事业的黄金期，但技术变化日新月异，行业竞争异常残酷，对一个企业来说，永远有更年轻、劳动成本更低的人可以选择，这让程序员的中年危机提前到来。 其实不管是否转型还是要练好三板斧：技术、架构、管理。 关注我一起交流程序员那些事。

• 

  徐志伟

  推荐

  个人觉得内容讲的较广但是比较浅，适合初级程序员寻找方向，不太适合工作时间长的高级程序员。

• 

  flex

  推荐

  业务分析章节不错，看完基本能理清楚实际开发中抽象业务到具体的代码所需的步骤。 架构设计章节算是对现在中小公司的常用的玩法有个总结，基本都是这么玩的。最后两章，没啥干货，快速阅读。

• 

  何小林

  推荐

  前面的技术章节，感觉视角比较小，过于关注技术点，没有细看。后面的技术管理的章节，写得还是不错，给出了一些确实可以操作的方法，如如何管理绩效不佳的员工。

• 

  万玉祥

  推荐

  全文应该就第三章写的还可以，站在自己角度讲解领导力和带领团队。适合带过团队的人，来相互印证经验。

• 

  Jacky蕭

  推荐

  目录框架会有一点指导作用，但又不多吧。可以快速看看，以了解了解

• 

  Nardo

  推荐

  19年等77本书，就是大型目录，说的都很空泛。不如直接看相关的名著。如敏捷相关，高效程序员的45个习惯等。内容太多，蜻蜓点水，跟名词解释无区别。如果想阔知识面，不如看 李知慧的大型互联网站，还有就是淘宝味有点重。内容还提到阿里规范和在阿里的历程，感觉对内容没有什么关系。何必强调自己的阿里身份。书中谈到太多，设计原则，面向对象，tdd，ddd。技术管理，还有不服气的员工怎办。2.5星吧。可以翻，没有太大价值。

• 

  王磊

  推荐

  架构部分大👍🏻 ◆ 1.2 代码规范与单元测试 >> 我们团队在项目实际操作过程中没有严格遵循测试驱动设计的步骤，但是遵循了同步编写开发代码和测试代码的思路。 ◆ 4.2 集成 >> 如果某个系统提供一个高并发、低延迟的共享用户会话方案（Shared Session Storage），则Redis可能是一个非常理想的选择；如果实现一个产品目录，涉及大量不确定结构的商品数据及属性的建模管理，则系统可能会采用模式灵活、有动态Schema的MongoDB作为数据库解决方案；如果系统希望支持非常强大的全文搜索能力，则可以采用Elasticsearch。 ◆ 5.1 架构设计概要 >> 应用架构的设计原则如下。 （1）稳定 ◎ 一切以稳定为中心。 ◎ 架构尽可能简单、清晰，追求小而美，不要大而全。 ◎ 不过度设计。 （2）解耦 ◎ 将稳定部分与易变部分分离。 ◎ 将核心业务与非核心业务分离。 ◎ 将电商主流程和辅助流程分离。 ◎ 将应用与数据分离。 ◎ 将服务和实现细节分离。 （3）抽象 ◎ 应用抽象化：应用只依赖服务抽象，不依赖服务实现的细节和位置。 ◎ 数据库抽象化：应用只依赖逻辑数据库，不需要关心物理库的位置和分片。 ◎ 服务抽象化：应用虚拟化部署，不需要关心实体机的配置，动态调配资源。 （4）松耦合 ◎ 跨域调用异步化：在不同的业务域之间尽量异步解耦。 ◎ 非核心业务尽量异步化：在核心业务和非核心业务之间尽量异步化。 ◎ 在必须同步调用时，需要设置超时时间和任务队列的长度。 （5）容错设计 ◎ 服务自治：服务能彼此独立修改、部署、发布和管理，避免引发连锁反应。 ◎ 集群容错：应用系统集群部署，避免单点服务。 ◎ 多机房容灾：多机房部署、多活。 >> （1）无状态，即尽量不要把状态数据保存在本机上。 （2）可复用。 ◎ 复用粒度是有业务逻辑的抽象服务，不是服务的实现细节。 ◎ 服务引用只依赖服务抽象。 （3）松耦合 ◎ 跨业务域调用，尽可能异步解耦。 ◎ 在同步调用时设置超时时间和队列大小。 ◎ 将相对稳定的基础服务与易变流程服务分离。 （4）可治理 ◎ 服务可降级。 ◎ 服务可限流。 ◎ 服务可开关。 ◎ 服务可监控。 ◎ 白名单机制。 ◎ 制定服务契约。 （5）基础服务 ◎ 基础服务下沉、可复用，例如时效、库存和价格计算。 ◎ 基础服务自治、相对独立。 ◎ 对基础服务的实现要精简，并可水平扩展。 ◎ 对基础服务的实现要进行物理隔离，包括基础服务相关的数据。 >> 数据架构的设计原则如下。 （1）统一数据视图，即保证数据的及时性、一致性、准确性和完整性。 （2）数据和应用分离。 ◎ 应用系统只依赖逻辑数据库。 ◎ 应用系统不直接访问其他应用的数据库，只能通过接口访问。 （3）数据异构，即在源数据和目标数据内容相同时做索引异构，在商品库不同维度的内容不同时（如订单数据中的买家库和卖家库）做数据库异构。 （4）数据库读写分离。 ◎ 将访问量大的数据库做读写分离，例如订单库。 ◎ 将数据量大的数据库做分库分表。 ◎ 将不同业务域的数据库做分区隔离。 ◎ 对重要的数据配置备库。 （5）采用关系数据库。除成本因素外，MySQL的数据库扩展性和高并发支持能力较强，也比较容易招聘到相关的研发人员和运维人员。 （6）合理利用NoSQL数据库。在数据库有能力支撑时，尽量不要引入缓存。另外，要合理利用缓存做容灾。 ◆ 5.3 架构设计的核心要素 >> 软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个要素，下面分别对这5个要素进行讲解 >> 网站可扩展架构的主要手段是事件驱动架构和分布式服务 ◆ 5.4 高性能设计 >> 从开发者的视角来看，性能的重点在于应用服务器的性能，包括响应延迟、系统吞吐量、并发处理、系统稳定性等，主要的优化手段是利用缓存加速数据读取，使用集群提高吞吐量，使用异步加快请求响应，优化代码改善程序，等等。 从运维人员的视角来看，性能相当于一些基础设施的性能和利用率。 ◆ 5.6 可伸缩设计 是not only sql >> 非关系数据库设计模式 >> 非关系数据库设计模式 ◆ 5.7 可扩展性设计 >> 负载均衡、失效转移、高效的远程通信、整合异构系统、对应用最小入侵、版本管理和实时监控。 ◆ 第6章 架构的保障：质量与风险 >> 不接受不良品，不设计或制造不良品，不流出不良品 >> （1）P（Plan）：指仔细分析现状，并将现状与目标进行对比，看看缺口在哪里，然后详细规划改善的步骤。可以分几个步骤：一是将问题和目标定义清楚；二是利用各种工具，例如作业流程图、鱼骨图等，将问题相关的流程和因素梳理出来，定下优先顺序；三是进一步拆解流程，仔细分析各个步骤，看看问题可能出在哪里。 （2）D（Do）：指根据计划动手改进。需要事先想好退出计划，在动手时应从小处切入，谨防破坏现有流程，造成系统瘫痪。如果解决方案不止一个，就应该设计一个实验，评估各方案的优劣。 （3）C（Check）：指监控改进过程。需要确认测量工具和方法维持不变，否则可能误判。在结果数据出来后，需要仔细分析，看看哪种方案比较有效，而且对原来流程的变更幅度最小。 （4）A（Act）：指确认改善的确有效，在不良和缺陷已经消除后，导入及固化流程，改写规范。若改善无效，则检讨原因、修改计划，重新启动一轮PDCA循环。 ◆ 6.2 从黑天鹅事件到墨菲定律 >> 黑天鹅寓意不可预测的重大稀有事件，它在意料之外，却又改变着一切 >> 黑天鹅事件通常具备如下三个特点： （1）稀缺、史无前例（Rarity）； （2）影响很极端（Extreme Impact）； （3）具有意外性，但人的本性促使我们在事后为它的发生编造理由，并且或多或少认为它是可解释和可预测的 >> 亚马孙雨林中的一只蝴蝶偶尔振动翅膀，也许会引起两周后美国得克萨斯州的一场龙卷风。” >> 如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人做出这种选择。 >> 墨菲定律（Murphy's Law）的主要内容如下： ◎ 任何事都没有表面看起来那么简单； ◎ 做所有的事花费的时间都会比你预期的时间长； ◎ 会出错的事总会出错； ◎ 如果你担心某种情况会发生，它就更有可能发生 ◆ 6.3 软件质量稳定性之殇 >> 黑天鹅事件告诉我们要走出经验主义，不要将自己知道的东西太当回事，我们不知道的事比我们知道的事更有意义。蝴蝶效应告诉我们要及时感知问题，止损和熔断，避免问题范围扩大甚至传染到其他相关领域。墨菲定律告诉我们，我们知道的但是忽略的地方终究会出问题 >> 无意的：由于经验的缺乏导致初级开发者编写了质量低劣的代码。 ◎ 有意的：团队根据当前而非未来进行了设计选型，这种方式可能很快解决了当前的问题，但很拙劣。 >> 随着技术团队人员的能力提升，无意的技术债务可能会越来越少。但是在很多时候，我们欠下的技术债务往往是有意的，随着业务的高速发展，还会带来很多变化 >> 临时方案的可怕之处，不仅仅在于其不全面，更在于如果不对其及时处理，可能就永远“临时”下去了。随着团队成员的不断更替，慢慢地就没人记得这个临时方案了。一个说好只支撑两个月的临时代码，可能两年后还在线上机器里运行着。 >> ◎ 通过人员培训、代码审查等方式杜绝无意的技术债。 ◎ 要尽量避免有意的技术债。 ◎ 如果一定要引入技术债，则一定不要引入不计后果的技术债。 ◎ 要记录所有欠下的技术债，并且有偿还计划。 >> 但是不得不说，有很多线上故障都是由于开发者对所使用的新技术不了解导致的。 >> 经过分析，80%的线上问题并不那么难以解决，其本质是未遵循规定的动作。 ◆ 6.4 从康威定律和技术债看研发之痛 >> 康威定律由Conway在1967提出，其主要观点是：设计系统的架构受制于产生这些设计的组织的沟通结构。 >> 软件开发领域有一个流行的原则：DRY（Don't Repeat Yourself），我们一般将其翻译为：不要重复造轮子 >> 架构是演进出来的，而不是设计出来的。笔者比较赞同这种说法 >> 架构方案和业务形态息息相关。 ◎ 架构是演进的、发展的，没有最好，只有适合。 ◎ 技术债要做清偿计划。 ◎ 不要在下雨天补屋顶 ◆ 6.5 求解质量熵 >> 黑天鹅告诉我们，要走出经验主义，就不要将自己知道的太当回事，我们不知道的事比我们知道的事更有意义；蝴蝶效应告诉我们，要及时感知问题、止损和熔断，避免问题范围扩大甚至影响到其他相关领域；墨菲定律告诉我们，你知道却忽略的问题终会爆发！ >> 我们可以建立如下价值观： ◎ 个体和互动优于流程和工具。 ◎ 能工作的软件优于详尽的文档。 ◎ 客户合作优于合同谈判。 ◎ 响应变化优于遵循计划 >> ，当我们适应了原有状态却需要面对改变时，我们会经历抵抗、混乱、改变主意、重新上路等过程，最后适应新的状态。 >> 技术人员水平不行、意识不够，代码越写越乱。 ◎ 开发者都有一颗积极向上的心，但不知道如何做才好。 ◎ 上行下效，没有靠谱的Leader、架构师，大家便都是懒惰的，不想去还债。 ◎ 业务压力太大，赶着交付，没有时间清偿技术债 >> 这里总结了几个有效应对思路。 ◎ 构建质量保障体系，让开发人员有勇气动手改造。比如进行接口测试、单元测试，通过持续集成进行反馈，这样开发人员在做重构的时候就有一些基本保障。 ◎ 不要动遗留系统中没有出问题的地方，对于遗留系统中出问题的地方，修复并补充测试代码，更进一步地，对高危功能和模块做定向增强。 ◎ 招募优秀的工程师，使好的工作作风和习惯影响整个团队。 ◎ 抓住痛点大做文章。比如，平时说持续集成，可能团队成员没有感受到其好处，那么出Bug了再讨论讨论； >> 通过ATDD、引流对比、串讲反串讲、评审、录制回放验证、接口回归测试等手段可以验证从需求到设计再到实现是否发生了变形。 >> 一旦以某种高耦合方式引入某种技术，调整或者去除该技术的成本就会呈几何级数形式。 >> 除了需要构建功能回归测试环境，还需要构建性能回归测试环境，以保障每次发布的产品性能是没有降低的 ◆ 6.6 踩过的坑和经验总结 >> 这个默认设置当初是一个“临时方案”，但是一直没被改过。这就是技术债的问题 >> 在上线前未经过代码审查。这就是人、流程与文档之间的博弈问题。 >> 也恰巧印证了墨菲定律：未经过测试的功能往往存在问题。 >> 主要还是由于技术债导致的。由于在方案设计初期没有考虑到业务发展可能带来的变化，在无意中引入了“临时方案”，就欠下了技术债，进而导致故障的发生。 ◆ 6.7 故障复盘流程及模板 >> 故障复盘的最终目的其实是通过对已经产生的故障的反思，进行总结及优化。 笔者认为，故障复盘主要有如下目的。 ◎ 对已发生的故障进行总结，避免再次出现同样和类似的问题。 ◎ 找出团队的强弱项，优化人员分工和办事流程。 ◎ 尝试找到更好的问题解决办法。 ◎ 进行经验总结，分享沉淀，引起大家的广泛重视。 >> 故障复盘主要有如下目的。 ◎ 对已发生的故障进行总结，避免再次出现同样和类似的问题。 ◎ 找出团队的强弱项，优化人员分工和办事流程。 ◎ 尝试找到更好的问题解决办法。 ◎ 进行经验总结，分享沉淀，引起大家的广泛重视 >> 故障发生时间、故障描述、影响范围、主要模块、相关责任人、故障处理人员、故障处理时效、故障的当前状态、故障解决时间、故障解决方案、故障原因、故障定级等。 >> 故障定级根据不同的业务有着不同的指标，通常可以参考的指标有：影响用户数、故障恢复时间、用户投诉数、资金损失数、模块重要性等。 >> 在定性和定责时需要明确出哪些个人（团队）对本次故障承担主要责任，哪些个人（团队）对本次故障承担次要责任，定责过程要公平、公正、公开，做到权责一致、边界清晰 >> 制定的行动点都需要满足如下条件。 ◎ 必须是明确的项，要有明确的行动点，不能是大而空的规划。 ◎ 必须可落地，能够切实改善既有问题。 ◎ 必须可验收，有明确的验收标准。 ◎ 必须承诺验收时间，并且要在原则上按照承诺的时间完成。 ◆ 6.8 监控与告警 >> 监控是每个公司都必不可少的重要风险防控手段。 >> JMX框架提供了关于JVM的大部分核心信息，应用系统可以通过接入JMX框架来实时读取JVM的CPU、内存等信息。 >> 警信息需要包含时间、机器IP、告警原因、告警描述和错误日志等重要信息，以便于开发人员快速排查问题，如图6.22所示 ◆ 6.9 应急处置 >> 系统最近是否上过线？ ◎ 依赖的基础平台是否升过级？ ◎ 依赖的系统是否上过线？ ◎ 是否有线上营销活动？ ◎ 网络是否稳定？ ◎ 业务量是否有变化？ 对系统层一般监控如下指标。 ◎ 系统的CPU使用率。 ◎ 平均负载（Load Average）。 ◎ 内存（Memory）。 ◎ 网络与磁盘I/O。 ◎ SWAP使用情况。 ◎ 线程数。 ◎ 文件描述符（File Description）等。 ◆ 7.1 构建自我阶段性目标 >> 满意的工作从两件事开始，一是有明确的目标，二是有实现这一目标的可操作性步骤。 ◆ 8.1 什么是领导力 >> 管理的核心，就是利用组织的资源把事干好，从而达到组织的目标。 >> 管理的核心在于事，领导力的核心在于人。 ◆ 8.3 让自己成为T型人才 >> 我们也可以将T型人才简单理解为“一专多能”, T字的横轴表示跨专业领域的思考能力，T字的纴轴表示精深的专业能力 >> 需要做充分的准备。 ◎ 离开舒适区，学会挑战自己，让自己所掌握的技能变得更为精深；与同行保持交流，从中掌握不同的设计方案和不同的思考方式。 ◎ 坚持阅读及与不同领域的人交流，以接纳更多的信息和观点。 ◎ 创造需求，及时应用和实践自己掌握的知识，这也是让知识变得更有价值的好方法，而不仅仅是让知识成为一种可阅读的信息流。 ◎ 尝试训练自己从多个角度分析问题，或用不同的思维思考问题。 ◎ 给学习和应用设定目标和里程碏，让自己一步步地成为T型人才。 ◆ 8.5 遇到“不服管”的员工怎么办 >> 典型的技术思路：找出“不服管”的原因所在，针对原因找出解决方案，实施方案

• 

  王逸少

  推荐

  程序员不仅需要写好代码，还需要合理规划自己的职业发展路径。本书以作者多年的实践经验总结为基础，从程序员的技能、成长、学习、进阶，到架构和管理等的成长周期做了深入分析，不仅讲到如何写出具有专业水准的代码，还讲到如何快速成长，以及如何转型架构和技术管理。

• 

  吴默默

  推荐

  从技术精进，架构思维，管理方式展开讲述，内容很满，但很多讲的都比较宽泛。 总体看完还是有收获的，比如代码审查，主动性，时间管理，工作优先级，学会'偷懒’，从成就自己到成就他人，以及做重要的一点就是搞清楚你人生的意义和真正想要的是什么，也是近期在思考的问题。

• 

  胡明 HHH

  推荐

  五位作者的合集，将各自的经验分文别类整理成程序员的三门课，这三门课通常也是程序员的职场发展之路，编码、架构然后是带队伍编码，架构。 前两节课技术精进和架构修炼部分可以快速过一遍，是对程序开发涉及的方法与概念的整理，新手可作为继续深入的索引，老手也可系统回顾一遍。 虽然是三门课，但涉及范围广，内容太过浅显，使整体可读性不高。

• 

  捷后愚生

  推荐

  做为一个测试，前面两篇没有阅读，大概浏览技术精进一篇前面的部分（如何学习新的编程语言），我认为前两篇应该也是不错的。 直接看第三篇管理探秘，以下是一些收获。 如何构建领导力 管理的核心，就是利用组织的资源把事干好，从而达到组织的目标。 我的理解，就是组织、上级有什么目标，给我这边什么资源，我指定更加具体的实施计划，实现这个目标。 技术领导力4D框架 维度1：提供清晰的领导力风格，并以信任感作为基石 说实话，读了两遍书中这部分内容，还是不大明白书中说的提供清晰的领导力风格是什么到底是意思？ 清晰的领导力风格的判断标准是什么？ 管理者在向员工布置任务时，会把任务“重复”5遍： 管理者：我有一个任务要交给你，任务是这样的……（第1遍进行详细的任务说明） 员工：好的，我知道了。 管理者：稍等，你能重复一遍这个任务吗？ 员工：好的，您交给我的任务是这样的……（第2遍重复任务是什么） 管理者：你有想过我为什么会布置这个任务吗？ 员工：我理解，您布置这个任务的原因是……（第3遍谈论任务的目的） 管理者：在这个任务的进行过程中，你觉得会出现什么意外情况？遇到什么情况你会向我汇报？遇到什么情况你能自己决定？ 员工：我理解，在这个任务中，可能会遇到的意外情况有……（第4遍明确风险和汇报标准） 管理者：如果这个任务让你自己做，你会有什么更好的建议和想法吗？ 员工：如果这个任务让我自己做，我会……（第5遍让员工发挥主观能动性） 维度2：了解业务，并带领团队达到高绩效 在技术管理者带领团队确定战略方向，制定技术和组织实施的过程中，技术管理者本身也在进行角色从“演员”到“导演”的转换和突破。在没有做技术管理者之前，技术专家在遇到问题时往往都冲在最前面，就像舞台聚光灯下的演员。管理者则需要对整台戏进行策划，寻找最合适的演员，然后给每个演员都分配明确的角色，让演员们在舞台上都有最出色的表现，自己却可能不上台。因此，从技术到管理的一个非常重要的突破就是从台前的“演员”变为幕后的“导演”。因此，“了解业务，带领团队高绩效”其实也是管理者本身升级和突破的过程。 维度3：发展自己和团队成员 对于刚从技术专家转换角色的领导者，首先需要实现的突破就是忍住“我自己做”的冲动，转为发掘和培养一个最合适的人，然后选择最适合他的工作，把事做到最好。 维度4：塑造未来 对一个技术领导者而言，领导力中非常重要的一环就是：和团队一起确立共同的愿景，带领追随者实现梦想，同时协助他人实现自我和超越自我。 这个自己现在暂时还达不到。 高效时间管理 确定在做的事情符合自己的目标 在谈论高效时间管理之前，我们必须十分清楚自己的目标是什么，并且在行动及时间安排上始终瞄准自己的既定目标。 第1步：确定自己究竟想要什么 利用面向未来的场景进行一次思考：假如在什么时间，需要对你过去的经历和成就进行总结，请思考，在这样一份总结中，你希望得到什么样的总结？ 第2步：把自己的目标写下来 心理学研究证明，如果只把一个目标停留在脑海中，没有以书面形式记录下来，那么它就始终是一个空想，毫无生命力可言。相反，如果把自己脑海中的目标用白纸黑字写下来，这些目标就会变得更清晰、更具体，也会帮助自己创造一个看得见、摸得着的行动蓝图。 第3步：为自己的目标设定一个最后期限，并让大家都知道 在为自己的目标设定一个最后期限，并且让大家都知道（这非常重要）之后，出于心理学上“承诺和一致性”的压力，你就会在不知不觉中避免拖延，事情会完成得更快，工作效率也会提高。 第4步：将实现目标需要做的最重要的事情列出来 根据优先级从高到低只列出实现目标所需要做的最重要的三件事。 在最重要的三件事都完成之后，如果暂时没有达到目标，就再重复分解剩下需要做的最重要的三件事，如此反复，直到目标达成。 第5步：每天都做一些接近自己目标的事情 当我们开始脚踏实地、一件一件地做关系到目标完成的事情，并且能够看到成效的时候，我们就会感到满足、愉悦和信心满满，从而投入更多的精力和时间在其中。在执行一段时间之后，就会发现事情一件接一件地完成了！ 随时应用80/20法则 要把80/20法则应用在时间管理中，我们就需要随时问自己这些问题： ◎ 这个工作是属于20%高价值的部分呢？还是属于80%低价值的部分？ ◎ 对自己需要做的工作，我是否抵御住了先易（低价值的工作）后难（高价值的工作）的诱惑？ ◎ 自己是否应该做一些减法？把目前工作中属于80%低价值的部分减少一些，从而增加做另外20%高价值工作的时间？ 创造大块时间 固定时间法 每天固定时间做固定的事情，养成气场 减少被打断 主动通知其他人不要打扰，例如在即时通信工具中设置状态为“正忙”；或者切断干扰源，例如把手机设置为静音状态，从而不间断地充分利用大块时间进行高效工作。 每日时间分区法 需要先摸索找到自己的区间：记录-统计-执行 遇到“不服管”的员工怎么办 运用技术领导力4D框架，来应对“不服管”的团队成员。 团队管理者内心坚持“每个人都是不错的”信念 运用教练思维 建立亲和与信任感 需要在解决具体的“高难度”的“事”之前，从最重要的“人”出发，建立亲和与信任感！ 建立亲和与信任感的管理工具1：工作之外的背景介绍。 心理学研究表明，在影响信任感建立的因素中，相互之间的了解是很重要的。信任感建立在一定的相互了解基础之上。团队领导者和团队成员之间信任感的建立，也必须在一定的了解之后才会开始。而促进相互了解最重要的手段，就是对双方工作之外的个人背景进行了解。 团队领导者和团队成员就工作之外的个人背景进行一些介绍和互动，例如自己的家乡、毕业的学校和专业、第一份工作、之前工作过的公司、爱好、家庭情况、个人的有趣经历等。 建立亲和与信任感的管理工具2：勇于展示个人的不足 在第一次和新团队成员进行一对一谈话时讨论这个话题：“你能介绍你的三个优点和三个还可以做得更好的地方吗？我之后也会和你分享我自己的答案。” 我们已经通过相互分享工作之外的经历，了解了对方的一些背景信息，我想，我们第一次发现了彼此很多之前都没有想到的内容，比如我们发现学的是一样的专业。那么接下来是否可以进行一个更有趣的“冒险”，尝试向对方分享我们愿意分享的两个强项和两个弱点。 建立亲和与信任感的管理工具3：从绩效评估到建设性反馈 1．用“成长式思维”设定成长目标 核心思路一：面向解决方案。 核心思路二：充分利用“有力的问题”引发人的改变。 团队领导者和团队成员的沟通方式从陈述句（下达指令）变为疑问句（通过发问激发团队思考）。 一般来说，“有力的问题”往往有如下特征。 （1）简短，直接，切中要害。 （2）能鼓励被提问者打开话匣。“有力的问题”是开放式的问题（例如5W1H问题：What、When、Where、Who、Why和How），因而能够让被提问者有空间更好地展开回答，从而有更多的机会获取更多的信息，以及激发更多的创意和思路。 （3）能促使被提问者深入思考。一个出其不意的好问题往往会让被提问者一时语塞、沉默思考。 2．用建设性反馈助力快速成长 对于一位团队管理者来说，提供反馈的过程就是依据对事实的观察，将团队成员行为的影响或者效果以客观的方式提供给团队成员，以期对员工的行为产生影响（保持有效的行为或者改变无效的行为），从而达到改进绩效的目标。 在实践中提供“建设性反馈”可以遵循下面的五步“公式”进行： 建设性反馈 = 明确目标（“我希望和你讨论____”）+观察（“我观察到____”）+ 影响（“这么做的影响是_____”）+要求（“我期望今后你能_____”）+ 讨论（“你觉得呢？______”） 第1步：明确此次“建设性反馈”的目标 开门见山、言简意赅的“建设性反馈”的主题。 第2步：具体描述观察到的事实 建设性反馈最重要的基石在于具体的事实，所以在描述事实时应该尽量清晰地指出时间、地点，以及发生了什么。更重要的是，一定要使用第一手的观察，尽量少使用从其他人那里获得的观察，从而避免反馈和事实出现偏差。 第3步：阐述行为所产生的影响 所说的影响既包括行为所带来的可观察到的结果，还包括行为所影响的人的反应。 特别需要注意的是，这里的影响是一个中性词，既包括正面的影响，也包括负面的影响。 第4步：清晰描述期望的行为 从面向未来的角度清晰描述自己的期望，并提供切实可行的改进行为以达到目标的建议。 第5步：给对方机会阐述他的想法 如何处理冲突 了解产生冲突的原因 1）目标理解不统一 2）多种技术方案选型 3）多项目并行引起资源冲突 4）项目进度冲突 5）团队成员的情感因素 ◎ 个性不同：大家的沟通方式、方法差异导致沟通不愉快而发生冲突。 ◎ 团员间的偏见：表现为对他人的观点不赞同，甚至一言一行都看不惯，这样势必发生冲突。 ◎ 价值观不一致：表现为因经历不同、背景不同、观念差异而产生冲突。 正确看待冲突 在大多时候，大家都认为冲突只会产生不好的结果，但是世间事都有两面性，冲突同样有积极的意义。例如，上述“多种技术方案选型冲突”就可以通过技术讨论拓宽视野，弥补冲突各方的认知盲区。我们将冲突产生的积极意义归纳如下。 ◎ 暴露问题，及时熔断。 ◎ 促进了解，加快团队磨合。 ◎ 弥补不足，拓宽视野。 ◎ 产生竞争，培养主动思考能力。 ◎ 信息流动，引导创新。 ◎ 团队涅槃，完善管理。 处理冲突 管理者处理各种冲突的基本原则就是客观和公正。 1）强调目标和项目的意义，建立共赢意识 2）搁置冲突，冷处理 3）管理协调，双方妥协 4）建立制度，法治管理。 清晰定义了边界 5）职务介入，强制执行 利用经理权 如何对上管理 做好对上的预期管理 1.彻底理解需求 心态上，不要畏惧上级，要彻底弄明白上级想要什么。 2.学会站在老板的角度理解KPI，求同存异 老板说的不一定正确，基于KPI思考老板提出的要求是否合理。如果不合理，是不是最好不要当众指出老板的不是，可以私下讨论。 及时汇报 1.认真聆听。因为汇报也是一个沟通的过程，所以一定要认仔细聆听且理解领导的意思。 2.简单扼要地表达。在汇报前罗列好汇报清单，可以运用结构化汇报方法。 先总后分，结构化表述，汇报前自己先打草稿，汇报不记得我觉得可以翻看一下笔记也没问题。 3.客观描述，不要避重就轻。 把真实存在的问题反馈出来，纸是包不住火的，提早抛出问题，上级还可能有时间想其他办法，到最后时间才爆出问题，就无法挽回了。

• 

  郑同学

  推荐

  我们学的很多技术实现都逃不脱基础原理，不管是Java，还是其他语言，只要用TCP用的都是相同的原理，逃不出范围，只要抓住原理，举一反三，时间一长了，甚至还可以自己推导答案。 对于技术的基础，我会把其它成四类： 程序语言：语言的原理，类库的实现，编程技术（并发、异步等），编程范式，设计模式等。 系统原理：计算机系统，操作系统，网络协议，数据库原理等。 中间件：消息队列，缓存系统，网关代理，调度系统 等。 理论知识：算法和数据结构，数据库范式，网络七屋模型，分布式系统等。 有了这些基础，学新的技术也就不会太难理解。