你们在寻找的高级程序员究竟是什么样子的？

若是第二次看到个人文章，欢迎「文末」扫码订阅我我的的公众号（跨界架构师）哟~

每周五11：45 按时送达。__固然了，也会时不时加个餐～

个人第「110」篇原创敬上

你好，我是Z哥。

这篇文章主题很简单，就是一个很常见的话题“什么是高级程序员？”。

文章稍微长了些，可是很容易阅读。

咱们的中国文化，对“面子”看的特别重，因此你会发现身边处处都是高级XXX，听着倍儿有面子，程序员也不例外。

可是你真要问每一个人，你认为的高级XXX是什么样子的。估计每一个人都有不一样的回答。

我还记得在我刚开始从事编程工做的时候，对坐在边上不远的那位我心目中的高级程序员的印象是：

工做至少有六、7年以上，能写一个用起来很方便、看起来很牛逼、可是不太容易让初级人员看懂的框架。

前两天，我把这个问题丢到群里，你们给出的答案中，占比最高的是如下几个。

• 有 N 年以上编程经验（大部分都说5年以上）
• 有出版过技术图书
• 对某领域内对经常使用框架原理有了解，而且实际使用超过2年
• 能够随时随地快速写出常见的一些算法
• 至少封装过一个被全局使用的开发框架
• 写出来的代码，阅读起来很好理解
• 能带领其余人员成功完成项目

你看，这件事对你们来讲就是常说的，“一千我的眼中有一千个哈姆雷特”。

不过这也正常，毕竟像初级、中级、高级这种高度抽象的词汇，想要获得一个可描述的定义与人交流，必然须要夹杂着我的的主观因素。

可是不少行业都在这么进行分类，天然有它的道理和好处。

我以为其中最大的一个好处刚好是「主观」的附属品——「弹性」。

好比，我如今想招一位高级程序员，面试的时候无论是经过仍是不经过，我都有理由来解释我对“高级”的定义。如此一来，我对陌生人的判断就有了更大的「弹性」。

这实际上是面试官的一种权利，也是长期以来面试者总在面试中处于下峰的缘由之一。

事物老是有两面性的，咱们在对陌生人弹性的同时，间接的也对内部的人弹性了，会致使内部的一些人才培养出现问题。

好比，你以为内部的高级程序员不够，但愿能在外部招聘的同时，从内部也培养一些出来。可是此时，你又面临了须要定义什么是“高级”的问题。

若是无法定义一个可以达成共识的标准，又如何指导培养的方向呢？只能是一句空话。

长期以往会致使更严重的问题：真正的高级程序员不够，只能让中级程序员顶上。顶替的时间长了，会让一些中级程序员误觉得本身已经达到了高级水平。

在我平时的面试中，这样的案例家常便饭。网上流传的工做10年 = 1年重复10次的段子是真实存在的。

下面我来聊聊我对「什么是高级程序员」的我的见解，欢迎你和我一块儿探讨。

无论是什么行业，什么岗位，在这个高度分工协做的现代社会，所需的能力主要分为三个维度。

• 专业能力
• 链接能力
• 领导能力

我对程序员在这三个维度的理解大体是如下这个样子。

先卖个关子，文章的最后我会将这三个维度组合起来，你会发现一片新的天地。

根据这三个维度的水平差别，咱们对初级程序员、中级程序员、高级程序员作一个简要的描述。

01 初级程序员 - 知道有事要作 

处在初级阶段的时候，咱们的精力大多只会专一在专业能力的提高上。这个时候「领导能力」和「链接能力」是很弱的。

因此，这个时候哪怕你有强烈的好奇心也没法很好的表达出来，大多只能被动的接受工做安排。

在这个时期作事情须要依赖一些教程、文档，只能“依样画葫芦”，几乎不能在不借助外部信息的状况下解决以前从未遇到过的新问题，因此百度、Google就成了他们惟一的选择。

你能够在你的身边观察一下，若是常常有如下这些场景出现，大可能是初级程序员的表现。

• 很难提出正确的问题，大多会直接问别人这个功能应该怎么作。若是你清楚地向他解释，他就会彻底按你说的去作，甚至你写的示例代码都会copy过去。由于在他们的世界里，只有编译成功和编译失败，任务完成和任务未完成。
• 常常犯错误，因此会预留过多“弹性时间”，以便有时间在到期日以前重作。因此总会抱怨“没时间”。
• 对与本身有工做交集的人员的职能没有认识。好比，对测试人员老是充满敌意的，由于他们发现了错误，“阻碍”了本身完成工做。
• 还没注意养成一些好习惯，好比习惯性的提炼重复代码、编写风格一致的代码、自测等等。

