程序员职场晋升：与阿里前 P9 的一次近距离互动

程序员职场晋升，想必是很多技术同学想要了解的内容：晋升遵循怎样的路径？怎样才能顺利晋升？晋升时要注意哪些坑，又有哪些技巧？……

博文视点“解惑杂优铺”栏目邀请到畅销书《互联网大厂晋升指南：从 P5 到 P9 的升级攻略》作者李运华老师来进行了一场“从程序员职场晋升直播课，与阿里前 P9 的一次近距离互动”的主题直播访谈，希望可以解答小伙伴们在晋升道路上的一些疑问。

李运华老师，阿里前资深技术专家（P9），有 16 年的软件设计开发经验，曾就职于华为、UCWEB、阿里巴巴、蚂蚁金服，承担架构设计、架构重构、技术团队管理、技术培训等职责；专注于开源技术、系统分析、架构设计，对互联网技术的特点和发展趋势有较深入的研究和理解，先后负责过阿里游戏异地多活、飞鸽消息队列、交易平台解耦、蚂蚁国际澳门钱包等项目，对于高性能、高可用、业务架构、系统解耦等方面有非常丰富的经验。同时，李运华老师也是《编程的逻辑》《从零开始学架构》《互联网大厂晋升指南》3 本书的作者。

Q：可能有很多小伙伴对大厂的职级体系还不够了解，老师先来介绍一下大厂的职级体系吧~~

答：我先简单介绍一下自己的经历吧，因为可能大家对我个人的经历也比较感兴趣。

为什么我能够写《互联网大厂晋升指南：从 P5 到 P9 的升级攻略》这样一本书，也和我的工作经历有关！

工作经历的话，04 年到 09 年是在华为，10 年开始在 UC，直到 UC 被阿里收购，后来一直在阿里，18 年转岗到蚂蚁金服。我在这三个公司都经历过职级的定级和评审。

我刚在华为的时候，华为的值级还不是现在的 13、14、15、16、17 这种，是 T1、 T2、 T3、 T4，然后每一级有 a、b、c、d 四等。但是那个时候刚定完级别我就走了，我都忘了我当时是什么级别了，好像因为刚毕业四五年左右定了一个 T2-b 还是什么。我走了之后，华为改成了 13、14、15、16、17 这种。

后来去了 UC，UC 虽然是一个创业公司，但也有自己的一个职级体系，也是用 T1、 T2、 T3、 T4，然后每一级分 a、b、c 三等。后来被阿里收购后也是 P5、P6、P7、P8 这种等级。

所以，我个人职业生涯经历过的这几个公司都有职级体系，我有机会去接触不同的职级体系，以及不同职级体系里面会有一些怎样的玩法，甚至说有一些什么样的技巧或潜规则之类的。

另外，我自己晋升还算是比较顺利的。我主要是在 UC 和阿里晋升的，从 UC 的 T2-a 一路晋升，并到阿里之后从 P7 晋升到 P8，从 P8 晋升到 P9，整体上来说都是比较这个顺利的。

后来带团队，我又指导了我的一些下属晋升到 P7、P8。后来因为我晋升到了 P9，所以就作为晋升评委去评 P6 升 P7 和 P7 升 P8。

在做晋升评委的时候，实际上有很多机会去跟其他部门、其他业务线，甚至其他背景的评委一起来考察这个申请者，所以也会有更多的视角去看大家怎样去理解晋升，怎么去判别晋升。所以，在这一块我自己形容自己是球员、教练和裁判都做过。

简单地给大家讲解一下我在晋升这一块的经验。

互联网行业现在比较常见的两个职级体系：一类是阶梯式的，以腾讯为代表，腾讯以前是 T2.1……T3.1……T4.1……腾讯后来改了一次，改成 T6、T7、T8、T9……但实际上都是换汤不换药，本质上都是阶梯式的，也就是说两个级别之间的这个差异是比较小的；另外一类是比较典型的跨越式的，就是阿里这种职级，包括百度、滴滴也是类似的，以阿里为例，就是 P5、P6、P7、P8、P9……这种职级的 P6 和 P7 的差别就比较大，这就是为什么叫跨越式，因为你可能要花很大的力气才能从一个级别晋升到另一个级别。

所以目前来说，互联网行业主要是阶梯式和跨越式这两种职级体系。

