第四章：高手修养

上升通道：技术路线和管理路线

如果你待在一个做产品的公司，它一定会给你技术、管理两条晋升通道，无论公司是大还是小；如果你待在做项目的公司，也就是小商品工厂，它可能就不太需要专研技术的人才。有了这个认识后，根据自己的情况选择合适的公司。

业务上的精进

预见未来：软件工程师要有前瞻能力

这个阶段不管是宏观规划上还是细节上，你都能够掌握，这就是所谓的融汇贯通。

前瞻能力：指你得知道为什么系统今天是这个样子，以及未来他会朝着什么样的方向去演进。例如2011年特火的一个APP软件里有各种滤镜贴纸来换脸，当时火爆全球。你一定要有知识的广度，需要去读论文，去各公司做广泛交流，保证有足够多的不同的信息进入你的视野；多做跨行业的交流，跳出自己的圈子，跟其他行业人交流。

权衡利弊：软件工程师要有取舍能力

关键在于1.目标明确：最终目标就像一把尺子，是衡量最优方案的唯一标准；2.学会预测：建议你多总结行业内的历史，关注10-20年发生的事就可以。只有你知道历史的轨迹，才更容易知道未来在哪里

攻克难题：主动寻找技术难题并尝试不同的解决方案

技术难题有时候需要自己去找，这对自己能力的提升有很大帮助，在攻克技术难题时，想法设法尝试不同的方案是最重要的。

关键决策：技术选型的六大要素

宏观层面：1.看这项技术解决的是不是大问题。（格局更大的问题，比如C++解决的是C语言的一些问题，而Java则以颠覆者的角度解释了C/C++的很多问题）；看这项技术解决的方式是否让人有想象空间，比如智能手机、AI技术的想象力就很大。

微观层面：看有没有大公司撑腰；看有没有很好的技术社区；看有没有杀手级应用，已为这项技术有颠覆性，如Java的杀手级应用WebSphere、Spring等；看有没有经历10年以上时间，十年是一个成熟技术产品的成长周期，这个时间是跨越不了的。

代码评审：不是“做出来”，而是“做漂亮”

作为一个没有参与代码编写的人，从头到尾把别人写的代码审一遍，看有没有需要改进的问题。“时间不够”“需求总变”不是拒绝评审的理由。如果业务逼得紧，让技术人员疲于奔命，那应该是需求管理和项目管理的问题；需求总变，我们更应该做代码评审，因为需求变得更快，对代码质量的要求越高。

评审清单：代码评审怎么做？

设计：代码是否经过精心设计并适合系统？

功能：代码是否复核开发者意图？代码对用户是否友好？

复杂性：代码是否可以更简洁？

命名/测试/注释/风格/文档等

评审误区：代码评审是为了找Bug吗？

代码评审有比找Bug更重要的价值，审查更高一级的代码质量，包括代码可读性、可维护性、可重用性，程序逻辑以及对需求和设计的实现等。找Bug有专门的环节负责，比如单元测试、功能测试、性能测试、回归测试等，不需要等代码评审环节才做。

千万不要等大厦盖好了再去评审，而是当有了地基、有了框架、有了房顶、有了门窗、有了装修的时候，循序渐进地评审，这样反而更有效率。

带团队的心法

实力服众：工程师宁愿被lead,不愿被manage.

这个行业对管理者的独特要求在于，你的技术足够牛，如果不能证明你有一定的技术水平和素养，下面的同学就不会服。有点像武林，你的武艺高强，才能领导大家，文弱书生相当领袖，基本不可能。

敢于放手：从工程师变成管理者

之前你想的是怎么让自己变得更好，现在你要做的是怎么让其他人做得更好，怎么让团队变得更好。你要给团队指导方向，告诉大家哪些该做、哪些不该做，哪些要坚持，并让下面的同学能够理解这样做的原因，用软件工程师能够理解的方式说服他们。

善于说服：相对于下指令，还是要讲道理

软件工程师最反感的事情是你让她做一件事情，却不能说明为什么。软件工程师都是自恃为专业人士，分配任务时你得告诉他背后的原因和道理，某种程度上，你得说服他。

招聘面试：考察一个人的元能力

看工作简历之外更重视一个人的元能力，看他工作过程中沉淀出了哪些基本素质，哪些可以持续拥有的能力。比如系统设计、代码的结构化，通过分析找到关键问题。元能力是软件工程师最底层，也是最核心的能力。元能力强的人，在设计开发的工作中自然不会差。

员工激励：让工程师更有成就感

