标签：人才 环境 加速 教程 ext 成本 招聘 例子 一个
优秀的程序员
根据这三个维度的水平差异，我们对初级程序员、中级程序员、高级程序员做一个简要的描述。
01 初级程序员 - 知道有事要做
处在初级阶段的时候，我们的精力大多只会专注在专业能力的提升上。这个时候「领导能力」和「连接能力」是很弱的。
所以，这个时候哪怕你有强烈的好奇心也无法很好的表达出来，大多只能被动的接受工作安排。
在这个时期做事情需要依赖一些教程、文档，只能“依样画葫芦”，几乎不能在不借助外部信息的情况下解决之前从未遇到过的新问题，所以百度、Google就成了他们唯一的选择。
你可以在你的身边观察一下，如果经常有以下这些场景出现，大多是初级程序员的表现。
很遗憾，看似很初级的阶段，并不只是刚踏入工作的程序员所属，在实际工作中，也有不少工作多年的人还处在这个阶段。
02 中级程序员 - 知道如何做某事
对人群按照单一维度进行划分，大多数时候都是符合正态分布的，这里也不例外。中级程序员是我们身边最多的，包括那些不得不穿上高级程序员马甲的中级程序员。
在这个阶段，有些中级程序员开始具备了一定的「连接能力」，但并不是所有人，主要看是不是拥有了「共同体意识」。
在专业能力上，中级程序员已经明白了一定的「整体与局部」的概念，但仍然看不到整个“森林”，大多局限在某个模块、流程上。比如，他们会想“这是做敏捷的正确方式吗？”，但不会考虑“这对整个团队、整个公司会产生什么实际的影响？”。
他们开始注重代码质量，因为担心低质量的代码会影响他们视野中的“整体”。
但是对于质量的理解还是比较单一。比如，这个时候你会经常听到他们把「性能」挂在嘴边，在他们心目中「性能」的地位是至高无上的，总是想着你这个方案和我的方案哪个性能更好。
同样可以观察一下周围，中级的开发大多数会这样做事。
其实这个阶段是最危险的阶段，因为最可怕的不是无知，而是一知半解。心理学中的邓宁-克鲁格效应(The Dunning-Kruger Effect)讲述的就是这个问题。
两位社会心理学家在1999年做的4项研究，证实了下面的这个曲线的存在。
在这种状态下，人最容易高估自己，这也是很多导致产生很多“假高级程序员”的原因所在。
03 高级程序员 - 知道必须做些什么
高级程序员在「专业能力」、「连接能力」、「领导能力」这三个维度都有所建树。因为他们不但可以把从1到100的事情做得很好，也有能力带领其它人完成0到1的事情。
根据我身边所接触的程序员群体来看，我所认为的高级程序员，他们明白没有什么是完美的，相反，问题、缺点和风险总是存在的。
他们的决策总是站在为了整体的「平衡」角度去考虑，而不是技术的酷炫或者外界流传的所谓“正确的”技术。
他们会更多的关心那些不显而易见的东西，如可维护性，可扩展性，易阅读，易调试等等。
高级程序员就好比社会中的成年人，他们踩过足够多的坑，也填过足够多的坑，已经认清了现实的残酷，寻求适合而不是完美。周到、务实、简单，是他们做事的时候强烈散发出的“味道”。
可以根据下面的这些场景来看看你身边有多少“有味道”的高级程序员？
那么，怎么做有助于我们成为高级程序员呢？
01 关注技术之余还要关注业务
为什么把它放第一点，因为我觉得这点最重要，是其它项的基础，也最容易做到。但是很多程序员不愿意去做。
一定要搞清楚业务目标，不搞清楚不开工。相信我，只要是一位合格的leader，一定会不厌其烦的和你说清楚的。
然后要习惯基于业务目标去分析可能会面临的技术挑战。比如，多少流量，涉及哪些用户角色和功能，复杂度有多大等等。
再带着下面的「不可能三角」去寻找合适的技术框架、解决方案。尽可能的寻求最优的平衡，而不是走极端。
如果拿捏不准，可以将多个方案各自的优缺点罗列出来，向Leader寻求建议。
02 “设计”代码而不是“写”代码
一般人可能拿到需求，就开始写代码了，写着写着由于页面功能越来越多，感觉代码越来越复杂，自己都会觉得难以维护了。
虽说要做好设计离不开大量的实战经验的积累。但是还是有些方法可以让塑造这个能力的过程更快一些。比如，
03 “接”需求之前会先“砍”需求
要做这点还得依赖于第一点，否则，你提出的“砍”需求建议大多是不会被采纳的。
很多人在听需求讲解的时候，思考的是，这个功能能不能实现、怎么实现、难不难。大多数的提问也是基于这个思路展开的。
可能也会提出“砍”需求的问题，但是理由大多是这个实现起来太麻烦了，这个没法实现之类。
其实只要你时刻保持着“做这个需求的目的是什么”这个问题去思考，“砍”需求会变成一件更容易成功，而且自然而然的事情。
04 解决一类问题而不是一个问题
很多人觉得，每天看到bug清完就万事大吉了。哪怕同一个问题在生产环境出现多次，最多也就说一句“不会吧，怎么又出问题了”。
这种对待问题的方式只会让你越来越忙，因为你的解决问题效率与投入的时间多少是成同比变化的。
我们要习惯于解决掉一个bug之后，想一下能否通过什么方式找到现有代码中的同类问题，并把它们处理掉。
甚至是考虑有没有什么办法能够一劳永逸的避免此类问题再次发生，比如封装一个SDK或者写一个组件，尽可能用一种低侵入的通用方式将问题扼杀在摇篮里。不但让自己轻松了，也造福了大家。
05 遵循KISS原则，写尽可能简单的代码
KISS 原则：保持简单，愚蠢（Keep it simple, stupid）。
不单单是程序员，任何化繁为简的能力才是一个人功力深厚的体现，没有之一。
越简单，越接近本质。就好比，有的人要用长篇大论才能讲明白一件事，而有的人只要做一个形象的比喻你就懂了。
这个「简单」指的是整体的简单，而不是通过局部的复杂让另一个局部简单。比如，为了上层的使用更加傻瓜化，底层封装的代码错综复杂、晦涩难懂，这并不是真正的“简单”。
如果你自认为已经是一个中级或者高级程序员了，那么你回头去看看自己还是初级程序员那会写的代码，就会很容易发现一些显得冗余的代码。
第二点提到的——「“设计”代码而不是“写”代码」对做好这点有很大的帮助。
06 选择忍受某些问题
在人工智能还不能代替我们coding之前，我们永远要亲自面对无穷无尽的、这样那样的问题。
然而，任何事物都有两面性的，一个方案在解决一个老问题的同时，总会带来新的问题。所以，我们一定要意识到，忍受某些问题是必然的。
那些你现在看起来很傻逼的设计，可能就是当时的人做出的妥协。
所以，既然如此，你更应该考虑的是，当前的这个问题现在到底有没有必要解决？值不值得，为什么之前没去解决？它是不是你当前所有待解决问题列表中优先级最高的？
07 打造自己的“T型”专业技能
可能很多人都听过“T型人才”的概念，我们程序员在专业技能的打造上也适合用这种模型。
但是对于“先竖再横”还是“先横再竖”可能不同的人有不同的看法。
我的观点是，大多数情况下，先竖再横。特别是某个技术、领域发展的越成熟，越应该如此。
因为很多事物的本质是一样的，所以对某一个领域达到非常深入，洞察到一些本质的东西之后，对其它相邻的领域有触类旁通的效果。可以加速自己在「广度」上的扩展。
不过，「广度」也不是说蜻蜓点水，只知道最表象的“它是什么”。我认为比较合适的程度是，可以不用清楚某个技术具体的使用方式，但得知道它可以解决哪些问题，以及使用成本和潜在的风险，我将这些信息概括为“它怎么样”。
08 构建自驱动的“闭环”
很多人都知道闭环的概念，但是它的重要性和价值往往被低估。因为人总是短视的，“聚沙成塔”之类的方式总是不受待见。
常规的搭建一个闭环的过程大多是这样的。
这里所说的自驱动的“闭环”是这样的。
如何才能变成这样呢？只要做一件事，尽可能多的对外输出自己的知识。
举个我自己的例子，我在2015年那会在项目中开始引入领域驱动设计，并且不断的在内部进行分享它的好处，慢慢地越来越多的项目开始往这个方向走。
因为前期的不断分享，所以在组织内部，别人对我的人设多了一个“DDD专家”的标签，那么大家遇到有关DDD的问题就会来和我一起探讨。
越到后面，我已经不用自己主动去寻找这个领域的知识去学习了，因为接收到的外部反馈已经足够多了，它们能够倒逼我往前走。并且这些反馈都是实际的真实场景，此时的信息获取和学习自然能达到「学以致用」的效果。
说实话，有不少人并不是这么想的，他们想的恰恰相反：“为什么每个人都在问我问题！你自己去学习吧！”。
所以，当你遇到其他人来请教你的时候，如果恰巧这是你所关注的领域，那么应该去拥抱这个问题而不是排斥它。因为你是团队里最权威的人，这是你构建自驱动“闭环”的好机会。错过这一回，下一回不知道得等多久。
前面文章里说到，我会将「专业技能」、「连接外部的能力」、「领导力」三个维度组合起来给你看。就是下面这个样子。
你会发现这里面包含了程序员在进阶后的几个常见岗位。
可以对号入座一下：D
好了，我们总结一下。
这篇我先和你聊了一下在大家眼中高级程序员是什么样子，发现没有特别统一的标准，都是模糊的。这也体现在了几个现实的场景中，比如招聘高级程序员、培养高级程序员上。
其次，我对初级、中级、高级程序员的特点分别阐述了自己的观点。
然后，给出了一些帮助大家往高级程序员靠拢的实践思路。
希望对你有所启发。
最后，用Martin Fowler的一句话作为结尾：“任何傻瓜都能写计算机能理解的代码，优秀的程序员编写人类能够理解的代码。”
标签：人才 环境 加速 教程 ext 成本 招聘 例子 一个
原文地址：https://www.cnblogs.com/EarlyBridVic/p/12100007.html