但是你要问哪一个更好的话，我个人觉得在实际操作过程中，其实阿里的这种体系更合理一些，而且现在阿里的这种职级体系基本上也是行业的硬通货，基本上大家问你是什么级别的时候，你说一个公司的级别，面试官可能对你们公司的级别不太了解，他就会问你对标到阿里是哪个级别。

其实现在稍具规模的公司都有晋升体系，所以大家也不要觉得自己在“中厂”是不是就没有机会了。自己可以看一下公司的一些规章制度和规范。

Q：晋升时需要通过哪些“关卡”，哪个关卡最重要？

答：这里大概来跟大家讲解一下这几个晋升的关卡，每个关卡里面的重点事项。

首先，这里说的是我经历过的最全面、最完整的流程，当然如果你们的公司为了一些晋升效率，可能会进行一些裁剪或者合并，这也是可能的。这就需要自己去看一下公司的规定。

通常情况下，晋升要经历提名、预审、评审、复审、审批和沟通这 6 个阶段。

听起来很多，但大家不用担心，其实你自己真正要参与的其实就两个阶段。

我先每一个阶段都介绍一下，它是干什么的，你在里面要做什么事情。

提名阶段，就是团队或者你自己去提名，提名可能要满足一些标准跟要求，比如你的绩效、工作年薪、能力要求等等。在这一步，如果你是自主提名，或者主管说让你准备晋升，那么可能你要写个提名词。那么，怎么写提名词呢？提名词不是写一篇文章，而是可能就 200 字以内，你要把晋升的理由讲出来，那这里面其实是有非常多的技巧的。

这是第一点，第二点大家注意是主管是可以提免你晋升的。如果你的绩效一般，但是主管觉得达到了晋升的话，也是可以提名的。这里就有一个大家注意的事项了，平时很多人都说这要跟主管关系好才行，这个观察肯定有一定的偏颇的，但是如果你跟主管的关系非常差，那我可以很明白地告诉你，你的晋升确实会受影响！

有人的地方就有江湖，大家为了自己的前途不要把和主管的关系搞得太差，毕竟在提名阶段他就可以卡你了。但绝大部分主管不会为了个人恩怨来卡你，因为主管自己也希望带领团队做出绩效和价值。

预审阶段，其实就是部门内拉通。每个小组都会提名，大家疯狂地提名，那是不是都去晋升呢？那肯定不行，因为每年晋升都有一定的限额。不是你想提谁谁就去，结果一面评发现明显不行，那这不浪费大家时间吗？所以就有预审这么一个步骤。

预审其实就是部门的大佬（P8、P9、P10 的几个大佬）一起讨论一下这个名单，看一看有没有哪一个不合适。那这些大佬怎么知道哪个人合适哪个人不合适呢？这其实就是根据他平时各种渠道了解到的一些信息，比如你某一次开会表现很积极，或者某一次处理问题很积极，有个大佬可能看到或者听到了。当然如果你哪一次跟别人发生了激烈的争执，然后别人去投诉了，那大佬当然也知道了。这里其实就想提醒大家，在职场里还是要考虑合作共赢，尽量不要引起矛盾；另外就是平时大家还是要善于表达和表现自己，这不是说去演戏，而是说你不要以为我把这个事情做好了就可以了，老大自然就知道了，这个其实不太可能的。比如我之前下面管理的人可能有将近 100 个，每一个人我都很清楚也很难。

评审阶段，你要写 PPT，写完 PPT 去答辩，答辩的时候你讲 PPT，然后问答，可能是 3 个评委或者 5 个评委，然后评委根据你的答辩情况决定你通过还是不通过，这就是评审阶段。

复审阶段，就是你答辩完了，已经不关你的事情了，整个部门甚至整个公司一起来看一下，今年的通过率会不会太高了，或者今年的通过率会不会太低了，这里就涉及大家经常说的运气。今年如果都很牛，公司又有限制说你不能晋升那么多，那有的人能力稍微比别人差一点的可能就晋升不了了。这也是晋升里很大的一个运气因素。

有公司的通过率指标，也有部门的通过率指标，你们部门今年晋升了几十个，别的部门才晋升十几个，那肯定要把你们部门的刷一刷。