很遗憾，看似很初级的阶段，并不仅是刚踏入工做的程序员所属，在实际工做中，也有很多工做多年的人还处在这个阶段。

02 中级程序员 - 知道如何作某事

对人群按照单一维度进行划分，大多数时候都是符合正态分布的，这里也不例外。中级程序员是咱们身边最多的，包括那些不得不穿上高级程序员马甲的中级程序员。

在这个阶段，有些中级程序员开始具有了必定的「链接能力」，但并非全部人，主要看是否是拥有了「共同体意识」。

在专业能力上，中级程序员已经明白了必定的「总体与局部」的概念，但仍然看不到整个“森林”，大多局限在某个模块、流程上。好比，他们会想“这是作敏捷的正确方式吗？”，但不会考虑“这对整个团队、整个公司会产生什么实际的影响？”。

他们开始注重代码质量，由于担忧低质量的代码会影响他们视野中的“总体”。

可是对于质量的理解仍是比较单一。好比，这个时候你会常常听到他们把「性能」挂在嘴边，在他们心目中「性能」的地位是至高无上的，老是想着你这个方案和个人方案哪一个性能更好。

一样能够观察一下周围，中级的开发大多数会这样作事。

• 针对一个问题，能够提出多个方案，可是没法作出准确的决策。一旦更权威的人给出了他的选择，中级程序员就会不假思索的按照建议执行。
• 能够看出代码中的一些设计模式，可是本身写代码的时候除了单例和工厂，其它的几乎想不到。
• 在讨论一些时髦的框架和技术的时候总能聊上几句，可是追问这个框架或者技术有什么缺点，基本说不上来。甚至，草率的在项目中运用上这些时髦的框架和技术，最终致使线上问题频发，不得不让高级程序员来收拾残局。
• 可以对本身完成任务所需的时间有准确的评估，可是评估他人的时间不会因人而异，也会以本身做为标准来评估。
• 对与本身有工做交集的人员的职能有了必定的认识。好比，会主动寻求测试的配合，帮助本身交付更高质量的项目。

其实这个阶段是最危险的阶段，由于最可怕的不是无知，而是只知其一;不知其二。心理学中的邓宁-克鲁格效应(The Dunning-Kruger Effect)讲述的就是这个问题。

两位社会心理学家在1999年作的4项研究，证明了下面的这个曲线的存在。

在这种状态下，人最容易高估本身，这也是不少致使产生不少“假高级程序员”的缘由所在。

03 高级程序员 - 知道必须作些什么

高级程序员在「专业能力」、「链接能力」、「领导能力」这三个维度都有所建树。由于他们不但能够把从1到100的事情作得很好，也有能力带领其它人完成0到1的事情。

根据我身边所接触的程序员群体来看，我所认为的高级程序员，他们明白没有什么是完美的，相反，问题、缺点和风险老是存在的。

他们的决策老是站在为了总体的「平衡」角度去考虑，而不是技术的酷炫或者外界流传的所谓“正确的”技术。

他们会更多的关心那些不显而易见的东西，如可维护性，可扩展性，易阅读，易调试等等。

高级程序员就比如社会中的成年人，他们踩过足够多的坑，也填过足够多的坑，已经认清了现实的残酷，寻求适合而不是完美。周到、务实、简单，是他们作事的时候强烈散发出的“味道”。

能够根据下面的这些场景来看看你身边有多少“有味道”的高级程序员？

• 与初级和中级程序员不一样，他们抛出问题不是为了正确的作事，而是作正确的事。他们会询问为何要这样作以及你想要实现什么。当你告诉他们目标是什么后，他们或许会经过暗示这种方式是错误的而另外一种更好来作出一些修正；固然，更重要的是还会提供论听说服你。
• 由于提早明确了作事的目标，因此在动手作一件事的过程当中，他会在关键细节思考有没有更好的方法，甚至是那些不在以前的讨论范围的新尝试。
• 他能够轻松地认可他不知道什么，而且向你请教。同时也能够轻松地向他人讲清楚他所知道的事情。
• 他们理解合做的人员的职能的做用，不但知道何时向谁寻求帮助，还知道本身如何更好的帮助他们。
• 困难的事交给他们很放心，由于他们擅长的不是某种技术，而是解决问题的能力。他们总能解决那些以前从未遇到过的新问题，哪怕它们很困难。

