我在 2020 年 7 月毕业并成为一名后端研发工程师，工作已快三年。本篇文章分享我从校园跨入职场以来，关于能力提升与工作效率的经验 & 思考。

如果觉得有用，欢迎在文章尾部 SUPPORT 给予我支持！

一、何为工作能力 & 效率

工作可以拆分为各种各样的任务，可能是：调研任务、编码任务、设计任务、流程管理任务等等。粗略地理解，工作能力取决于你能接下什么难度的任务，而效率取决于完成任务需要的时间长短。

工作能力强、效率高，意味着你可以做更难的任务以及可以比别人更快完成任务。

那么回到文章主题，要提升能力、工作效率，意味着我们要能接下难度更高的任务以及尽可能快地提高解决工作中各种各样问题的效率。要达成目标，那么初步可以从以下几个方面入手：

• 思维转换
• 工作习惯
• 基础技能
• 实用工具

二、思维转换

思维转换是从校园跨入到职场的第一个要学习的事情，即从学生思维到职场思维。

2.1 做好负面情绪管理

思维内核

最直观的区别，在学校，学生付钱，老师教导学生，你可以翘课；在公司，老板付钱，我们给公司打工，你不能翘班。身份不同，加上快节奏，会很容易带来一系列负面情绪问题，例如压力、烦躁、焦虑等等。

在学校的时候，可以逃避从而避免负面情绪产生，翘课睡觉、打游戏。但在工作中，即使凌晨三点发版，第二天还是得照常上班，这并不是一件令人开心的事，但也必须做。学会如何在工作中管理好自己的负面情绪非常重要，因为负面情绪会非常影响我们的工作效率，让我们较难达到工作目标。

因此，要有一个这样的思维，时刻记住自己是什么身份，管理好自己的负面情绪，不但有利于自己更好地达成自己的目标，也不会影响到其他同事。对于大多数人来说，都会选择在工作中面对并解决负面情绪，但如果实在顶不住，离职休息也算是解决负面情绪的一种手段。

个人经验

1. 今日事今日毕：我会尽可能地当天把想不通的问题解决掉，加班也要解掉，即使解决到 12 点或者 1 点，也会解到再下班。这样下班了也不会老是想着有东西没做完。
2. 好好吃饭：首先，我会尽可能保证三餐，这是最基本的健康保障；其次，偶尔来几顿，垃圾食品、炸鸡汉堡披萨之类的高热量、高碳水食物，让人放松；或者大餐，人均 500 起步那种海鲜大餐也挺过瘾
3. 在正确的场所干适合的事情：我会在公司，专注工作，把活儿干完；午休时间，睡半小时，别老是玩儿手机；下班了，专注休息，别想着工作；人类是有极限的，要有意识地让其休息，时间可以少，但必须要有
4. 做一些可以放松压力的事情：这个非常重要，其实从我个人角度来看就是去做一些非工作，但让自己又感觉有收获的事情。例如下班了，可以练琴、阅读、看电影；周末可以出去看看展览、公园散散步、玩玩摄影；对于我来说，周末在自习室学习或者写博客也是一件解压的事情；如果没有找到，就去不断尝试吧

2.2 工作方向很重要

思维内核

第一个要讨论的问题是关于「知识焦虑」。许多人在学生时期，甚至在工作了一段时间后都会焦虑于一类问题，例如公司用的是 gRPC 协议，在大学没有学过怎么办？公司业务需要用到 HDFS 、HIVE、DATA-X 开发，之前没有学过怎么办？

如果有这样的问题，说明陷入了思维误区。知识和技术是学不完的，在工作中也没有人能够融会贯通所有的技术。所以：不需要对「无法具备某个知识」有所焦虑，但在工作中需要具备快速学会某项技术或者知识，从而达成目标，这个目标可能是某个调研文档，可能是一个工程服务。

第二个要讨论的问题是关于「知识必要性」。现代互联网风潮影响下，许多人会去盲目追求新技术、新知识、熟悉源码的潮流，但这些内容是否有用，是建立在能否解决实际问题的基础上，如果脱离实际问题和需求，那么学习的技术就没有价值。久而久之会发现好像学习了很多知识，但解决的问题并没有很多，或者解决问题的能力并没有得到很大的提升。

以上两个问题，会发现都和工作方向挂钩，工作中做的每一件事都与「方向」有关，工作中总会走弯路，但需要不断往正确的方向靠拢，才能变得高效，工作方向需要我们自己不断思考，并与合作的同事或者领导不断同步、拉通对齐目标。

