想要在职业生涯中取得进步者的实用建议

照片由 Simon English 在 Unsplash 拍摄。

嗨，欢迎你！

我的名字是贝诺特。我已经做了八年半的软件工程师。我在第一家也是前一家公司工作了七年半，然后在2022年初换到了另一家公司。

这篇文章源自最近我对希望早点开始做的一些事情以及希望做得不同的事情的反思。

我在这里分享的内容可能会对希望提升并成为高级开发人员及更高层次的初级到中级开发人员有用。

    **目录**   

     · 我的职业生涯演变  
    · 我希望早点开始做的事情：  
     ∘ 写工作日志  
     ∘ 勇敢走出舒适区  
     ∘ 对其他团队和项目保持兴趣  
     ∘ 加入轮班团队  
     ∘ 换到其他团队  
     ∘ 写博客文章  

    · 我希望我能够做得更不一样的事情：  
     ∘ 在向团队介绍新事物时要小心  
     ∘ 在团队面前不要让情绪控制自己  
     ∘ 尝试了解招聘市场  
    · 结语

我的职业成长之路

在进入正题之前，先来简单介绍一下我的职业经历。

1. 我在一家初创公司（该公司很快成长为一家规模扩大型公司）实习了三个月。
2. 在那之后，我边读书边工作了一年，花了三个月在学校，九个月在工作中。
3. 然后，我被聘为全职软件工程师，并在这个职位上工作了三年半。
4. 公司引入技术职业阶梯后不久，我被晋升为高级软件工程师。我在这个职位上工作了三年直到离开公司，当时技术团队大约有200人。
5. 我以软件工程师2的身份加入了一家拥有数千名技术员工的公司。尽管在第二家公司我的职位有所降级（参见大型科技公司招聘保守——为什么？），我一直试图保持与以前相同甚至更多的职责。

过去8年半我的职业发展如下所示。

最初，我是前端团队的一员。当时的技术组织把工程师分为前后端开发者。当时我们团队的人数不超过30人。一年后，新的CTO上任了，他引入了基于功能团队的组织模式，就像Spotify模型那样：Spotify模型。虽然一开始有些抵触（人们通常不喜欢变化），这次重组最终还是带来了积极的效果。

我在同一个特性团队待了超过五年。从它成立之初我就加入了，因此这些年里我成为了该项目的技术参考人。最终，我转到了另一个团队，在那里工作了一年后，我离开去开始一段全新的旅程。

好的，背景信息就说这么多。希望你喜欢继续读下去，也希望以下这些建议对你职业发展有帮助。

我希望能早点开始做的事情： 写写工作日记录

工作日志是日常的工作记录，记录你完成的任务。任务的具体性并不重要，只要你能记录你做了啥。

你可以按照你想要的频率填写这份文件。我建议你每周填写一次。周五时，你本周完成的任务还很新鲜，所以这不会很难。

这个工作日志为什么很重要呢？以下是两个原因：

• 回顾自己在过去6到12个月里所做的一切。这在绩效考核中非常有价值，这样你可以向你的经理展示你所取得的成就，并说明你为什么值得加薪或升职。
• 记录你在职业生涯中负责的项目、重要职责和关键数字（如为关键服务降低了X%的延迟）。这对于你在任何时候想要进入招聘市场时准备简历都大有帮助。

大约在我打算离开第一家公司的两年之前，我开始写工作日志。因此，在这八年半的时间里，我的工作日志里只有三年的数据（其中有些空白）。当我需要在2021年底写简历时，我不得不靠记忆回想我职业生涯前五年做的事情。至少可以说，回忆所有有价值的事情花了我不少时间，我确定漏掉了一些。

如果你需要，你可以用一个工作日志模板（比如这个）。我自己一开始用了两年的微软笔记，后来我转而使用带有项目符号的谷歌文档（每年一月到十二月都有一个列表）。

别总待在舒适区了

这是成为更好开发者的最好方法。舒适区是你感到舒适的工作范围和环境，包括你熟悉的工作伙伴、项目和责任。每天与你一起工作的熟悉队友，多年来的项目，你一直承担的责任，等等类似的内容。

但为什么他们会觉得你应该离开这种这么好的状况？因为这种环境不适合个人成长和发展。

当然，如果你待在这样一个圈子里，你就是一个高效的人。你知道该找谁聊聊某个特定的话题，以及哪个代码文件需要修改。但比起一个高效的人，多个高效的人岂不是更好？几个高效的人岂不是更棒？