那么，怎么作有助于咱们成为高级程序员呢？

01 关注技术之余还要关注业务

为何把它放第一点，由于我以为这点最重要，是其它项的基础，也最容易作到。可是不少程序员不肯意去作。

必定要搞清楚业务目标，不搞清楚不开工。相信我，只要是一位合格的leader，必定会不厌其烦的和你说清楚的。

而后要习惯基于业务目标去分析可能会面临的技术挑战。好比，多少流量，涉及哪些用户角色和功能，复杂度有多大等等。

再带着下面的「不可能三角」去寻找合适的技术框架、解决方案。尽量的寻求最优的平衡，而不是走极端。

若是拿捏不许，能够将多个方案各自的优缺点罗列出来，向Leader寻求建议。

02 “设计”代码而不是“写”代码

通常人可能拿到需求，就开始写代码了，写着写着因为页面功能愈来愈多，感受代码愈来愈复杂，本身都会以为难以维护了。

虽然说要作好设计离不开大量的实战经验的积累。可是仍是有些方法可让塑造这个能力的过程更快一些。好比，

1. 首先就是前面提到的第一点，多关注业务。不了解业务，你啥都设计不出来。或者把马设计成了驴……
2. 若是某个功能的开发/修改，以“天”为工时单位，必定要先画图。具体画什么图，能够参考我以前写的文章：软件开发中会用到的图。
3. 搞明白每一个设计模式的特色和适用场景，注意，不须要把代码怎么写背下来。只要你每次写代码以前扫一眼设计模式的列表，看看有没有适用的。若是有的话，再去“依样画葫芦”按照设计模式去实现，通过时间的积累，慢慢地，你真正掌握的设计模式就愈来愈多了。这有助于锻炼你的设计能力。

03 “接”需求以前会先“砍”需求

要作这点还得依赖于第一点，不然，你提出的“砍”需求建议大可能是不会被采纳的。

不少人在听需求讲解的时候，思考的是，这个功能能不能实现、怎么实现、难不难。大多数的提问也是基于这个思路展开的。

可能也会提出“砍”需求的问题，可是理由大可能是这个实现起来太麻烦了，这个无法实现之类。

其实只要你时刻保持着“作这个需求的目的是什么”这个问题去思考，“砍”需求会变成一件更容易成功，并且天然而然的事情。

04 解决一类问题而不是一个问题

不少人以为，天天看到bug清完就万事大吉了。哪怕同一个问题在生产环境出现屡次，最多也就说一句“不会吧，怎么又出问题了”。

这种对待问题的方式只会让你愈来愈忙，由于你的解决问题效率与投入的时间多少是成同比变化的。

咱们要习惯于解决掉一个bug以后，想一下可否经过什么方式找到现有代码中的同类问题，并把它们处理掉。

甚至是考虑有没有什么办法可以一劳永逸的避免此类问题再次发生，好比封装一个SDK或者写一个组件，尽量用一种低侵入的通用方式将问题扼杀在摇篮里。不但让本身轻松了，也造福了你们。

05 遵循KISS原则，写尽量简单的代码

KISS 原则：保持简单，愚蠢（Keep it simple, stupid）。

不仅仅是程序员，任何化繁为简的能力才是一我的功力深厚的体现，没有之一。

越简单，越接近本质。就比如，有的人要用长篇大论才能讲明白一件事，而有的人只要作一个形象的比喻你就懂了。

这个「简单」指的是总体的简单，而不是经过局部的复杂让另外一个局部简单。好比，为了上层的使用更加傻瓜化，底层封装的代码错综复杂、晦涩难懂，这并非真正的“简单”。

若是你自认为已是一个中级或者高级程序员了，那么你回头去看看本身仍是初级程序员那会写的代码，就会很容易发现一些显得冗余的代码。

第二点提到的——「“设计”代码而不是“写”代码」对作好这点有很大的帮助。

06 选择忍受某些问题

在人工智能还不能代替咱们coding以前，咱们永远要亲自面对无穷无尽的、这样那样的问题。