个人经验

1. 确定好任务目标：每次我接到一个任务，会先想清楚任务目标，也就是其终点是什么，跟派发任务的同事或 leader 做好同步。这个事情一定要自己思考并提出来自己的想法，而不是等着别人投喂，跟同事们对齐目标
2. 思考、梳理问题并沟通：初步确定好任务的目标后，我会梳理具体的每个问题点，列举式地记录下来；梳理过程中，会关注其他同事已有的材料，再通过工具分析，可能是脑图也可能会通过 Typora 简单记录；如果有些不清楚或者疑惑的问题，再次找同事们沟通讨论，但要先自己过一遍整个任务的流程，梳理出一堆问题再沟通，而不看一点就开始找他人讨论，这样效率不高
3. 围绕问题展开思考：对于新的书籍和技术的切入方向，我首先会关注它能解决什么问题，围绕着它要解决的问题点去思考它都做了哪些设计；第二个点，就是关注其发展的历史，每个阶段它是怎么进化的，都解决了什么问题

2.3 学会评估工作收益

思维内核

工作中我们往往会发现许多问题（NOTE：如果没有发现问题，那就得好好思考一下为什么自己没发现啥问题了），我们每解决一个问题就会给产品带来收益，但时间往往是有限的，我们需要进行合理地评估解决问题能带来的收益，尽量在规定的时间范围内，做一些高收益的事情。举个例子，有一些并发问题可能在 16C32G 配置下，在只有 100 QPS 时是很难触发的，那就把这种问题优化排后，而是去做一些能带来直观收益的事情，例如服务重构，或者基础组件的开发。

个人经验

1. 问题是否有必要现阶段解决：我的判断的依据很简单，从能否满足业务需求入手，例如功能性的问题就必须要解决了，但是一些性能问题、或者依赖升级是不需要现阶段解决的
2. 评估解决的问题对于个人提升有多少：如果有的选，我会尽量去做一些自己提升比较多的事情，比如能学会多少新的知识。举个例子，有些问题，可能我做了只是学习了一个 API，有些问题，可能我做了会学习到新的热门技术，或者新的协议，那么我可能会觉得后者是提升比较多的

2.4 工作并不是只有写代码

思维内核

写代码只是研发任务的其中一种，而且所有任务里面最简单的。从需求到上线，研发需要不断与合作的同事讨论同步，设计方案，同步方案，解决BUG，拉会协调等等。写代码是工作环节中最「不受重视」的一环，这么说是因为它已经简单和基础到要求每个研发都必须会的能力了，这已经成为了大家都共识，所以如果一个研发连代码都不会写，那是有非常大的问题的。

个人经验

1. 设计比编码重要：设计从小到大，都做细致，把手头上的业务逻辑的设计做好后，我会关注其他组，或者其他部门，看看其他人是怎么做设计方案的，看看有哪些可以汲取的
2. 码力要在线：想要提升码力，很简单，多写代码即可；我一般通过俩途径，第一个途径是做单测，积累代码量和锻炼基础抽象能力；第二个途径是做算法题，这里注意的是算法题基本分为数论题和数据结构题，对于我们做工程的，注重数据结构即可，例如，考察一下自己，实现个二叉堆，二叉树，LRU Cache 等基础或常用数据结构
3. 理清自己的逻辑促进更好的讨论：跟同组的同事沟通应该代价是最小的，接下来随着和其他组的研发、运维组、产品组沟通，代价都会逐渐变大，如何将自己的问题清除地让对方理解非常重要，我一般会在问题沟通前，先把一些截图，或者梳理出逻辑，发给要沟通的同事，而不是用嘴巴干讲，这有会比较抽象

2.5 不断学习的意识

思维内核

这里说的不断学习不是指什么下班了看看书，周末了看看教学视频这种的，这些只是表象和行为而已。味同嚼蜡。

目前来看，至少在国内的研发是不存在咸鱼的，要么不断学习跟上时代，要么被干，所以国内互联网公司（野鸡公司暂不讨论）都是高薪的，因为低薪的直接被干掉了，我们能看到的都是高薪的。

