给初级开发人员的职业建议

刚入行的软件工程师经常问我：“怎样才能快速提升自己？”

换句话说，我怎样才能在最短的时间内成为一名高效的贡献者？我怎样才能熟悉我们庞大的代码库？我怎样才能学习到所有我应该知道的知识？

即使是资深工程师，开始一份新工作也可能压力巨大，而对于第一份编程工作来说，压力更是难以承受。因此，让我们来看看初级开发人员提升技能的四种策略，以便您能够迅速上手。

1. 多问问题

首先，要多问问题。更重要的是，不要害怕提问。鼓起勇气提问可能很难，因为这意味着承认自己并非无所不知。但你为什么要无所不知呢？软件工程领域如此广阔，没有人能够精通所有知识。

提问，尤其是在公司 Slack 频道等开放论坛上提问，会让你处于一种不安全的状态。你可能会想：“别人会不会因为我不懂而瞧不起我？我会不会因此失去作为软件工程师的信誉？” 在这种时候，重要的是要提醒自己以下几点：

首先，每个人都必须从某个地方开始。即使是拥有30年经验的软件工程师，也曾经和你一样，在这个庞大的行业中摸索前行。

其次，如果你有问题，很可能其他人也有同样的问题。鼓起勇气提问，不仅对你有帮助，对你的同事也有好处。

第三，冒名顶替综合症会影响每个人。每个人都会在某个时刻觉得自己不够优秀，觉得自己不配待在现在的位置上，觉得如果同事发现他们懂得很少，就会揭穿他们的骗子身份。不要听信这种声音。

第四，在公共论坛提问，就相当于创建了一个文档，方便日后查阅。所以我总是鼓励那些在 Slack 上给我发私信的工程师，把问题发布到公共的 Slack 频道里。这样一来，整个团队或组织都可以参与讨论，帮助解答问题；其他有同样疑问的人也能从中受益；而且，以后有类似问题的人也能搜索到相关的讨论内容。

现在，我想对那些被问到问题的工程师们说几句：在公共论坛上提问，意味着你们肩负着一份神圣的信任。公司的文化由你们来决定。你们的公司和团队是否营造了一种心理安全的环境，让大家可以自由提问而不会受到责备或轻视？请谨慎回应，以免营造出一种同事不敢畅所欲言的氛围。

谷歌曾进行一项研究，旨在确定哪些因素有助于打造高效团队，结果发现心理安全感是首要因素。团队成员需要感到安全，并且能够在彼此面前展现脆弱的一面。

那么，作为一名初级开发人员，为了提高工作效率，你应该问哪些问题呢？以下是一些例子：

• 能否给我详细介绍一下我们应用程序的架构？我们使用了哪些框架和库？
• 能否给我介绍一下我们的代码库目录结构？代码都放在哪里？它是如何组织的？
• 开发流程是怎样的？我们使用哪种Git 工作流程？
• 发布流程是怎样的？新代码如何部署到生产环境？新代码的发布频率如何？
• 为什么[功能X]要以这种方式实现？
• 为什么我们使用[库A]而不是[库B]？

事实上，这些都是任何人在开始一份新工作时都应该问的好问题，而不仅仅是初级开发人员。

2. 需要帮助时要寻求帮助

同样，当你需要帮助时，寻求帮助也很重要。

攻克难题是学习如何解决问题和排除故障的关键环节。如果总有人在你身边手把手地教你，你的进步速度就会慢下来。但是，到了某个阶段，承认自己需要帮助才是更明智的选择。

一个很好的经验法则是：如果你遇到难题，先尝试 15 分钟，如果仍然无法解决，就必须寻求帮助。

这相当于给你的任务设定了一个时间限制。它还要求你在寻求帮助之前花更多时间思考问题，这样你就不能轻易放弃。更重要的是，时间限制可能会激励你尽快找到答案，因为你或许真的不想寻求帮助！

如果15分钟时限已过，你仍然感觉束手无策，那就必须寻求帮助。你或许觉得独自苦苦钻研是高尚的，但请记住，你是拿工资的。如果同事能给你一些提示帮你快速解决问题，那么花费数小时却毫无进展，这在经济上是不负责任的。你的队友可以成为你的宝贵资源，他们随时准备提供帮助。

无论他们是否意识到，经验丰富的教师和导师在帮助初级学习者时，常常会运用维果茨基的最近发展区理论以及支架式教学法。最近发展区（ZPD）指的是“学习者无需帮助就能完成的任务，与在拥有更多知识或专业技能的人的帮助下能够完成的任务之间的差距”。支架式教学法是一种指导学生在最近发展区内学习的技巧。

因此，一位有益的导师会给予初级开发人员足够的指导，使他们能够完成任务；或者，导师会提供足够的信息，帮助他们解决在开发的任何阶段遇到的障碍。

3. 持续学习