一旦你在某个话题上感到自在了，就应该去寻找新的东西了。

• 指导他人，让他们在这个话题上感到轻松自在。
• 寻找舒适区之外的新鲜事物来尝试。

指导是高级职位的一个期望责任，它能帮助同事快速提高效率，是个很好的方法。这让你成为一个倍增器。

这里有一些灵感提示：新事物可以是任何东西，以下是一些例子：

• 为一个你以前从未接触过的团队或组织项目做出贡献，比如，因为这个项目一直由同一个熟悉它的同事负责。
• 写一份关于你熟悉的话题的文档。目的是分享你的知识，并间接指导他人，让他们比你更快地获得这些知识。此外，写作是一项值得学习和提升的技能，无论是撰写文档、电子邮件、即时消息、RFC（评论请求）还是博客文章等。
• 自愿参加跨团队项目。你甚至可以在这个过程中担任领导角色，这样既可以提升自己，又能帮助团队。
• 负责改进工具、监控系统或团队/组织流程。
• 参加公司组织的聚会或活动。
• 加入公司的社区或公会，参与组织层面的跨团队项目。
• 通过参与技术面试和/或检查候选人提交的家庭作业来帮助招聘团队。

目标是学习新事物。绩效回顾可以帮助你定义要做什么，以及当你走出舒适区时如何去做。但你不必等待这一刻来采取行动或做出改变。你可以在任何时候这样做，只要你的经理知情即可。例如，你可以在一对一会谈中讨论这个话题。你经理的核心目标之一是帮助你职业成长，所以我强烈建议在你离开舒适区之前与他们交谈。

有些科目你可能并不真正感兴趣。就我来说，有一段时间我对学习机器学习和数据分析这些内容毫无兴趣。但后来好奇心和求知欲还是让我走上了这条道路。虽然我没有机会在公司项目中应用这些领域的知识，我还是很高兴自己了解了它们。和同龄人进行有意义的对话真是太棒了，甚至能帮助我找到以前没有这些知识想都不敢想的新点子。

如果你想要在职业生涯中取得进步，我强烈建议你勇敢走出舒适区，每次有机会时都去学习新东西。我也觉得这些建议同样适用于你的个人生活。

多留心其他团队和项目的动向

这个和之前的差不多，不过你不需要承担额外的责任。

一直以来，我对团队范围之外的团队和项目的关心不多。我们的产品依赖于其他团队的服务，因此只要我们之间的 API 明确，我们无需了解服务细节。

我们唯一需要看看事情是如何运作的时候，就是我们需要为这些项目做出贡献的时候。由于我们被组织成了功能团队，如果我们需要在其他项目的某些地方做些改动，我们就得自己动手做这些改动。每个功能团队都有自己的路线图，所以我们一般不会要求其他团队帮忙，因为我们可以自己完成这些工作。虽然一开始我们进展缓慢，有了其他团队的帮助，我们慢慢在他们的项目上变得更加高效。

但对于我们没有直接互动的其他服务，我完全不知道它们是如何工作的，以及它们在系统中的确切作用。直到几年后我加入值班团队，我才真正开始了解公司的所有服务，这些服务是如何运作的。当我最终对所有服务有了全面的了解时，感觉非常棒。

• 当事情出错时，我对问题的原因有了更好的理解。
• 我知道为什么我们需要那个特定的服务/功能，或者为什么我们做出了那个数据存储的决定。
• 最后，经过多年为公司创造价值，当我把这些拼凑在一起时，那种“哦，现在我明白了”的感觉真是太爽了。

如果有机会，看看你公司里的其他项目和团队。阅读公司内部的维基页面，参加他们的演示，并阅读他们的公共文档。不需要长期投入，偶尔做一下就好。如果你能画一张图，写一份关于“整体情况”的文档那就更好了。这样做的话，组织里的人们肯定都会感谢你的。

请注意，这里你不需要产出任何结果，这与之前提到的在舒适区的建议不同。你所需要做的只是保持对新事物的好奇心，阅读其他团队提供的文档，并提问题。你可能会遇到其他团队的成员，你可能会发现一些你真正感兴趣的项目。

加入轮班团队

这可能感觉有争议，也可能在你公司行不通。当然，只有贵公司有健康的值班制度时，才值得考虑这条建议（参见软件工程师值班补偿机制）。