审批阶段，最后名单都确定了，公司大老板决定怎么发钱，有的年份公司绩效好可能多发一点，有的年份可能公司绩效不好，可能就少发一点，这也是跟运气相关的，你也控制不了。

沟通阶段，就是结果出来之后，你的主管和 HR 要找你沟通。如果通过了，为什么通过了？还有哪些需要改进的？如果不通过，原因是什么？接下来应该怎么做？

所以，要完成晋升对于公司来说，全流程投入的人力还是挺多的，但是对于个人来说，基本上只要搞定提名、评审阶段。

总体来说，肯定是评审阶段对你是最重要的！

但是一定要注意，不是说你把评审阶段搞好就行，提名、预审、评审其实都是你平时工作的一个体现，不是说我平时什么都不关心，就希望把 PPT 写得非常漂亮，然后一下子就通过了，这个是很难的！

Q：什么样的人更容易晋升？

答：其实很多同学如果没有经历过晋升的过程，或者是说自己可能参与了晋升，但是对于晋升的全貌不了解的话可能会有比较多的误区。

我先说误区吧！很多同学的第一个误区就是觉得技术能力越牛越好，要天天去刷 LeetCode、刷数据结构和算法、看源码之类的，我的能力越强，晋升越容易。这是一个非常大的误区！

实际上，不管是站在企业的角度，还是站在团队的角度，都不会因为你天天花时间研究数据结构、算法、源码就给你晋升，这样的话最后就没人干公司的活儿了。

所以，晋升的首要原则是一定要为公司带来价值！你做的事情一定要为公司或团队创造价值，比如你做的这个业务效果很好，为公司降低成本、提升效率、提升质量等。

第二是主动原则！很多人觉得我只要把自己事情做好，把自己的能力提升了，主管肯定会看到，尤其是技术人都比较腼腆，比较崇拜技术，不喜欢表现，认为金子在哪里都会发光的，酒香不怕巷子深。这些都是错误的认知！

你要主动去寻找和抓住有利于晋升的机遇。因为主管的风格有很多种，并不是每一个主管都会关注团队人员的成长和晋升的。应该主动去跟主管沟通，或者主动去抓住机会，提升跟工作相关的能力，而不是等着主管来安排，等着机会砸到自己身上！

当然，这对大家的要求就会高了。什么时候找主管？你是不是天天找主管？那也不行！需要你有更多对团队、对业务的理解，对上下游的理解，能够主动识别出哪些地方有机会、哪些地方有困难，然后你能够针对这些机会、针对这些困难做好准备，机会来临的时候，你跳出来说“我可以做这个”……

第三是成长原则。就是不管做什么事情，一定要想着自己的能力要有成长，包括你的业务能力、技术能力、沟通能力、团队管理能力……不要老是说“哎呀，我就拿 1 万块钱工资，反正我就做这么多事情，对得起这些工资就行了”，你如果抱着这种态度的话，可能感觉自己心里很爽，但是长期来看，对自己是得不偿失的……

一定要想着我做这些事情，除了赚这份工资以外，还一定要积累经验提升自己的能力，就算是我的能力在当前这个公司、当前这个团队得不到发挥，得不到回报，那我也有这个底气去其他地方，找到属于自己的机会。

Q：在晋升时，评审团如何判断我有没有达到晋升标准呢？

答：评委为什么认为有的人可以晋升，有的人不能晋升，背后的逻辑是什么？

我知道之前很多同学可能有一些误区，会觉得这个人特别会说、PPT 写得很漂亮、讲话口若悬河，所以他晋升了。但其实这些都不是决定性因素，也不会成为一个关键性因素。

也有的同学会说，“那个人的绩效还不如我，我的绩效比他好，为什么他晋升了，我没有晋升呢？”这其实就是第二个误区！

所以，关于什么样的人在评审（就是面评的时候）会通过晋升，其实背后是有个逻辑的，我把这个逻辑整理成一句话，就是你在当前级别把下一级别的事情做好了，你就可以晋升！

所以，你不要觉得我是个 P6，我怎么做的事情跟 P7 一样，我是不是吃亏了？这个时候你应该要感到高兴才对，说明主管已经在安排机会给你锻炼了。你在 P6+的时候做的跟 P7 的事情一样，做好了之后，拿到了绩效再去晋升，评委会看你做的这个事情是不是真的能符合 P7 的能力要求。