软件工程领域瞬息万变。新的语言不断涌现，曾经流行的库和框架被新兴的替代方案取代，设计潮流也来来去去。为了跟上这个快节奏的世界，你必须持续学习。软件工程师并非只是上大学或参加开发训练营，毕业后找到工作，然后就从此不再学习任何新知识。学习是我们每天都在做的事情。

“一万小时定律”因马尔科姆·格拉德威尔2008年出版的《异类》一书而广为人知。该定律指出，大约需要一万小时的练习才能成为某方面的专家。虽然练习越多，技艺越精湛，这听起来合情合理，但自该书出版以来，“一万小时定律”已被多次驳斥。

事实证明，真正重要的不仅是练习的量，还有练习的方法。“练习”和“刻意练习”之间是有区别的。

学习乐器时，练习的方式和内容都必须有意识地安排。如果你在学习一首特定的歌曲，不能只是反复练习。每次都从头到尾演奏一遍是无效的。歌曲中很可能有些部分比其他部分更难。如果你进行有针对性的练习，可以反复练习相同的四个小节，直到熟练掌握，然后再继续练习歌曲的其他部分。

同样的道理也适用于软件工程。不要浑浑噩噩地混日子，要目标明确地学习你想要学习的内容。

如果你觉得编写单元测试很困难，那就去Pluralsight上花两个小时学习使用Jest（或任何与你的编程语言相关的测试框架）进行单元测试的课程吧。

如果你想学习React，那就去读读文档吧——React 的文档真的很好！

务必了解公司使用的一些基本技术。熟悉AWS、Heroku或您使用的任何IaaS/PaaS 提供商。如果您是前端开发人员，请学习公司使用的 UI 框架或库，例如Angular、React或Vue。如果您经常使用数据库，请了解SQL 和 NoSQL 数据库之间的区别，以及它们各自的优缺点。

换句话说，要抽出时间“磨利锯子”。这个术语由史蒂芬·柯维提出，是他著作《高效能人士的七个习惯》中的最后一个习惯。引用柯维博士的话说：“我们绝不能因为忙于锯东西而忽略了磨利锯子。”

人们很容易陷入只在工作时间内完成任务的误区。毕竟，你还在上班时间，雇主付你工资让你来上班，所以你应该“工作”，对吧？然而，这种想法是短视的。这就像用锯子砍一棵大树，却从不磨锯子，一砍就是几个小时。磨锯子的时间就没用来砍树。但是，锯子越锋利，切割效率就越高。实际上，你用磨锯子的时间砍树的速度会比不磨锯子的时间更快。

优秀的雇主都明白这个道理，他们会积极鼓励员工每周抽出几个小时进行有意识的学习。不要因为在工作时间阅读文章或观看视频教程而感到内疚。当你把这些学习作为刻意提升技能的一部分时，你将会成为一名比只专注于工作任务更高效的工程师。

4. 参与代码审查

最后，积极参与代码审查。所有正规的软件公司都建立了代码审查流程，以确保代码库的高质量。代码审查通常被视为一种把关机制——确保使用了良好的设计模式，代码简洁清晰，经过充分测试，并避免潜在的负面影响。

但或许同样重要的是，代码审查也是一个知识共享的过程。当你创建一个新的合并请求并邀请其他人审查你的代码时，你实际上是在邀请他们提供反馈。他们可能会提出各种各样的建议：代码重构的方法、更优的数据结构或设计模式，以及你尚未掌握的违反最佳实践的地方。代码审查是最佳的学习机会之一，而且它已经融入到开发流程中！

代码审查可能会让人情绪波动。毕竟，你是在请求别人对你的作品进行评价，所以很容易让自尊心作祟。遇到这种情况，不妨冷静下来，记住：即使你的代码中有些部分写得不好，也不代表你就是个糟糕的开发者。放下自尊心，记住最终目标是编写高质量的代码并分享知识。

准备合并请求时，务必尊重代码审查者的时间。他们抽出时间来帮助你，所以请确保提交信息清晰明了，合并请求描述详尽易懂，并且你已经亲自审查过代码。作为代码审查者，最令人沮丧的事情莫过于审查缺乏上下文的代码，或者到处都是注释掉的代码和格式混乱的代码。我读过的关于这方面最好的建议来自 Michael Lynch 的文章《如何让你的代码审查者爱上你》。

另一方面，不要害怕审阅其他工程师的代码，即使是资深工程师的代码。人无完人，资深工程师也会犯错。通过审阅经验更丰富的工程师的代码，你可以了解他们如何编写代码、构建代码结构、命名变量以及解决复杂问题。通过观察并模仿资深同事的编码风格，你可以快速提升自己代码的质量。

谷歌为代码审查员和被审查代码的代码作者都提供了非常好的指导方针。我强烈建议两份都阅读一下。

结论

如果你只能从这篇文章中记住一件事，我希望你记住：学习要有目的性。弄清楚你需要知道什么，以及你想知道什么，然后专注于这些。认真练习。保持好奇心。渴望学习。拥有这种心态将引领你走上成功职业生涯的正确道路。

祝你好运！