值班团队由那些愿意在工作时段和非工作时段（即晚上、周末及公共假期）介入处理问题的人组成。您的公司可能有一个专门的SRE（站点可靠性工程师）团队来负责这个值班工作，和您的团队可能不负责DevOps工作[1]。注：DevOps是指一组软件开发实践，详情请参阅https://aws.amazon.com/devops/what-is-devops/。

不过，如果有条件加入值班团队，是你正在工作的产品，还是整个公司（取决于公司的规模），我建议你加入。

加入这个团队有以下几个好处：

• 你了解到更多关于公司产品和服务的幕后情况。
• 当坏事发生时，特别是晚上，你会对同事产生更多的同理心，感受到那份责任的沉重。
• 你会对公司有更深的归属感，因为你将更多的时间投入到确保产品和服务满足客户期望的工作中。

再次强调，要有个健康的轮班制度，才能接手这些职责。

在我第一份工作的地方，我在我离开前大约两个月加入了值班团队（这些服务的值班团队）。要是早一点加入就好了，因为在那几个月里我学到了不少东西，这份额外的责任也让我觉得挺值得的。

在我第二份也是目前的工作中，我开始工作后两到三个月加入了值班团队（负责某一产品的服务）。目前，我仅在工作时间内介入，但将来，我最终将能够在晚上和周末响应值班召唤，以便及时处理可能的问题。

换队

我能看出你可能有三个理由想换团队。

• 现在的位置让你太舒服了，你想尝试跳出舒适区。
• 你不喜欢团队的项目或工作范围，更想从事自己喜欢的项目。
• 你和同事或经理的关系变糟了，你希望换个环境，但还想留在公司。

如果你发现自己处于以下这些情况中的一个，那么我建议你考虑换个团队，而不是直接辞职去找新公司。

换到一家新公司是很累人的，你可能会失去一些你真正看重的东西，比如同事、企业文化或员工福利。

我觉得团队跳换挺好的，原因有以下几点：

• 新团队的组织结构可能不同（团队仪式和工作方式），所以你可以在这个方面学到更多。
• 你可以带来你在前一个团队中学到的积极变化（改进代码审查流程、工具、库和仪式），从而成为公司内最佳实践的倡导者。
• 当新队友需要接手你之前团队的项目时，你可以帮助他们，这样知识就可以高效地从一个团队传播到另一个团队。
• 你可以学习新的工具、语言、库、架构以及解决问题的新方法。换句话说，你会成长为一个更优秀的开发者。
• 可能你会在更好的条件下工作，如果你的变动是因为前面提到的第2点或第3点原因。

在我离开第一家公司的那一年之前，我决定换到另一个小组。有几个团队邀请我加入他们的行列，要是我能把自己分成好几份就好了，我就会很开心地加入他们中的每一个。

当我加入新团队时，我觉得我的高级头衔不再合适了。我必须学习新的代码库、工具和实践。当然，我的软技能和对业务/产品的了解仍然保留着，但我的技术技能受到了削弱。学习新事物当然很棒，但我不再是团队的技术顾问了。尽管如此，每当团队需要为之前的项目提供支持时，我能更有效地提供帮助。随着时间的推移，我逐渐摆脱了“不配拥有这个头衔”的感觉，我通过不断学习和积累，变得更好。

总之，我认为换团队不该太频繁。我在第一个团队待了五年多点，然后就去了新团队待了一年，最后还是因与这个团队无关的原因离开了公司。

如果你觉得你的状况符合这三种原因之一，我会建议你考虑换到另一个团队，但至少要在当前团队待上一年。我认为一年是一个合理的时间，来看看你是否适合当前团队。如果你无法等待整整一年，那就说明情况很紧急，我会建议你找你的经理或他们的经理谈谈，来解决这种紧迫的问题。

写博客

这本来应该只是“写”，但感觉有点短。写作是开发者应该具备的必备技能之一。我们的日常工作中经常需要写作：代码、消息、邮件、文档、RFC（请求评论）、会议纪要、事故后的总结报告等。

写作是一种很好的异步交流方式。他们可以在方便的时候阅读你的消息，不会被打断当前的任务，可以专心处理。当然，在某些情况下，比如视频通话或面对面会议，同步交流更有效，以解决紧急问题或消除误会。但根据我的经验，开发者在日常中更多地用写作而非交谈。