那 P7 有什么样的能力要求？我在《互联网大厂晋升指南：从 P5 到 P9 的升级攻略》这本书中总结出了一个模型：面相复杂度的多维度模型。

不同的技术、不同的业务、不同的管理的复杂度是不一样的，能力要求也不一样。

多维度就是技术、管理和业务这三个维度，你的级别不同，这三个维度的要求是不一样的。

所以，评委会根据级别本身的要求以及你做过的事情能不能匹配这个级别的要求，来评判是否可以晋升。

Q：在晋升的时候，不同级别的 Title 可能听起来会比较抽象，比如，“工程师”“高级工程师”“专家工程师”，那这个“高级”具体高级在哪里呢？我怎么把这种抽象的字眼转化成具体技能做更有针对性地提升呢？

答：我还是以阿里的职级为例解读一下 P5 到 P9。

P5 到 P6，用一个关键词来总结，叫工匠！工匠的核心任务是完成任务！

那 P5 跟 P6 的区别是什么？

P5 可能还不能独立完成任务，还有一个师傅带着；P6 就是独立完成任务了。

那 P5 跟 P6 的核心要求是什么？专业能力！

P7 到 P8，用一个关键词来总结，叫指挥！

大家想想一个交响乐团为什么要有一个指挥？指挥的目的是什么？

指挥团队大家来合作协作，一起把大的任务完成！

所以，你想晋升到 P7、P8，要想想自己有没有真正指挥过……

P9 到 P10，是导演！

那导演跟指挥有什么区别？指挥是拿别人的乐谱来演奏，指挥是不需要自己创作这个乐谱的，导演很大程度上决定了这个作品是否优秀，导演定目标和基调，决定一些关键的事项、想创造一个什么样的作品。所以 P9 跟 P10 的要求就更高了！

实际上，每一个级别具体的要求就比较多比较细了，大家有兴趣的话，可以看一下《互联网大厂晋升指南：从 P5 到 P9 的升级攻略》这本书。

Q：是不是 PPT 做得好就容易晋升？

答：首先，是不是 PPT 做得好就能够晋升呢？

那当然不是的！

我见过很多 PPT 做得很好的，结果一面评发现完全不是那么回事。

我们就怀疑这个 PPT 是不是主管教他这么写的。为什么这么说呢？因为这个 PPT 写的重点和调理都很清楚，但是我们在面评针对 PPT 里面的内容去展开问的时候，很多东西他都答不上来。

当然，PPT 本身如果是你自己写的，而且又写得好的话，那确实有助于晋升。

很多技术同学觉得 PPT 是耍嘴皮子功夫、是表面功夫，甚至有的同学不屑一顾，总觉得我的代码写的好就可以，但是你要知道晋升的时候没办法看你的代码，所以大家一定要注意写 PPT 并不是一个耍嘴皮子的功夫。

同样一件事情，不同的人写出来，PPT 的内容就是差异很大的；同样一个 PPT，不同的人讲出来的东西也是差别很大的，那背后的逻辑是什么？

大家一定要注意，PPT 其实就是要你把你做过的事情的逻辑结构、关键点背后的原因讲出来、总结提炼出来。

能把 PPT 写好说明你本身的逻辑、思维都是清晰的。

讲 PPT 其实基本上就是把你写的过程中的逻辑展现出来。这里有很多技巧，比如说金字塔原则、STAR 原则，大家有兴趣可以自己去查一查。

评委也是针对 PPT 上的内容来提问，或者是由 PPT 上的内容展开来提问的，所以 PPT 这一块大家一定要重视！

如果你马上就要晋升了，有没有技巧来尽快提升你的质量呢？

就是模拟面评！写完之后首先自己对着屏幕讲 3 遍，看一下哪里会卡住，时间用了多少，自己觉得讲得很顺之后，再拉上你的主管或者同事到会议室里，给他们讲一下，让他们问你一些问题，通过他们的视角帮你完善这个 PPT 和一些问题的答案。

Q：晋升答辩的时候，是不是答得越多越能展现自己能力？

答：其实不是！就像前面讲的，并不是说这个人特别会说就可以。

评委随便问一个什么问题，他都能说 5 分钟，评委最怕这样了，为什么？

