成为高级开发工程师是多数人在编程生涯中的奋斗目标之一，那么成为“高级”开发工程师意味着什么呢？
在开始之前，我们先消除下对于高级开发工程师固有的一些观念。与招聘网站上列出的绝大部分职位不同的是，高级开发工程师的定义其实并不仅仅和你简历上的工作年限严格相关。
确实，通常更多年限的工作时间往往伴随着更多工作经验，甚至有些公司仅仅根据工作年限来确定你的级别。但事实是，工作年限并不是唯一用于证明某个人是否是高级水平的因素。
那么为了进阶为高级水平，我们能为此做哪些准备呢？
高级开发工程师所具备的素质
回顾职业生涯中让我们最钦佩以及尊重的开发者，一般都归结为有如下四方面的素质：
- 经验
- 领导力
- 指导力
- 技术力
仅仅将其中任何一项作为评判一个人在团队中的表现都不够完善，每个开发者都是独一无二的，某方面素质强，其他方面素质弱些都是正常情况。更重要的是综合上述四个素质来评判某个人能给所在团队带来的进步。
接下来让我们进一步分析各项素质。
经验
谈到经验通常能想到的是工作的年限，但我们知道其实这并不准确而全面。
经验其实和开发者一样，都是与众不同的。比如开发者A在一个需要高密集度解决各种技术挑战的工作环境；与此同时，开发者B在一个有大量时间可以摸鱼的工作环境，可能唯一的工作职责只是每周简单更新下网站而已（当然这不一定是坏事，毕竟每个人都有自己的路要走且需要平衡工作和生活）。同样工作五年，开发者A和开发者B的经验其实是不同的。
那么经验到底意味着什么？
能基于以往的工作辨别新问题的模式
几乎每个开发者开发过程中都经历过（也许是不经意间）某些随机产生的棘手的错误，也许是某些和具体编程语言、工具类、或者操作系统相关的问题，具体是什么没有关系。
通过请教同事也好，Google 也罢，最终你摆平了这个错误！三个月后，你在其他项目中又遇到了类似的问题，这次你都不需要 Google 或者已经知道要 Google 什么了。你早就知道这个问题是怎样的，并且能更快的干掉它！！！
这就是经验带来的变化！能从错误或以往成功的经历中分辨出问题的模式，这就是成长。这些经验可以帮助团队成长，当其他人被卡住时，可以使他们摆脱困境。
能分辨那些你不知道的
能知道那些自己不知道同样很重要，常言道：“学的浅，感觉自己什么都懂；学的越多，反而你可能会发现自己不懂的也越多”。
尽管如此，这不应该被视为可怕的事情。这应该是激烈人心的，我们所熟知的领域有更广阔的天地值得去探索去发现！
初级工程师：“我不知道怎么解决这个问题！如果只是不停的 Google，我永远也找不到答案。😵”
高级工程师：（因为一个问题 Google 或 StackOverflow 了 37个浏览器 tab）
重要的是要意识到这种心智模式将如何影响你的工作及团队中的其他成员。比如，如果你假装什么都知道并且独自做了大量的工作，这并不会帮助到任何人。相反，可能由于你实际并不理解某个需求而导致做了很多无用功，这会影响 sprint 的进度并且让其他团队成员感到沮丧（甚至可能影响到产品的用户）。
无论你是在准备阶段还是在开发期间，都不要害怕去请求协助。open-minded，也许你可能是团队中唯一的高级工程师，但这并不意味着你不能从团队中的其他初、中级工程师学到什么。
尝试去仔细审视目前你所处的阶段，你懂得东西，向哪方面继续深入学习能让受益更多。
领导力
作为团队中的高级开发工程师，一般都被期望能有潜在的领导力。但这并不意味着你需要在项目中扮演 Tech Lead 的角色或者拍板最终决定，而是说你最起码能在一定程度推进项目的进展。
能识大局（bigger picture）
如果你曾和其他团队成员一起开发过项目，应该明白每个项目或 feature 都基本由一系列关联的 stories 来完成。每个 story 都会聚焦在具体的事项上，以实现特定目标。
如果团队中没有任何人明白这些 stories 是如何组装成特定的目标，这将是充满挑战的。作为高级开发工程师，你应该能像拼图一样知道每个不同部件是怎样组合成更大的版图的，并且能理解每个 story 为什么有特定的接受标准。如果你不知道这些，你得知道如何能获取到这些答案并且确保同步给了其他团队成员。
如果你还不确定方向，放下手中的事情，必要时回退一步，仔细想想如何能帮助项目团队实现最终目标。
能协助其他更少经验的团队成员
协助或指引初级开发工程师或其他更少经验的成员，这应该是自然而然的能力。开发者迷失在项目的大局中不知该聚焦在哪儿，这是很普遍的现象。和我们前面讨论的一样，高级开发工程师应该能够对整体项目及不同 stories 如何合理组织有好的想法和把控能力。
协助引导其他团队成员以确保其方向正确。尽管让所有人都明白每个组件如何组成更大图景会很有益处，但有时协助他们专注在手头上的具体任务如何组织会更有意义。在与团队成员合作时，需要意识到这点，无论是通过鼓励他们提出更多问题，还是在 review 代码发现他们偏离方向时提供引导。
指导力
只埋头专注于自己的工作而不用顾虑其他成员在做什么听上去确实挺舒心，但这真的对所有人都有益吗？
能帮助其他团队成员成长
你也许是个“一顶十”的高效率开发者， 但把所有事情都揽在自己手上且没有任何团队协作反而会影响团队整体的效率。比如接手其他同事的工作时，通常你需要花大量的时间和精力去理清上下文。但如果平时有花少量时间和其他成员互相沟通相关工作的话，这个过程会更加顺畅。
“单打独斗”从某种意义上来说并不道德，毕竟没有人想在项目中感到被孤立，尤其是更少经验的工程师。软件工程是个大而复杂的世界，一些小小的引导可以很大程度帮助其他成员提高生产力，且有利于建立一个更多快乐、更少压力的环境。
也行很容易忘记我们曾经也是团队中的一名初级开发工程师的经历，某些事情对于你来说想当然，但这些概念对于其他成员去掌握可能是具有挑战性的。
记住团队成员是一体的，任何大大小小的改进都值得庆祝，当然如果有其他团队成员陷入僵局，记得伸出你的援手。
能分享知识
分享知识是很多团队努力去做的事情，很多时候我们都希望能通过某种方式去完成，但大多数时候却未能如愿。对此，我们能做些什么呢？
请分享你所知的。记得你刚刚又在核心业务逻辑上重复工作了吗？快去花30分钟带所有成员都梳理一遍相关代码吧，如果他们难以理解，记得共享你的屏幕。
这是可以鼓励所有人去做的，不论工程师的经验。通过和团队成员分享你的工作成果，其实也是在归纳总结，温故知新，自然会学到更多。
技术力
我故意将这点放到最后。这是因为，尽管技术能力挺重要，但在成为高级开发工程师的旅途中有更多的方面需要综合，不是仅仅精通于某类技术就行。
能快速上手“新”技术
作为高级开发工程师，通常在其特定领域能比初级开发工程师更快提高生产力。假如你是个 JavaScript 专家，那么你会被期望对 JavaScript 语言的核心原则和模式有较深入的了解。
前面我们讨论过“能分辨那些你不知道的”，认为所有的高级开发工程师知道所有的事情是不现实的。比如我不会因为一个 GoLang 专家不懂 JavaScript 而否认他是个高级开发工程师，但会希望他们在学习其他语言时能懂得更好利用其现有知识储备。
能合理运用模式
某些情况下，你刚刚运用的代码模式不是最新的。这没有关系！在构建出优秀的软件这个目标上，并没有必要要求每个解决方案都是最新且独一无二。
因此，我们可以通过以往成功或失败的经历中学习并总结出相关模式，从而更好地运用在团队工作中。
一些成熟的模式（比如 MVC 模式）并不是无故流行起来的，这些都是工程师们不断解决各种软件领域的各类挑战一步步探索出的知识晶体。利用这些知识晶体，我们可以将解决方案应用到日常的工作中。我们不需要重复造轮子，而是更关注在使用成熟的模式解决实际的挑战以及构建出好的产品。
路漫漫其修远兮
在编码生涯中，我们每个人都有自己独特的成长路径。希望我们都能成为更好而全面的开发工程师，并且能明白所做的工作给团队带来的影响力。
最后，一同共勉：路漫漫其修远兮，吾将上下而求索。