写博客很有趣的原因有以下几点：

• 实践出真知。提高技能的唯一途径就是不断练习。如果你不确定自己是否做得正确，你可以向你认为在这方面做得不错的人求助，让他们指导你如何在这个主题上做得更好。你也可以阅读有关此主题的文档和博客文章。说到底，最重要的是开始练习，即使你的第一篇文章还存在一些问题。
• 它迫使你了解你所谈论的主题。这是真正学习事物的好方法——深入研究特定主题。
• 它有助于发展你的个人品牌。越多人对你的博客文章感兴趣，你就会吸引到更多的追随者，你的影响力也会随之增大。

你可以在个人博客上写文章，也可以在公司博客上写文章。刚开始为公司写文章是个不错的选择，因为它已经有了固定的读者群。不过，你谈论的话题范围会受到限制，因为公司会决定讨论的话题。

不要指望一写完第一篇博客文章就会变得受欢迎。成为有影响力的人需要很长的时间，这并不是一蹴而就的。你甚至可能根本无法达到那个时刻，但这也没关系。你应该为了自己而写，用以提升你的写作技巧，并与社区分享你的发现。你不必担心能获得多少点赞或关注。获得这种认可确实会让你感到鼓舞，但你的目标不应仅仅是增加这些数字。你的目标始终应该是提高你的写作水平，并与大家分享你的知识。

我通过在我的第一家公司工程博客上发布开始了一段旅程：在网页浏览器中安排函数的最准确方式。甚至被提到在[JavaScript Weekly 通讯]中，这让我感觉非常棒。

然后，在2021年3月的时候，我开始在Dev.to写博客文章，并且偶尔还会继续写。我也在HackerNoon上发布了一篇文章，但我不太喜欢他们对标题的编辑，我觉得Dev.to会是我的主要博客平台，至少目前来说。

我希望当初能做些不同的事 小心地向团队介绍新事物

这尤其在你职位越往上走时更加正确，不过即使是新人也应该觉得自己有能力为团队带来新事物，无论是库、语言、编程范式、协作模式等。作为一名新人，你可能会更容易受到团队中资深成员的挑战。然而，越往上走，说服别人，尤其是新人，接受你的想法就越容易。

在我第一个公司里，在转到另一个团队的几个月前，我已经学习函数式编程范式大约两年了，并且坚信它的好处和优势。那个时候，我能够提议对代码库进行一些雄心勃勃的更改。

在几个月的时间里，我向包括我所在的两个团队介绍了函数式编程的概念和思想。记录在案，这些讲解发生在我还没有对代码库进行大规模改动之前。

我认为这些培训课程足够说服人们采纳这个新的思维方式。而在那一刻，的确是这样：人们在点头赞同。他们理解了新概念及其利弊，并知道了我们可以用来改进项目的工具。

在一系列展示之后，我们发现了一个机会：

• 那到了夏天，所以未来几月里业务活动会相当缓慢。
• 在今年上半年，我们遇到了一些bug，并且不得不在一个老旧系统中使用一些临时手段。
• 我们可以通过一些方法大幅提升该系统的可测试性和开发体验，借助函数式编程思想和TypeScript（简称TS）的类型。该旧系统最初是用TS的一个早期版本开发的，当时其类型特性并不完善。

换句话说，这是进行一些重构的绝佳时机！我向团队展示了使用TS进行函数式和类型级别编程的概念验证，极大地改进了该系统。我们都认为它的好处，并决定进一步实现一个生产就绪的版本。我负责任务的创建和规划哪些工作可以并行完成等。我定期向Slack频道发布更新，以便所有利益相关者可以跟踪进度。

我将系统v2作为库开发在我们自己的代码库中，使其成为一个可以独立测试的模块。我们能够测试所有可能的边界情况，由于副作用得到了控制，我们使用了单元测试。尽管引入了很多新的概念、功能和代码变更，大家对此都很满意。我在代码审查中得到了批准通过。

我深受启发于fp-ts库，它的编码方式与“常规的JavaScript”有所不同。由于一些不便透露的限制，我们不能直接在代码库中导入该库，所以我不得不自己重新引入了一些函数和数据类型，并稍作调整。我还做了更多关于这些变化的演讲，并且得到了积极的反馈。

没有反对的声音让我继续越陷越深。