第一，答辩的时候，评委要考核的东西是不少的，但是答辩的时间是有限的，一般来说答辩大概就 30~50 分钟，如果一个问题说 10 分钟，评委总共能问的问题就少，怎么综合来看你的能力呢？所以不要以为说越多越好！

第二，评委并不要求你把每一个问题的代码细节给他背出来。我们考察的时候，其实就看你有没有把握住这个地方的关键点，你把这个关键点讲清楚了，我们基本上就认为你已经掌握了，也不可能让你现场去写代码。如果评委还有兴趣展开的话，那他继续问你继续答就可以了！

大家注意，在真正回答问题的时候也是有技巧的，你要明白问题的分类有什么，不同的问题，答的时间不一样，答的内容也不一样，具体每一类问题答什么，大家可以详细看一下《互联网大厂晋升指南：从 P5 到 P9 的升级攻略》这本书！

这不是我一个人的经验总结，都是综合我多次评审过程中，和我合作的、不同背景的评委，总结观察发现的一个共性！

Q：为什么答辩感觉很好，结果却还是没通过？

答：这是有可能的。

你觉得答辩还好，但最后结果没过，这里有几种情况：

第一种就是你可能自己答得很嗨，但都是答非所问或者没有答到重点！

第二种就是你自己觉得自己答得好，实际上你答得并不好。就是我刚才说的，你滔滔不绝地答了很多，有的评委可能比较累了，会比较烦了，他就懒得让你再答，结果一场面试下来，就答了三四个问题，评委也不知道你能不能过。

第三种就是跟运气相关了，就像在前面介绍的，在晋升流程里的复审阶段，部门或者公司要把所有的晋升数据拿过来看一下，根据晋升通过率把一批人给刷下去。

所以晋升的时候也确实有很多不确定性的因素，大家如果第一次晋升没通过，也不要灰心，也不要气馁，有可能是运气的原因。

Q：最后，老师还有没有一些忠告想要给大家？

答：第一，现在整体来说大环境不太好，面对这种外部大环境的不可控，还是要更多关注于自己内在的能力提升，这样在潮水来的时候大家都能浮起来，潮水退去之后，能力过硬的人才能够更好地生存，找到更好的机会！

第二，因为每次都有同学问我，所以今天统一跟大家说一下：未来 10~20 年国内的技术趋势，大家把握三个关键字——数字化、国产化和云原生！

大家可以在这三个方面积累一些经验、提升自己的能力，尝试去抓住一些机遇。

最后，祝大家早日晋升！

……

更多精彩内容尽在李运华老师的著作《互联网大厂晋升指南：从 P5 到 P9 的升级攻略》一书中，欢迎大家阅读此书了解关于晋升的更多内容！

▊《互联网大厂晋升指南：从 P5 到 P9 的升级攻略》

李运华 著

• 从 P5 到 P9 的升职秘籍

• 实用的职场晋升技巧

• 19 个高效工作和学习方法

• 完整的职场晋升路线

• 
  

本书主要介绍了一套系统的晋升方法论，涵盖“理解晋升→准备晋升→参与晋升→获得晋升”这条完整的晋升链条，深入剖析了晋升背后的规则、“潜规则”、技巧和套路，帮助读者找到正确的发力点，顺利通过晋升，获得更好的职业发展。

（扫码了解本书详情！）

李运华老师其他著作

▊《从零开始学架构：照着做，你也能成为架构师》

李运华 著

• 自成一派的架构设计方法论

• 教你体系化的架构设计技能

架构设计是技术人员成长和晋升过程中必须掌握的技能，但目前业界缺乏架构师学习和培养方面体系化的知识和实践的指导，本书结合作者多年在架构设计方面的学习、思考、实践，提出了完整的一套架构设计方法论，包括什么是架构、架构设计的目的、架构设计原则、架构设计流程、架构设计模式和技巧、互联网公司技术演进等内容。这套架构设计方法论适合不同行业，比如互联网、企业应用等；也适合不同的技术领域，比如后端架构设计、前端架构设计、客户端架构设计、测试平台架构设计、运维平台架构设计等。

（扫码了解本书详情）

▊《编程的逻辑：如何用面向对象方法实现复杂业务需求》

李运华 著

• 剖析面向对象本质

• 落地面向对象技术

• 梳理面向对象流程

• 实战面向对象案例