然而，任何事物都有两面性的，一个方案在解决一个老问题的同时，总会带来新的问题。因此，咱们必定要意识到，忍受某些问题是必然的。

那些你如今看起来很傻逼的设计，可能就是当时的人作出的妥协。

因此，既然如此，你更应该考虑的是，当前的这个问题如今到底有没有必要解决？值不值得，为何以前没去解决？它是否是你当前全部待解决问题列表中优先级最高的？

07 打造本身的“T型”专业技能

可能不少人都听过“T型人才”的概念，咱们程序员在专业技能的打造上也适合用这种模型。

可是对于“先竖再横”仍是“先横再竖”可能不一样的人有不一样的见解。

个人观点是，大多数状况下，先竖再横。特别是某个技术、领域发展的越成熟，越应该如此。

由于不少事物的本质是同样的，因此对某一个领域达到很是深刻，洞察到一些本质的东西以后，对其它相邻的领域有举一反三的效果。能够加速本身在「广度」上的扩展。

不过，「广度」也不是说走马观花，只知道最表象的“它是什么”。我认为比较合适的程度是，能够不用清楚某个技术具体的使用方式，但得知道它能够解决哪些问题，以及使用成本和潜在的风险，我将这些信息归纳为“它怎么样”。

08 构建自驱动的“闭环”

不少人都知道闭环的概念，可是它的重要性和价值每每被低估。由于人老是短视的，“积少成多”之类的方式老是不受待见。

常规的搭建一个闭环的过程大可能是这样的。

这里所说的自驱动的“闭环”是这样的。

如何才能变成这样呢？只要作一件事，尽量多的对外输出本身的知识。

举个我本身的例子，我在2015年那会在项目中开始引入领域驱动设计，而且不断的在内部进行分享它的好处，慢慢地愈来愈多的项目开始往这个方向走。

由于前期的不断分享，因此在组织内部，别人对个人人设多了一个“DDD专家”的标签，那么你们遇到有关DDD的问题就会来和我一块儿探讨。

越到后面，我已经不用本身主动去寻找这个领域的知识去学习了，由于接收到的外部反馈已经足够多了，它们可以倒逼我往前走。而且这些反馈都是实际的真实场景，此时的信息获取和学习天然能达到「学以至用」的效果。

说实话，有很多人并非这么想的，他们想的偏偏相反：“为何每一个人都在问我问题！你本身去学习吧！”。

因此，当你遇到其余人来请教你的时候，若是恰巧这是你所关注的领域，那么应该去拥抱这个问题而不是排斥它。由于你是团队里最权威的人，这是你构建自驱动“闭环”的好机会。错过这一回，下一回不知道得等多久。

前面文章里说到，我会将「专业技能」、「链接外部的能力」、「领导力」三个维度组合起来给你看。就是下面这个样子。

你会发现这里面包含了程序员在进阶后的几个常见岗位。

能够对号入座一下：D

好了，咱们总结一下。

这篇我先和你聊了一下在你们眼中高级程序员是什么样子，发现没有特别统一的标准，都是模糊的。这也体如今了几个现实的场景中，好比招聘高级程序员、培养高级程序员上。

其次，我对初级、中级、高级程序员的特色分别阐述了本身的观点。

而后，给出了一些帮助你们往高级程序员靠拢的实践思路。

但愿对你有所启发。

最后，用Martin Fowler的一句话做为结尾：“任何傻瓜都能写计算机能理解的代码，优秀的程序员编写人类可以理解的代码。”

Any fool can write code that a computer can understand. Good programmers write code that humans can understand

但愿看到这篇文章的每一个程序员最终都能成为头发茂盛的码农：D

推荐文章：

• 8个月打磨，一份送给程序员的「分布式系统」合集
• 一个引起程序员们干架的问题

做者：Zachary

出处：https://zacharyfan.com/archives/934.html

---

若是你喜欢这篇文章，能够点一下文末的「赞」。

这样能够给我一点反馈。: )

谢谢你的举手之劳。

▶关于做者：张帆（Zachary， 我的微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎 扫描下方的二维码~。

若是你是初级程序员，想提高但不知道如何下手。又或者作程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注个人公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思惟导图。

若是你是运营，面对不断变化的市场一筹莫展。又或者想了解主流的运营策略，以丰富本身的“仓库”。欢迎关注个人公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思惟导图。

按期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。