新系统完成后并通过测试，我们必须替换掉分散在代码库各处的旧系统。它在很多地方被使用，因此从旧系统迁移到新系统的过程结果发现非常繁琐。

我这辈子从来没有这么拼命工作过。我喜欢将旧代码重构成我认为更好的样子，所以我没怎么在意时间。两个月下来，每天差不多都要花上十个小时，连周末也不例外。

工作完成后，我请了两周假（这计划已久）。在我离开期间，团队不幸遇到了一个相当重要的事故。他们努力找出根本原因并解决它。问题出现在新系统内部，这个系统与其他代码库明显不同。因为我几乎是唯一开发这个系统的人，团队对它不太熟悉。

在我的演讲中，人们理解并接受了这些新工具和新实践。但当他们独自面对这一切新事物时，自然会感到迷失。

演示很重要，但如果你不练习新学的知识，你最终会忘记这些。另外，单独讲解每个概念与一起使用是不同的。这给本来就难学的课题增加了更多复杂性。

简单来说，我在团队中引入了许多新概念，他们在我的演示中虽然表示赞同，但在我离开后带来的项目变更极大地影响了他们解决这个关键问题的能力。

当我回来听说这件事后，我主动提出与他们分享更多的演示文稿，让他们更快地熟悉代码。

实际上，我根本就不应该去探索那个兔子洞。这根本不是一个实际的解决办法。那些类型改进确实不错，但整个新的功能系统却是一个错误。

你不应该仅仅因为你对这些变化感到舒服就进行重要调整。你得记住要考虑到bus factor。我原以为自己能在那个团队待足够久的时间，让大家最终熟悉新代码，并且可以慢慢教他们。

但是，在这些事件发生后的几个月，我又加入了一个新的团队。回想起来，我为自己在离开前几个月把这个难以维护的模块丢给了别人而感到难过，并且几乎把自己累坏了。

无论你是个人贡献者（又称IC）还是管理者，如果一位资深队友提出了这样的重要改动，我强烈建议你认真地质疑他们的提议。我相信像我这样的情况下本可以找到更好的平衡点。

如果你也像我一样处于这种境地，我建议你仔细考虑一下。这真的是一种实际的解决方案吗？你确定范围已经明确，所有潜在问题都已经被识别了吗？你是为团队着想还是仅仅因为你喜欢做这件事？当你不在时，团队是否依然觉得这样合适？

别让你的情绪在团队面前不受控制

有时，我强烈不同意经理或同事在会议上提出的意见。我当众表示我对此感到不满，从而公开地表达了不同意见。

我想向我的同伴展示，不同意别人的决定也没问题。但是，这并不是一个健康的反应。

• 当冲突变得明显时，人们可能会感到不舒服，就像在这些情况下一样。把他们置于这些情境中是不公正的。
• 这可能会在团队内部造成分裂，使得一些人支持A，另一些人支持B。团队必须保持团结才能高效运作。
• 总的来说，这显示出一定程度的缺乏自制力和纪律性，以及缺乏从不同角度审视情况的能力。

我说的并不是说控制情绪很容易。毕竟，毕竟，我们是人类，不是机器。但是，也要尊重同事，避免干扰会议进程。

在我看来，正确的做法是等到会议结束，然后马上采取行动。

• 去和对方私下谈谈。
• 和你经理聊聊这个情况，并找到解决的办法。

会议后感到情绪激动，这种时候要立即进行一对一谈话，拖延时间会让情况变得更糟。

根据我的经验，与对方交谈总是有助于改善情况，让事情变得更好。沟通在这里是关键。没有社交互动，我们在公司（或个人生活中）就无法取得显著的进步。

试一下招聘市场的行情

当我作为实习生加入第一家公司的那一刻，我和未来的经理进行了一次30分钟的面试。就这样。我快速地进行了一次“文化适应性”面试，就这样被接受了。

七年半的时间里，我没有踏入过招聘市场。一旦我决定离职，那次短暂的招聘经历显然无法代表即将面对的情况。当你申请一个有大约八年工作经验的高级职位时，招聘过程绝对不仅限于一个“30分钟的行为面试”。

读了《历史上最火热的技术就业市场》这篇文章之后，我觉得自己已经准备好了去试试看。我更新了我的领英资料，然后将自己设为“开放工作机会”。