本书系统地讲述了面向对象技术的相关内容，包括面向对象的基本概念、面向对象开发的流程、面向对象的各种技巧，以及如何在实际开发项目中应用面向对象技术进行设计和开发。在讲述相关知识或技术的时候，除了从“是什么”这个角度进行介绍外，更加着重于从“为什么”和“如何用”这两个角度进行剖析，力争让读者做到“知其然，并知其所以然”，从而达到在实践中既能正确又能优秀地应用面向对象的相关技术和技巧。

（扫码查看本书详情！）

更多相关图书

▊《程序员修炼之道：从小工到专家》

[美] 亨特（Andrew Hunt），[美] 托马斯（Daid Thomas） 著

马维达 译

• 全球票选程序员读物

• 常读常新的不老神话

• 从开发到架构注重实效永不过时

• 一本被所有编程翘楚力荐过的书

本书由一系列独立的部分组成，涵盖的主题从个人责任、职业发展，直到用于使代码保持灵活、并且易于改编和复用的各种架构技术，利用许多富有娱乐性的奇闻轶事、有思想性的例子及有趣的类比，全面阐释了软件开发的许多不同方面的较佳实践和重大陷阱。无论你是初学者，是有经验的程序员，还是软件项目经理，本书都适合你阅读。

▊《程序员修炼之道：通向务实的最高境界（第 2 版）》

[美] David，Thomas（大卫托马斯），Andrew，Hunt（安德鲁亨特） 著

云风 译

• 《从小工到专家》重磅新版

• 雄踞“全球程序员至爱书单”顶端

• 开发新兵走向卓越领袖

本书之所以在全球范围内广泛传播，被一代代开发者奉为圭臬，盖因它可以创造出真正的价值：或编写出更好的软件，或探究出编程的本质，而所有收获均不依赖于特定语言、框架和方法。时隔 20 年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的最佳实践及重大陷阱，以及易于改造、复用的架构技术。本书极具洞察力与趣味性，适合从初学者到架构师的各阶层读者潜心研读或增广见闻。

▊《程序员的自我修养：链接、装载与库》

俞甲子，石凡，潘爱民 著

• 网易云风力荐:莫到用时再读书!

• 俯瞰程序前世今生，参透代码如何变成程序在系统中运行

• 透过系统软件底层形成机制走进程序世界，探索深层次的自己

• 畅销 13 年，经久不衰

本书主要介绍系统软件的运行机制和原理，涉及在 Windows 和 Linux 两个系统平台上，一个应用程序在编译、链接和运行时刻所发生的各种事项，包括：代码指令是如何保存的，库文件如何与应用程序代码静态链接，应用程序如何被装载到内存中并开始运行，动态链接如何实现，C/C++运行库的工作原理，以及操作系统提供的系统服务是如何被调用的。每个技术专题都配备了大量图、表和代码实例，力求将复杂的机制以简洁的形式表达出来。本书最后还提供了一个小巧且跨平台的 C/C++运行库 MiniCRT，综合展示了与运行库相关的各种技术。

▊《程序员的底层思维》

张建飞 著

• 揭秘软件设计背后的 16 种底层逻辑与思维能力

• 大厂资深程序员修炼之道与思维秘籍

• 
  

本书涵盖程序员应知应会的 16 种思维能力，共 18 章，分为三部分。第一部分主要介绍抽象思维、逻辑思维、结构化思维、批判性思维、维度思维、分类思维、分治思维、简单思维，以及成长型思维等解决日常问题的基础思维能力。第二部分结合软件行业的特点，主要介绍解耦思维、契约思维、模型思维、工具化思维、量化思维、数据思维，以及产品思维等专业思维能力。第三部分主要是对上述思维能力的综合运用实践。

▊《技术人修炼之道：从程序员到百万高管的 72 项技能》

黄哲铿 著

• 全方位讲解 IT 技术人技能首著

• 72 项核心技能，50 多位一线从业者及作者近 20 年经验总结

• 全面升级个人底层操作系统

• 突破职业瓶颈实现职场跃迁

• 12 位高管及领袖力荐

本书旨在帮助 IT 技术人员提升职场核心技能、架构思维、团队管理能力、商业认知，让每一位普通的技术从业者，修炼成为“技术职场超级个体”，通过全面升级个人的底层操作系统，突破瓶颈，实现职场跃迁。