对软件工程师来说，成就感不单单来源于独立完成一个项目，而是能够做特别牛的事情，做开创性的项目，或在行业内取得含金量极高的奖项。重要的是作为管理者，你要有这个意识，你可以结合自己所在公司和领域的情况，来给团队成员创造可以获得成就感的机会。

团队建设：做好人才布局。

管理者需要对每个下属的诉求以及长处、短处有判断，每个人适合干什么，不适合干什么，判断之后给每个人选择一个赛道，你心里要清楚，每个人未来的职业通道是成为一个专家架构师，还是成为技术管理者，把每个人放在合适的位置上。

布局长远：关注长期目标

管理者要判断，哪些事情需要长期投入，做了之后能产生规模效应。管理者要坚定不移地投入到长期目标上，因为眼前地事太多了，一不小心，长期地项目就半途而废了，这个坑太大了。

平衡需求：判断紧急与重要

作为技术管理者，如果照单全收，就会使团队长期处于应对的状态，你必须去判断，哪些事情是紧急的，哪些事情是重要的。管理者在这些重要的事情和紧急的事情之间做出平衡，这个事情做的好不好，很能体现一个技术管理者的段位和格局。

协同机制：保持公开透明的信息协同

如今一个大的互联网产品小的工作室模式根本接不住。技术体系的要求也比之前高了很多，需要团队进行大规模的协同，形成高质量的流程线，去把最终的功能实现。所以鼓励公开透明的协作，让大家把自己做的东西工具化、开源化，让所有人都能看到和试用就很重要。

团队合作：一加一大于二

拼车要想让乘客有更好的体验，很大程度上要依赖地图团队，只有当地图团队真正理解拼车的顺是怎么回事，才能解决拼车体验更优的问题

第五章：行业大神

丹尼斯·里奇：保持简洁

里奇是“C语言之父”，也是UNIX系统的联合发明人，他创造了几乎所有计算机软件的DNA，是为乔布斯等IT巨匠提供肩膀的人。为了提高通用性和开放效率，里奇发明了一种新的计算机语言：C语言。

为什么UNIX和C语言能够至今不衰，真正的原因不在于复杂而在于简洁，“保持简单和直接”，也就是著名的“KISS原则”.C语言共有9种控制语句，32个关键字、34种运算符，既有低级语言的实用性，又有高级语言的基本结构和语句。

林纳斯·托瓦兹：只是为了好玩

买回来之后发现Minix根本不好用，于是决定自己写一个替代系统。后来有人想给林纳斯1000万美元售后Linux,但他拒绝了，他选择让Linux一直保持开源的状态。林纳斯觉得比起有钱，让全世界的软件工程师一起成就Linux更有意义。（当时的软件：微软、甲骨文、IBM等政策都是保护软件的知识产权，即使在公司内部，也只有少数核心员工有权限访问软件程序的完整源代码。）林纳斯开源了Linux，让任何人都可以查看和修改源代码，发起了全世界软件领域的“开源运动”。吉多·范罗苏姆：允许不完美、保持开放

范罗苏姆并不是在一开始就追求完美，但足以满足大家的需求，同时一直遵循开放、开源的原则，吸引了大量优秀的软件工程师。这些软件工程师协同改进Python ,有很多核心部分的重大改变或者重构都是由他们提出并落实的。范罗苏姆说，Python是互联网上发展的语言，完全开源，由一群志愿者组成的专业的社区开发，他们充满热情，也拥抱绝对的原创权。

玛格丽特·汉密尔顿：拯救人类登月计划

1965年，玛格丽特担任阿波罗登月计划的软件编程部部长，负责制定一套应急预案，一旦飞船出问题，就启动这套预案。玛格丽特两次绝境之下化险为夷（阿波罗8号和11号），背后靠的就是制定规范、严格制定。他认为程序员需要理解错误，梳理错误的原因，并防止下一次出错，这在计算机“蛮荒年代”，需要一颗清醒的头脑来制定规范。

玛格丽特率先用了“软件工程师”来称呼团队里的程序员。在她的推动下，“软件工程”成了一门更规范、更系统的科学，我们现在程序员们，才有了“软件工程师”这个称号。

杰夫·迪恩：开创分布式系统

今天我们看到的整个云服务运作的分布式存储、分布式计算，以及一些硬件、网络技术，都是基于迪恩的这个方向产生、蓬勃发展的，把整个行业的认知提升到不一样的水平，从而推动整个行业的发展。

第六章：行业清单

行业大事记

推荐资料

书籍：零基础入门、正式入门、专业进阶（编程语言、理论学科、系统知识、软件设计）、高手精进

影视作品

行业术语：

宏观、编程、并发、数据库、错误、系统、工程、安全、其他