作者：HannahLin
起源：medium
明天，想跟大家聊聊我身边的「真．资深工程师」大略都具备怎麽样的能力跟特质，以及身为一般的工程师，应该要朝什麽方向去致力。
实际能力
既然是工程师，不论你是下班时做公司我的项目，还是上班后本人搞外包，最重要的工作就是把脑中的构想通过写代码实现进去，所以实际能力相对是必要的。就像 Linus Torvalds 的名言“Talk is cheap. Show me the code”，光说是没有用的，只有把程式码写进去了，那才算是真正实现了一件事件。
实际能力要到什麽水平能力算是“资深”呢？这也没有标准答案，但依据我的察看，资深工程师们的实战经验往往十分丰盛，只有你的需要不要太过严苛（心愿零碎的可用性有十个 9 之类的 XD），简直没有做不进去的货色。
任何 ticket 对他们来说大略都只有「这个简略弄一下很快就好了」跟「这货色我要花点工夫钻研一下」两种，而且他们通常都能够独立工作，不会忽然跑来问你「为什麽我的 npm install 跑不过」、「我没写过 Dockerfile 能够教我吗？」。
说了这麽多，那实际能力要怎麽练起来呢？
对于这个问题，我的想法是要一直学习新货色，并且真的利用在实战中。
譬如我本来就很相熟用 Node.js 写 Restful API，那下次 Side Project 就能够试试 GraphQL 或是乾脆改用 Rust，尽管第一次写 Rust 会被编译器搞得很苦楚（想把电脑砸烂的那种），但写了就会发现「原来这种中央可能会有 data race！」、「原来非同步不是只有 callback 跟 promise 两种解决办法」，而这些事件做久了会缓缓晋升你的技术深度跟广度。
有了足够的技术深度跟广度之后，既便将来遇到一些没碰过的货色，也只须要花个五到十分钟就能看懂他在干嘛，甚至能猜到底层的技术原理，因而有需要进来时即使不相熟也能够更有把握的把货色写进去。
违心花工夫做设计
尽管资深工程师很懂怎麽写代码，但除了写代码，我认为他们最厉害的中央其实是设计。这边的「设计」指的不是 UI 上的设计，而是在真正开始动工之前的「零碎设计」以及「技术选型」。
我身边很多资深工程师在工作时并 不花太多工夫写代码 ，因为对他们而言“事先设计”的重要性远大于“实操”， 谬误的设计一但开始动工了，可能要花费设计阶段所需的十倍甚至百倍工夫来补救。
就像我前阵子在帮忙公司的一个我的项目，那个我的项目最后是从 2016 开始的，也就是 Python 3.6 发佈那一年，但我的项目居然是抉择用曾经被官网放弃的 Python 2 来开发，导致起初很多套件都无奈更新，整个我的项目也无奈保护，只好从新写一个版本。
因而在真的开始实际之前，好的资深工程师们会先认真确认需要、设计资数据库 Schema、思考后端架构等等，等这些大方向都确定下来之后，才是开始写下第一行代码，这种“先确定大方向，再缓缓实现小细节”的工作形式让我十分观赏。
要怎么加强零碎设计的能力呢？
零碎设计这方面其实我也还算是老手，所以没方法给出一个很明确的答案，大家参考参考就好。我认为想要把零碎设计做好，除了本人要有肯定的技术深度及广度之外，最重要的就是跟其他人探讨，不然很容易受限于本人过来的教训，而想不到更好的办法。
譬如说我多年前刚开始做 Side Project 时，都是用 AWS EC2 开机器来跑 API server。因为那时不晓得有 S3 这种服务能够放动态档案，所以 server 收到的材料都是间接放在机器上。而这样做的代价就是我的服务没方法程度扩大，如果效力不够就只能降级到更好的机器，当初回头看真的很傻很天真 XD。
因而我感觉在对于架构的把握够全面之前，尽量还是要多跟他人探讨，真的没人探讨的话也能够多看一些文章跟书，像我前阵子看到“零碎设计 101 — 大型零碎的演进”跟“零碎设计入门”都很不错，有很多货色用讲的很含糊但图一看就懂了。
而这些常识都备齐后就是靠实战累积教训了，只有每次开发新性能之前都有认真做设计，那必然能够感触到每一种设计在开发速度、部署流程、可扩展性等等各方面的好坏，长此以往设计进去的零碎也就会越来越残缺。
团队先于集体
这点是我从其「真．资深工程师」身上察看到最令人钦佩的中央，好的资深工程师会去思考怎麽晋升整个团队的效率，而不只是集体的绩效。
以写文档这件事来说，每家公司都会有本人的开发流程、部署流程、AWS 明码放哪之类的。而我身边的资深工程师就很乐意把这些货色整顿成文档，毕竟如果没有文档到时也是去问他 XD，所以先花点工夫写起来不只省了本人工夫、也省整个团队的工夫。
另外，他们也很违心写自动化测试，当然测试不可能全副都测，但如果能把零碎中相对不能坏的中央用测试爱护，那团队内其余共事在开发时就能够更安心，而且也不会有人假日还要被挖起来修 bug XD。
除了写文档及测试之外，在技术选型方面，他们也是以整个团队为优先，认真考量各个技术的效益跟学习曲线。
比方说因为 Docker 很好学，花一个下午就能够学会写 Dockerfile 了，所以用它来做部署的 CP 值就十分高；但如果说是要用 Rust 来写 API Server，尽管能够进步效力帮公司省开机器的钱，但一来团队内的新人要花更多工夫能力上手、二来要找到会写 Rust 的工程师真的不容易，所以显然不是一个好的计划。
还有什麽要做什麽的吗？
尽管“以团队为优先”听起来很形象，但其实做起来并不难，只有你抱着推己及人的心态，在做任何事件的时候都想一下“他人会不会也有雷同的困扰？”，而后花点工夫帮忙解决，那离资深工程师也就不远了
总结
要成为资深工程师，相对不是年资到了或是 Leetcode 刷得够多就能够。好的资深工程师除了技术能力够扎实之外，在沟通能力以及心态上也必须足够成熟（这方面我也还在致力），才有方法率领整个团队一起后退。
以上就是我从本人身边察看到的资深工程师，当然资深工程师还有很多种样子，而且他们有些还会有本人的特异功能（特地会通灵、隔空解 bug 之类的 XD），因而大家有空也能够多察看身边的前辈们到底厉害在哪裡，兴许能从他们身上学到不少货色哦～
代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
原文：https://larry850806.medium.com/
交换
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq44924588… 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。