▊《卓有成效的工程师》

[美] Edmond Lau 著，万学凡，顾宇 译

• 原著风靡全国被誉为工程师世界的《原则》

• 人气极高的 Quora 创始人（MIT、斯坦福客座讲师）神作

• 用杠杆率神奇工具将数字时代人的效能放大十倍

本书介绍一个强大的框架——杠杆率，用来推断、分析工作的有效性与影响力，研究并说明如何成为一名卓有成效的工程师。更为重要的是，本书提供了一系列可落地且经过验证的策略作为框架的补充，读者可以立即应用这些策略来提高工作成效。

本书的内容分为三个部分，第一部分阐述提高成效的思维模式切入；第二部分深入探讨持续提升执行力及取得工作进展的关键策略；在第三部分，作者转换角度，阐述了创造长期价值的方法。通过阅读本书，读者能够获得思维启发和高价值的实践经验，成为卓有成效的工程师，并打造高效的软件工程团队。

▊《匠艺整洁之道：程序员的职业修养》

[美] 罗伯特·马丁（Robert C.Martin） 著，韩磊 译

• 鲍勃大叔封山之作

• 向着软件匠艺的“北极星”前进：达到了解如何写好代码的境界

• 关于应用五项核心纪律的实用且详尽的指导：测试驱动开发、重构、简单设计、协同编程和验收测试

• 开发者和团队如何提升生产力、质量和勇气

• 程序员们精诚一致的真正意义，以及每位软件专业人员都该给出的十条具体承诺

本书共分三部分，前两部分用实例阐释 TDD 在敏捷软件中的运用，以及验收测试、协同编程等常被忽视的敏捷侧面与具体策略，还探讨了颇有价值的软件设计方案相关话题；第Ⅲ部分拔地而起，直接提出十条堪称金玉良言的“规劝”，以帮助程序员成为团队基石。

本书适合所有软件开发者、测试工程师及工程类院校师生，对技术团队负责人及架构师同样大有助益。

▊《架构整洁之道》

[美] Robert C. Martin（罗伯特 C.马丁） 著

孙宇聪 译，鄢倩 校

• 整洁之道再续新篇

• Bob 大叔封山之作

• 熔举世热门架构于一炉揭通用黄金法则以真言左耳朵耗子|余晟倾情作序

Martin 在《架构整洁之道》中远不只是在为我们提供选项，他几乎是在将软件世界中横跨半个世纪的各种架构类型的经验倾囊相授，目的是让读者既能阅尽所有架构选型，又可通晓其如何决定成败。Martin 也的确不负厚望，本书中充满了直接而有效的解决方案，以供读者应对自己面临的真正挑战——那些或最终成就或彻底破坏项目的挑战。

▊《代码的艺术：用工程思维驱动软件开发（双色精装版）》

章淼 著

• 提升软件工程能力大成之作

• 涵盖代码、文档、项目管理和实际案例解剖

• 百度技术学院【官方用书】

• 清华、IT 名企精品课指定用书

• 附配套教学视频，作者在线答疑

本书是作者围绕软件工程能力所做的系列培训的内容汇编。这些内容来源于作者 20 多年以来对软件工程的学习体会和项目实践，以及对中国工业界软件工程师的观察和教育实践。

▊《软件开发的 201 个原则（精装版）》

[美] Alan M.Davis 著

叶王 等 译

• 罗振宇推荐，原著亚马逊 4.5 高分，豆瓣 9.7 分

• 首本实现轻阅读的研发字典书

• 用【简单原则】讲透软件研发重要思想

• 百度学院指定用书

• 掌握方法，效率提高不止 100%

本书汇总了软件工程原则。原则是关于软件工程的基本原理、规则或假设，不管所选的技术、工具或语言是什么，这些原则都有效。

全书共 9 章，第 1 章为引言，后面 8 章将 201 个软件工程的原则划分为 8 个大的类别：一般原则、需求工程原则、设计原则、编码原则、测试原则、管理原则、产品保证原则和演变原则。

书单好书任你选

按以下方式与博文菌互动，即有机会获赠以上任意一本图书！

活动方式：关注下方“博文视点 Broadview”公众号，在后台回复“书单抽奖”参与活动，届时会在参与的小伙伴中抽取 3 名幸运鹅！