对于学习最重要的我觉得是「自我学习」的能力，这意味着要形成自我学习的意识，要培养这种意识也很简单：碰到一个问题，不用等别人给解决方案，而是赶在别人解决前就把它解掉。如果别人比我们更快解决了，或者解决方案更好，那就先学习他人的方案，不断积累，要具备这种先驱意识。这才是「不断学习」的核心，才是最重要的，在这个意识之下，可能会引发各种行为，例如「下班了看看书」之类的。

个人经验

1. 解决问题的意识 - 问题出现，在别人解决前解决它：工作过程中，经常有各种各样的问题，问题出现后，我会争取第一时间想出解决方案，并关注和学习其他问题的解决方案
2. 精益求精的意识 - 如果不够好，就尝试让其更好：如果我发现在已有的工程中存在一些能用的工具或者 API 方案能用，但是做的不好；或者发现了组内存在一些效率可以优化的过程，例如查看日志之类的，那么我会尝试去成为解决这些问题的人，而不是等着别人给我东西
3. 专注行业的意识 - 成为行业专家：时间是有限的，对于计算机，细分到每个领域的知识量已经足够巨大，需要我们再更聚焦于某一块的学习。对于我来说会关注以下几个点：Gartner 战略趋势分析、友商竞品、Youtube 行业公开讲座（英文）、行业技术的社区（例如 Github 中一些 topic 或者 treading 的板块、技术框架的在线社区像官方建立的 Discord、Slack）

三、工作习惯

建立起一些思维后，有一些不错的工作习惯值得分享给大家，这里直接分享我 2020 入职的时候到时，他发给我的原话吧，工作以来，无非是在坚持这些点而已

3.1 事前计划

「事前计划，做事不盲目，事后总结，经验常分享；」

讨论或者同步某些事情，准备好要讨论的材料，清单，做好规划。参与会议尤其是多人会议，要注意参与人力成本，要给出专业、高质量的工作内容；问题和解决方案可以常分享，因为同事们可能有更好的解决方案，或者新的 idea 可以吸收

我的个人经验：

1. 做编码前，对于复杂逻辑会先想清楚，根据设计方案梳理好代码备注，copy 到 IDE，然后对着备注写代码
2. 做设计前，会先梳理好逻辑为文本，然后 copy 到设计图，形成设计方案
3. 开会议前，会准备好材料，对于材料比较分散的情况，会做个索引，准备好连接或者目录点，快速将重点内容同步给参会人

3.2 记录的习惯

「养成做记录的习惯，无论大小会议，记录并形成行动项；」

研发的工作其实会有很多会议，或者工作内容挺多时候会比较杂乱，此时需要我们做好记录，并取其精华，形成要交付给其他同事的东西，或者用于自己后续工作的内容

我的个人经验：

1. 不定期做博客总结
2. 开会，做好会议纪要并提炼，有时对于不大理解的，或者内容比较多的会议，会录屏或者拍下关键内容，会后慢慢琢磨

3.3 互帮互助

「多跟其他同事交流，互相帮助；」

没有太多可说的，不要闭门造羹；多交流，多互助，总会有新的收获，团队的风气也会更好

我的个人经验：

1. 分享好工具
2. 参与到同事们遇到的问题，并给出解决方案，或者讲讲灵感

3.4 有能力的前提下主动承担更多任务

「做好本职工作的同时，可以主动承担更多任务，尽快提升能力，成为核心骨干。」

这里分享个 leader 入职时曾经说过的话，大概意思就是「把别人解决不了的难题解决了，那你就是个厉害的人」。做好本职的工作下，主动承担更多任务，更难的任务，能力就会提升的更快

我的个人经验：

1. 解决更多 Bug
2. 协助同事一起调研，给出调研建议
3. 引入一些能提高效率的解决方案，例如 Arthas 在研发环境查看日志、性能指标、JVM 信息；DEBUG 日志引入（包括热更新）

四、工具分享

工具分享可能是本篇文章最不重要的一环，因为工具总是更新迭代的，培养起 2.5 小节提到「不断学习」的意识，那么自然会发现一些好用的工具，发现工具也只是「不断学习」的一个过程行为而已，不过有好的、适合的工具，确实可以提高效率

4.1 OS

推荐：

• MacOS
• Linux CentOS
• Linux UbuntuOS

原因：对于研发，最好的情况下肯定是本地的开发环境和线上部署环境的系统一样，这样会最小化环境带来的差异产生的一些问题；如果没有其他特殊原因（例如客户部署就是 Win 环境），不推荐使用 Win 作为开发操作系统，因为会产生大量的「收益低」的问题，并且还必须要解决，才能继续下一步开发

