共计 6319 个字符，预计需要花费 16 分钟才能阅读完成。
咱们的中国文化，对“体面”看得特地重，所以你会发现身边到处都是高级 XXX，听着倍儿有体面，程序员也不例外。
然而你真要问每个人，你认为的高级 XXX 是什么样子的，预计每个人都有不同的答复。
我还记得在我刚开始从事编程工作的时候，对坐在边上不远的那位我心目中的高级程序员的印象是：
工作至多有 6、7 年以上，能写一个用起来很不便、看起来很牛逼、然而不太容易让高级人员看懂的框架。
前两天，我把这个问题丢到群里，大家给出的答案中，占比最高的是以下几个。
- 有 N 年以上编程教训（大部分都说 5 年以上）
- 有出版过技术图书
- 对某畛域内对罕用框架原理有理解，并且理论应用超过 2 年
- 能够随时随地疾速写出常见的一些算法
- 至多封装过一个被全局应用的开发框架
- 写进去的代码，浏览起来很好了解
- 能率领其余人员胜利实现我的项目
你看，这件事对大家来说就是常说的，“一千个人眼中有一千个哈姆雷特”。
不过这也失常，毕竟像高级、中级、高级这种高度形象的词汇，想要失去一个可形容的定义与人交换，必然须要夹杂着集体的主观因素。
然而很多行业都在这么进行分类，天然有它的情理和益处。
我感觉 其中最大的一个益处恰好是“主观”的附属品——弹性。
比方，我当初想招一位高级程序员，面试的时候不论是通过还是不通过，我都有理由来解释我对“高级”的定义。如此一来，我对陌生人的判断就有了更大的“弹性”。
这其实是面试官的一种权力，也是长期以来面试者总在面试中处于下峰的起因之一。
事物总是有两面性的，咱们在对陌生人弹性的同时，间接地也对外部的人弹性了，会导致外部的一些人才培养呈现问题。
比方，你感觉外部的高级程序员不够，心愿能在内部招聘的同时，从外部也造就一些进去。然而此时，你又面临了须要定义什么是“高级”的问题。
如果没法定义一个可能达成共识的规范，又如何领导造就的方向呢？只能是一句空话。
长此以往会导致更重大的问题：真正的高级程序员不够，只能让中级程序员顶上。顶替的工夫长了，会让一些中级程序员误以为本人曾经达到了高级程度。
在我平时的面试中，这样的案例不足为奇，网上流传的工作 10 年 = 1 年反复 10 次的段子是实在存在的。
上面我来聊聊我对“什么是高级程序员”的集体认识，欢送你和我一起探讨。
不论是什么行业，什么岗位，在这个高度分工协作的古代社会，所需的能力次要分为三个维度，我的了解大略是这样的：
- 业余能力：好奇心、敢于挑战艰难、刻意养成好习惯、要求严格
- 连贯能力：共同体意识、同理心、捕风捉影、接地气
- 领导能力：主人翁意识、沟通 / 会谈技巧、目标导向
先卖个关子，文章的最初我会将这三个维度组合起来，你会发现一片新的天地。
依据这三个维度的程度差别，咱们对高级程序员、中级程序员、高级程序员做一个简要的形容。
高级程序员 – 晓得有事要做
处在初级阶段的时候，咱们的精力大多只会专一在业余能力的晋升上。这个时候“领导能力”和“连贯能力”是很弱的。
所以，这个时候哪怕你有强烈的好奇心也无奈很好地表达出来，大多只能被动的承受工作安顿。
在这个期间做事件须要依赖一些教程、文档，只能“如法炮制”，简直不能在不借助内部信息的状况下解决之前从未遇到过的新问题，所以百度、Google 就成了他们惟一的抉择。
你能够在你的身边察看一下，如果常常有以下这些场景呈现，大多是高级程序员的体现。
- 很难提出正确的问题，大多会间接问他人这个性能应该怎么做。如果你分明地向他解释，他就会齐全按你说的去做，甚至你写的示例代码都会 copy 过来。因为在他们的世界里，只有编译胜利和编译失败，工作实现和工作未实现。
- 常常犯错误，所以会预留过多“弹性工夫”，以便有工夫在到期日之前重做。所以总会埋怨“没工夫”。
- 对与本人有工作交加的人员的职能没有意识。比方，对测试人员总是充斥敌意的，因为他们发现了谬误，“妨碍”了本人实现工作。
- 还没留神养成一些好习惯，比方习惯性地提炼反复代码、编写格调统一的代码、自测等等。
很遗憾，看似很高级的阶段，并不只是刚踏入工作的程序员所属，在理论工作中，也有不少工作多年的人还处在这个阶段。
中级程序员 – 晓得如何做某事
对人群依照繁多维度进行划分，大多数时候都是合乎正态分布的，这里也不例外。中级程序员是咱们身边最多的，包含那些不得不穿上高级程序员马甲的中级程序员。
在这个阶段，有些中级程序员开始具备了肯定的“连贯能力”，但并不是所有人，次要看是不是领有了“共同体意识”。
在业余能力上，中级程序员曾经明确了肯定的“整体与部分”的概念，但依然看不到整个“森林”，大多局限在某个模块、流程上。比方，他们会想“这是做麻利的正确形式吗？”，但不会思考“这对整个团队、整个公司会产生什么理论的影响？”。
他们开始重视代码品质，因为放心低质量的代码会影响他们视线中的“整体”。
然而对于品质的了解还是比拟繁多。比方，这个时候你会常常听到他们把“性能”挂在嘴边，在他们心目中“性能”的位置是至高无上的，总是想着你这个计划和我的计划哪个性能更好。
同样能够察看一下四周，中级的开发大多数会这样做事：
- 针对一个问题，能够提出多个计划，然而无奈做出精确的决策。一旦更权威的人给出了他的抉择，中级程序员就会不假思索地依照倡议执行。
- 能够看出代码中的一些设计模式，然而本人写代码的时候除了单例和工厂，其它的简直想不到。
- 在探讨一些时尚的框架和技术的时候总能聊上几句，然而诘问这个框架或者技术有什么毛病，根本说不上来。甚至，草率地在我的项目中使用上这些时尚的框架和技术，最终导致线上问题频发，不得不让高级程序员来收拾残局。
- 可能对本人实现工作所需的工夫有精确的评估，然而评估别人的工夫不会因人而异，也会以本人作为规范来评估。
- 对与本人有工作交加的人员的职能有了肯定的意识。比方，会被动寻求测试的配合，帮忙本人交付更高质量的我的项目。
其实这个阶段是最危险的阶段，因为最可怕的不是无知，而是只知其一; 不知其二。心理学中的邓宁 - 克鲁格效应（The Dunning-Kruger Effect）讲述的就是这个问题。
两位社会心理学家在 1999 年做的 4 项钻研，证实了上面的这个曲线的存在。
在这种状态下，人最容易高估本人，这也是很多导致产生很多“假高级程序员”的起因所在。
高级程序员 – 晓得必须做些什么
高级程序员在“业余能力”、“连贯能力”与“领导能力”这三个维度都有所建树。因为他们岂但能够把从 1 到 100 的事件做得很好，也有能力率领其它人实现 0 到 1 的事件。
依据我身边所接触的程序员群体来看，我所认为的高级程序员，他们明确没有什么是完满的，相同，问题、毛病和危险总是存在的。
他们的决策总是站在为了整体的“均衡”角度去思考，而不是技术的酷炫或者外界流传的所谓“正确的”技术。
他们会更多地关怀那些不不言而喻的货色，如可维护性、可扩展性、易浏览、易调试等等。
高级程序员就好比社会中的成年人，他们踩过足够多的坑，也填过足够多的坑，曾经认清了事实的残暴，寻求适宜而不是完满。周到、求实、简略，是他们做事的时候强烈散发出的“滋味”。
能够依据上面的这些场景来看看你身边有多少“有滋味”的高级程序员？
- 与高级和中级程序员不同，他们抛出问题不是为了正确地做事，而是做正确的事。他们会询问为什么要这样做以及你想要实现什么。当你通知他们指标是什么后，他们或者会通过暗示这种形式是谬误的而另一种更好来做出一些修改；当然，更重要的是还会提供论据压服你。
- 因为提前明确了做事的指标，所以在动手做一件事的过程中，他会在要害细节思考有没有更好的办法，甚至是那些不在之前的探讨范畴的新尝试。
- 他能够轻松地抵赖他不晓得什么，并且向你求教。同时也能够轻松地向别人讲清楚他所晓得的事件。
- 他们了解单干的人员的职能的作用，岂但晓得什么时候向谁寻求帮忙，还晓得本人如何更好地帮忙他们。
- 艰难的事交给他们很释怀，因为他们善于的不是某种技术，而是解决问题的能力。他们总能解决那些之前从未遇到过的新问题，哪怕它们很艰难。
那么，怎么做有助于咱们成为高级程序员呢？
1、关注技术之余还要关注业务
为什么把它放第一点，因为我感觉这点最重要，是其它项的根底，也最容易做到，然而很多程序员不违心去做。
肯定要搞清楚业务指标，不搞清楚不动工。置信我，只有是一位合格的 leader，肯定会不厌其烦地和你说分明的。
而后要习惯基于业务指标去剖析可能会面临的技术挑战。比方，多少流量，波及哪些用户角色和性能，复杂度有多大等等。
再带着上面的“不可能三角”去寻找适合的技术框架、解决方案。尽可能地寻求最优的均衡，而不是走极端。
如果拿捏不准，能够将多个计划各自的优缺点列举进去，向 leader 寻求倡议。
2、“设计”代码而不是“写”代码
个别人可能拿到需要，就开始写代码了，写着写着因为页面性能越来越多，感觉代码越来越简单，本人都会感觉难以保护了。
虽说要做好设计离不开大量的实战经验的积攒，但还是有些办法能够让塑造这个能力的过程更快一些。比方：
- 首先就是后面提到的第一点，多关注业务。不理解业务，你啥都设计不进去，或者把马设计成了驴……
- 如果某个性能的开发 / 批改，以“天”为工时单位，肯定要先画图。
- 搞明确每个设计模式的特点和实用场景，留神，不须要把代码怎么写背下来。只有你每次写代码之前扫一眼设计模式的列表，看看有没有实用的。如果有的话，再去“如法炮制”依照设计模式去实现，通过工夫的积攒，缓缓地，你真正把握的设计模式就越来越多了。这有助于锤炼你的设计能力。
3、“接”需要之前会先“砍”需要
要做这点还得依赖于第一点，否则，你提出的“砍”需要倡议大多是不会被驳回的。
很多人在听需要解说的时候，思考的是，这个性能能不能实现、怎么实现、难不难。大多数的发问也是基于这个思路开展的。
可能也会提出“砍”需要的问题，然而理由大多是这个实现起来太麻烦了，这个没法实现之类。
其实只有你时刻放弃着“做这个需要的目标是什么”这个问题去思考，“砍”需要会变成一件更容易胜利，而且自然而然的事件。
4、解决一类问题而不是一个问题
很多人感觉，每天看到 bug 清完就高枕无忧了，哪怕同一个问题在生产环境呈现屡次，最多也就说一句“不会吧，怎么又出问题了”。
这种看待问题的形式只会让你越来越忙，因为你的解决问题效率与投入的工夫多少是成同比变动的。
咱们要习惯于解决掉一个 bug 之后，想一下是否通过什么形式找到现有代码中的同类问题，并把它们解决掉。
甚至是思考有没有什么方法可能一劳永逸地防止此类问题再次发生，比方封装一个 SDK 或者写一个组件，尽可能用一种低侵入的通用形式将问题扼杀在摇篮里。岂但让本人轻松了，也造福了大家。
5、遵循 KISS 准则，写尽可能简略的代码
KISS 准则：放弃简略，愚昧（Keep it simple, stupid）。
不单单是程序员，任何化繁为简的能力才是一个人功力深厚的体现，没有之一。
越简略，越靠近实质。就好比，有的人要用简明扼要能力讲明确一件事，而有的人只有做一个形象的比喻你就懂了。
这个“简略”指的是整体的简略，而不是通过部分的简单让另一个部分简略。比方，为了下层的应用更加傻瓜化，底层封装的代码盘根错节、艰涩难懂，这并不是真正的“简略”。
如果你自认为曾经是一个中级或者高级程序员了，那么你回头去看看本人还是高级程序员那会写的代码，就会很容易发现一些显得冗余的代码。
第二点提到的——“设计代码而不是写代码”对做好这点有很大的帮忙。
6、抉择忍耐某些问题
在人工智能还不能代替咱们 coding 之前，咱们永远要亲自面对无穷无尽的、这样那样的问题。
然而，任何事物都有两面性的，一个计划在解决一个老问题的同时，总会带来新的问题。所以，咱们肯定要意识到，忍耐某些问题是必然的。
那些你当初看起来很傻逼的设计，可能就是过后的人做出的斗争。
所以，既然如此，你更应该思考的是，以后的这个问题当初到底有没有必要解决？值不值得，为什么之前没去解决？它是不是你以后所有待解决问题列表中优先级最高的？
7、打造本人的“T 型”专业技能
可能很多人都听过“T 型人才”的概念，咱们程序员在专业技能的打造上也适宜用这种模型。
然而对于“先竖再横”还是“先横再竖”可能不同的人有不同的认识。
我的观点是，大多数状况下，先竖再横。特地是某个技术、畛域倒退得越成熟，越应该如此。
因为很多事物的实质是一样的，所以对某一个畛域达到十分深刻，洞察到一些实质的货色之后，对其它相邻的畛域有举一反三的成果。能够减速本人在“广度”上的扩大。
不过，“广度”也不是说走马观花，只晓得最表象的“它是什么”。我认为比拟适合的水平是，能够不必分明某个技术具体的应用形式，但得晓得它能够解决哪些问题，以及应用老本和潜在的危险，我将这些信息概括为“它怎么样”。
8、构建自驱动的“闭环”
很多人都晓得闭环的概念，然而它的重要性和价值往往被低估。因为人总是短视的，“聚沙成塔”之类的形式总是不受待见。
惯例的搭建一个闭环的过程大多是这样的。
这里所说的自驱动的“闭环”是这样的。
如何能力变成这样呢？只有做一件事，尽可能多地对外输入本人的常识。
举个我本人的例子，我在 2015 年那会在我的项目中开始引入畛域驱动设计，并且一直地在外部进行分享它的益处，缓缓地越来越多的我的项目开始往这个方向走。
因为后期的一直分享，所以在组织外部，他人对我的人设多了一个“DDD 专家”的标签，那么大家遇到无关 DDD 的问题就会来和我一起探讨。
越到前面，我曾经不必本人被动去寻找这个畛域的常识去学习了，因为接管到的内部反馈曾经足够多了，它们可能倒逼我往前走。并且这些反馈都是理论的实在场景，此时的信息获取和学习天然能达到“学以致用”的成果。
说实话，有不少人并不是这么想的，他们想的恰恰相反：“为什么每个人都在问我问题！你本人去学习吧！”。
所以，当你遇到其他人来求教你的时候，如果凑巧这是你所关注的畛域，那么应该去拥抱这个问题而不是排挤它。因为你是团队里最权威的人，这是你构建自驱动“闭环”的好机会。错过这一回，下一回不晓得得等多久。
后面文章里说到，我会将“专业技能”、“连贯内部的能力”、“领导力”三个维度组合起来给你看。就是上面这个样子。
你会发现这外面蕴含了程序员在进阶后的几个常见岗位。
能够对号入座一下：D
好了，咱们总结一下。
这篇我先和你聊了一下在大家眼中高级程序员是什么样子，发现没有特地对立的规范，都是含糊的。这也体现在了几个事实的场景中，比方招聘高级程序员、造就高级程序员上。
其次，我对高级、中级、高级程序员的特点别离论述了本人的观点。
而后，给出了一些帮忙大家往高级程序员聚拢的实际思路。
心愿对你有所启发。
用 Martin Fowler 的一句话作为结尾：“任何傻瓜都能写计算机能了解的代码，优良的程序员编写人类可能了解的代码。”
Any fool can write code that a computer can understand. Good programmers write code that humans can understand
Martin Fowler
最初的小欲望
心愿看到这篇文章的每个程序员最终都能成为头发繁茂的码农：
举荐浏览
为什么阿里巴巴的程序员成长速度这么快，看完他们的内部资料我懂了
程序员 50W 年薪的常识体系与成长路线。
月薪在 30K 以下的 Java 程序员，可能听不懂这个我的项目；
字节跳动总结的设计模式 PDF 火了，完整版凋谢分享
对于【暴力递归算法】你所不晓得的思路
开拓鸿蒙，谁做零碎，聊聊华为微内核
=
看完三件事❤️
如果你感觉这篇内容对你还蛮有帮忙，我想邀请你帮我三个小忙：
点赞，转发，有你们的『点赞和评论』，才是我发明的能源。
关注公众号『Java 斗帝』，不定期分享原创常识。
同时能够期待后续文章 ing????