我感到非常不知所措。处理这些职位提案让我精疲力尽。从2021年9月到10月，我每天都要收到5到10个职位提案。我不得不请了几天假来应对这种情况，我几乎每个周末都在处理这些提案。

最初，我都能回复招聘者的消息。但后来情况变了，当我遇到以下情况时：

• 当时我还在目前的公司上班，所以一整天都在忙工作。
• 当时我正在搬到另一个城市，这让我感到相当有压力。
• 我在几家公司的招聘流程中帮忙。
• 我不断接到新的工作邀请。

回复新收到的招聘信息变得越来越吃力。

我最终自己编写了一个消息模板，包含了我对下一份工作的期望。我尽可能地详细描述了这些信息：公司的规模、工程文化、是否可以远程工作、薪酬、技术挑战等等。但即使这样，我忙于处理这些消息，根本无法跟上。

对于当时联系过我但没能回复的所有招聘顾问，我感到很抱歉。我当时感到非常困扰。

但处理 LinkedIn 的消息并不是最难的部分。最累的是面试。我之前根本没有机会练习过 DSA（数据结构与算法），因为我从来没有想过换工作。

我主要在leetcode上练习，并且还买了一些书来帮助我学习。

• Cracking the Coding Interview 作者是 Gayle Laakmann McDowell。
• 系统设计面试 第一卷 作者是 Alex Xu

此外，我还必须记住并详细说明我参与的最具影响力的一些项目。之前提到的工作日志在这里可以是非常有用的资源。

当我终于接受了一份 offer 之后，我向我的经理递交了辞职信。如果我没记错的话，这次的新 offer 给了我比原来高 25% 的基本工资增加。还有一些额外的补偿也被包括了进去，总的来说，对于我这种（远程工作）的情况，员工福利更好。

我时不时地鼓励你去尝试面试，因为这对于你的个人发展很有帮助。

• 在这个过程中，你会获得一些经验，所以当你最终进入一家新公司时，你会感觉没那么不知所措。
• 你可以检查一下自己在市场上的价值，或者向当前公司提出一些薪资调整。如果你能得到一份工作 offer，这可能帮助你从当前公司拿到应得的报酬。

在我的第一家公司的刚开始的几年里，我得到了不错的加薪（每年7%到10%），除了最后一年。尽管我对最后一年的加薪不满意，但在我总是以为在下一年我应该能得到更好的加薪。然而，那个时刻再也没有到来过，因为我在此之前已经辞职了。

由于我在那家公司大部分的职业生涯中得到了不错的加薪，我从来没有想过要去看看自己在招聘市场上的价值。我希望我早些时候就做了这件事。这并不一定意味着我会更早离开公司，但至少我可以获得一些经验，并且我本可以尝试要求调整薪资而不是加薪。

别误解我的意思：拿到10%的加薪很棒。但如果你的工资比市场平均水平低15%到20%，那么最终，这10%的加薪就不够了。那么你怎样才能知道自己是否得到了应有的薪酬呢？通过亲自体验一下市场。另外，通过与那些以前的同事们保持联系或定期交流。

做面试并不意味着你必须离开公司，但是你可以利用业余时间做很多次面试，只要你不耽误当前工作。只要你在不影响工作的前提下进行，你就可以在自己的公司做这些面试。这就是为什么我请了几天假，所以我常常一大早或午休时间做面试。

结束语

首先，感谢您读到这里！希望这篇文章对您有所帮助。您应该注意到了，这些建议都比较偏向软技能。大部分建议都侧重于软技能。也许我以后会写一篇更侧重技术技能或硬技能的文章。如果您对此感兴趣，可以告诉我一声哦。

最后想和大家分享的一点是：和一些以前的同事保持联系，特别是那些曾经激励过你的同事。你之所以钦佩他们，是因为他们符合你的标准。他们可能是出色的管理者，也可能是有影响力的领导者，你非常欣赏他们。这很重要，因为他们会帮助你进步，成为更好的开发者。只要频率合理，这就有益。他们甚至可能说服你加入他们的公司/团队。每个人都应该建立一个帮助他们变得更好的网络。

如果你有空试试这条建议，如果它对你管用，请分享你的经历，。我真的很想知道这条建议的反馈，看看它是否也能在其他情况下起作用，而不仅仅是我的情况。

一如既往，欢迎在评论区留言分享你的想法！下次见哦 :).

本文最初发表在_ Dev.to .