4.2 Terminal

推荐：

• iTem2
• Tabby

原因：开源免费，iTerm2 插件极其丰富，性能高；Tabby 用于 SSH 连接管理，性能不错，有命令快捷键

4.3 IDE

推荐：Jetbrain 全家桶，某宝买个账号，一杯咖啡的费用，不需要花费力气去折腾激活码这些问题

原因：不需要原因解释，业界统一，且用自己的账号，不存在盗版问题

4.4 Git Tool

推荐：

• Jetbrain IDEA / PyCharm / WebStorm
• SourceTree

原因：Jetbrain 对于 Git 可视化解决冲突做的很不错；SourceTree 对于代码的可视化和 Submodule 的支持比 IDEA 更直观

4.5 Editor

推荐：

• Typora
• VS Code

原因：Typora 买断值，价格大于是周末和朋友一顿早茶的价格合适，满足记录类的工作需求；VS Code 开源免费，文本类查看需求和大日志文本文件查看（排查 BUG 需要）非常不错

4.6 SearchEngine

推荐：

• ChatGPT
• Google

原因：两个搜索引擎都很不错，可以解决大部分的技术疑问

4.7 S3 Client

推荐：

• mc

原因：开源免费，MinIO 官方做的命令行软件，用于 S3 的查看和管理，性能高，且高效

4.8 HTTP Client

推荐：

• Insomnia

原因：开源免费，仿佛就是不卡的 Postman

4.9 MindMap

推荐：

• Kityminder

原因：开源免费，百度做的脑图，性能比 Xmind 好很多，支持 md

五、工作分享

跨部门合作

跨部门合作是工作中常见的一个任务，2022 年与集团几个部门都有过相关的合作，以下分享我是怎么做这项任务的

1. 对于研发需求，我会梳理好需求或者设计方案，确定好各方需要交付的内容产物，并拉会同步需求，按年月日做好会议纪要和行动项，并发布到联调群；每天跟进两次需求研发进展，并及时同步问题；对于合作产生的风险，要做好文档记录以及是否风险是否解决
2. 对于推进进展，问题沟通不要私聊，我会摆出到联调群沟通，并 @ 通知相关人员；如果相关人员没有进展，那么打电话沟通，如果依然没有进展，那么在联调群 @ 其 +1领导 或者 +2 领导，说明目前问题事务的验证性；风险暴露非常关键，晨会同步也是暴露问题、暴露风险的一个好时机
3. 对于任务验收，我会结合需验收好其他部门交付的产物，例如其部署了新的服务，更新了 API 接口，要做好 API 测试，围绕需求出发，测好其是否能满足自己的需求；如果其更新了基础镜像，需要在镜像部署上跑跑核心业务流程，看其是否有问题
4. 对于问题排查，如果我自己的能力排查不了，或者自己的部门同事联合排查不了，那就将问题抽象为一个容易复现的方式，例如可能是做一个脚本，直接运行就能复现问题，并拉群，找各部门的研发讨论，让问题在能复现的情况下，大家一起参与分析排查

技术调研

技术调研也是我们工作中必不可少的一环，下面分享一下我是怎么做这个事儿的

1. 明确好调研需求，背景、要交出的对应产物
2. 问同学，技术群友、工龄长的同事有没有相关经验，汲取经验
3. 对于三方服务类调研，货比三家，试用服务，并记录其能力，形成并记录调研结论
4. 对于技术方案类调研，直接去 Google、Sourceforge、BitBucket 等开源站搜索对应的关键词，也可以问问 ChatGPT，找到方案后，要以试用的目标为导向，去确定技术方案的能力。一般技术方案的仓库会有 sample 工程，或者其组织会有 example 工程，例如 Spring 组织下，都会有一些能直接使用工程，快速跑起工程后，就参考 API 文档慢慢定制化需求改动，这个过程慢慢确定此方案是否满足需求，最后一样，货比三家，形成并记录结论；快速上手可以关注 Github 仓库的 WIKI Tag，会有入门文档，而仓库的的组织下可能会有其他写的 example 工程

六、结语

最后，分享我在工作中一直在坚持的原则吧。不论是什么任务，简单的或者难的，都精益求精，做细做好，交出自己能力范围内最好的东西。这里如果仔细思考，其实「最好」是不可能达到的，因为无论如何，总是会有更好的做法。