如何成为更好的软件开发人员

英文原文： https://medium.com/devtrailsio/how-to-become-a-better-software-developer-dd16072c974e

今天，我想分享一些关于软件开发人员如何提高他们的专业技能并在工作中变得更好的想法。这里提出的主题是通用的，并不是特定于任何技术堆栈。就此而言，其中大部分都不是特定于IT的。这些是关于如何发展您的个人特征，改善与同事和客户的协作以及推进您作为软件开发人员的职业生涯的一般建议。

本文中的一些内容是主观的，反映了我的个人经历，而其他内容已被其他人采用并成功使用。

理解端到端的过程

许多开发人员认为软件开发完全是关于编码的，而其他一切只是让人讨厌并浪费宝贵时间的人。这不能远离真相。在您编写一个软件代码之前，它会经历一个从模糊的想法转变为精心设计的解决方案的过程，以便实施。在您将最新的更改推送到Git之后，软件正在进行测试，部署，监控，分析和改进。编码只是该过程的众多步骤之一。

那么为什么会这样呢？通常，特别是在大型组织中工作时，项目的不同阶段由不同的团队甚至部门处理。这一切都始于收集需求的业务分析师。然后将要求移交给为开发人员生成模型的设计人员。开发人员编写代码并将结果提供给QA工程师。如果一切正常，则会将工件发送给将其交付给最终用户的运营团队。该过程被视为一组离散步骤而没有任何反馈。由于各部门之间缺乏沟通，他们的代表往往不了解他人的目标，这会导致误解，甚至冲突。

对于现在的许多人来说，这听起来有点过分夸张。随着敏捷方法的兴起，越来越多的公司从这种僵化的方式转向由混合专业人士组成的小型团队。但即便如此，我们也看到人们并没有真正去了解别人的工作。您经常对设计师感到烦恼，因为他们希望您实现一个过于耗时的自定义复选框？反之亦然，受到批评，因为你忘了使用正确的字体。

只要关注他人的工作，就可以克服很多这些差异。与您的设计师坐下来解释他，实现自定义复选框需要一段时间，并且有一个库可以提供您可以重复使用的不同类似的复选框。作为回报，学习排版的基础知识并理解为什么选择正确的字体会产生影响。对经理，业务分析师，QA工程师，支持和营销专家持同样的态度。引用T. Huxley：

尝试学习关于某事的一切事物。

通过向每个人学习，您将能够预测他们的需求，缩短反馈循环并实现更频繁的交付。此外，它将赢得所有其他人的爱和尊重。

了解客户的需求

您需要了解有关客户的一件重要事情：他们不了解您正在做的大部分事情。敏捷，函数式编程或非关系型数据库对他们来说都是黑暗的。即使那些密切关注你的工作并且真正感兴趣的人仍然大部分都处于黑暗中。这有几个后果。

为他们招聘软件开发人员需要一定程度的信任。人们往往因为不理解他们需要付出很多钱而感到不舒服。记得上次你走进一个不熟悉的汽车维修服务，并不确定你是否可以信任他们的乘车？那么，你的客户有同样的感觉。除了没有汽车，只有一大堆抽象的非有形概念应该以某种方式实现产品和收入。与新客户合作时，获得他们的信任非常重要。确保他们了解您的操作方式，并以更小但频繁的迭代次数提供结果。通过这种方式，他们可以看到您的工作进度，评估中间结果并提供反馈。

通常，客户倾向于提出自己的解决方案而不是分享他们的问题。由于他们对您的能力知之甚少，因此他们的解决方案经常被误判，低估或过于雄心勃勃。还记得Henry Ford引用的旧（也可能是虚构的）：

如果我问过人们他们想要什么，他们会说更快的马。

有时候邀请他们退后一步讨论他们想要解决的问题，而不是顺其自然而且默默地实现客户想要的任何东西。结合他们的领域知识和技术专长，您可能会找到更好的解决方案。

请记住，并非所有人都喜欢对他们的想法提出质疑，而这种策略要求您有一些机智并激发客户眼中的信心。您还需要离开自己的舒适区并沉浸在自己的业务中，以便能够理解问题并提出更好的解决方案。如果您正在复杂的行业（如金融或医疗保健）工作，这可能具有挑战性。但如果你把它拉下来一次，那么下次客户会以更开放的心态返回时很可能。

为工作挑选合适的工具

如果你拥有的只是一把锤子，那么一切看起来都像钉子。

通常只学习单一技术的开发人员会将其应用于遇到的每个问题。不出所料，这种方法导致次优结果。相反，在解决新问题时，请暂停并思考您所使用的 工具 是否真的适合此类工作。如果您有疑问，请稍微调查一下，然后列出一些可能更好的替代方案。为了更容易，编译一个问题列表并逐个评估不同的选项。每个评估的问题可能不同，但它可以沿着以下方式进行：

• 它必须支持哪些平台或设备？
• 什么是非功能性要求，例如性能或内存使用情况？
• 购买许可证是一种选择，还是需要免费或开源的东西？
• 该解决方案是否提供了开箱即用的所有功能，或者您需要自己编写一些东西吗？
• 您是否有任何其他限制，例如公司政策，法律考虑或团队中缺乏专家？

回答这些问题可以帮助您构建头脑中的选项，并将其缩小到候选人名单。

Experiment Safely

那么如果你认识的东西都不适合你的情况并且你想尝试一些新东西会发生什么呢？你没有经历某事的这一事实并不意味着它是不可能的。这只是意味着您需要考虑一些额外的事情：

• 你有足够的时间准备吗？ 如果项目的时间表没有压力，您可以在开始实施之前尽可能多地学习，并在整个过程中学习其余部分。或者至少采用“ fake it till you make it “接近并说服客户，你知道你在做什么。
• 确定首先需要测试的内容。 Take the “ fail fast “在完成实验之前，”接近并确定您需要评估的关键事项。怀疑系统的性能？构建一个最小的原型并运行负载测试。不确定特定库或与外部服务集成？单独实现，然后构建其余部分。

请记住，走这条路仍然对您和您的客户都有风险，他们需要了解风险和潜在的好处。毕竟，从长远来看，为期两周的调查可能会节省数月的工作，这听起来很不错。即使实验失败，你也只会失去两周。您对客户的信任度越高，他们就越可能同意这样的事情。

建立在巨人的肩膀上

IT人员通常有两个共同特征：我们有创造力，我们喜欢我们的工作。这听起来像是一件好事，但它带来了一个尴尬的副作用：我们倾向于为之前已经解决的问题提出我们自己的解决方案。因此，每当我们面临选择是使用框架，库或服务还是自己实现它时，我们倾向于选择后者。这就把我们带到了重新发明轮子的徒劳之旅。导致这种情况的一些常见误解是：

• 自己实施一些东西比学习第三方解决方案更容易。 虽然这可能是一个完全正确的理由，但重要的是不要过度简化手头的任务。通常情况下，开始时似乎很简单，但随着进步而变得更加困难。最终，您最终可能会花费大量时间来处理有人可能为您处理的错误和边缘情况。
• 这个解决方案比我需要的更多。 除非有特殊原因导致这是一件坏事，例如增加生成的工件的大小，增加潜在的漏洞或大大减慢构建速度，这通常不是一件坏事。您最终可能会在以后需要它。另一方面，添加整个库只使用一个函数可能是一种矫枉过正。
• 我们可以做得更好。 尽管有一些成功的项目以这些词开头，但通常情况并非如此。质量第三方解决方案由具有解决此特定问题的经验和资源的团队维护。要与他们竞争，您需要能够进行更多投资。大多数项目既没有资源也没有必要这样做。
• 代码所有权和长期维护将成为一个问题。 有些人担心，如果你使用第三方解决方案，你可能会因为某种原因而在某些时候放弃或无法使用该项目。产品锁定的风险是真实的，您应该考虑可能的缓解策略。如果它是一个开源项目，您是否有可能自行分叉并维护？或者，如果它是一个专有项目，更换它需要多少钱？基于这些输入，您可以有意识地决定是否值得冒风险。

通过重新实现来学习

这个故事还有另一面。重新实现一些东西实际上是一种很好的学习方式。虽然为生产项目编写自己的框架几乎总是一个坏主意，但将其创建为学习练习可能非常有价值。有什么更好的方法可以通过解决同样的问题来熟悉它解决的问题。不要太深入兔子洞，简化粗略的实施将足以让你了解情况。

当你在这里时，不要回避窥视类似项目的来源。研究开源项目的代码将使您从更多经验丰富的开发人员的经验中受益。

研究你的工作方式

不仅在技术方面，而且在方法论方面努力改进。就像正确设计和优化的软件一样，完善的工作流程将使您能够以更少的工作量和压力工作，同时产生更好的结果。建立一个有效和高效的工作流程并非易事，而且有很多关于这一主题的书籍和材料。但首先，请考虑以下几个方面进行改进：

• 团队和项目管理方法。 由于我们大多数人都是团队合作，因此采用一种可以改善协作并为每个人建立共同工作节奏的流程非常重要。软件开发中的敏捷运动催生了许多广泛采用的方法，例如 Scrum or Kanban 。它们有助于组织整体工作结构，但不包括所有内容。还有其他方法可以帮助您进行估算，确定问题的优先级，改善沟通等。您需要确定您正在努力解决的领域，并寻找有助于解决困难的最佳实践。
• Personal processes. 像管弦乐队一样，有效的团队必须具有相同的节奏，但这并不意味着每个人都必须以相同的方式工作。每个人都有自己的偏好，应该以提高工作效率的方式工作。例如，许多人不喜欢在编码时被打扰几个小时，但我个人喜欢短时间工作一两小时，中断之间（不太严格的版本） pomodoro technique ）。我也不喜欢在家工作，以避免与家庭有关的分心，更喜欢在办公室或咖啡馆工作。找出适合您的方法并坚持下去，同时确保您的习惯不会给其他团队成员带来麻烦。
• 工程实践 。许多实践都存在于技术和方法之间的边界上，并侧重于改进实际的开发过程。例如， test-driven development and behavior-driven development 帮助保持代码库的良好结构和测试。 Code reviews 有助于减少代码中的缺陷，并在团队中传播知识。 Continuous integration and continuous delivery 确保更简单，更安全的部署过程。将这些实践与其他组织方法结合使用可获得最佳结果。

请记住，没有适用于所有人的流程，您需要在自己的环境中进行试用。此外，请确保您完全理解该过程并正确实施。向已经完成整个过程并从他们的经验中受益的团队寻求建议。不要忽视有助于您采用流程的软件和材料工具。获得真正的看板和现代化的持续交付平台。采用新工艺需要付出努力，甚至可能导致短期的生产力损失。给它一些时间，然后评估事情是否有所改善。

Remove obstacles

在解决障碍时必须另外说一点。忽视可能看起来不重要但实际上可能对你的工作产生毒害的小滋扰是一个常见的错误。您的产品设计师是否坐在单独的房间或建筑物内？这意味着需要花费更多的努力才能过来并进行对话，有些事情将不会被讨论。写新测试难吗？然后很多东西都不会被测试。

这些东西中没有一个本身特别危险，但它们往往堆积起来并造成严重后果。令人讨厌的是，你经常不会注意到它们，直到它已经太晚了。特别是当有更严重的危险需要解决时。记住有关的寓言 boiling frog and the notion of creeping normality .

保持警惕，并在他们找到你之前在他们的根源上对抗这些事情。

专注于基础知识

IT是一个极其快节奏的行业。每周都有新工具进入市场。我已经提到了臭名昭着的“ JavaScript fatigue “我上一篇文章中的综合症。许多开发人员都受到压力，并被迫在每个新项目中重新评估他们的JS技术堆栈，这让他们疯狂。事实上，始终站在边缘可能具有挑战性，但有一些想法可以使它更容易。

首先，关注基本面。尽管新技术经常出现，但新的基本概念却很少见。在学习新知识时，请确保您了解导致此实现的基本思想。很可能，这些想法也用于其他项目，一旦你遇到类似的东西，你就会更容易掌握它。例如，现代JavaScript UI框架基于组件，一旦您了解了如何使用React构建面向组件的应用程序，就可以在使用Angular时使用此体验。以类似的方式，Redux的想法进入Angular，而Angular的反应式状态管理是作为MobX实现的。

花一些时间熟悉有关软件开发中常见模式主题的经典书籍，如“ Enterprise Integration Patterns “由Gregor Hohpe和Bobby Woolf，着名的” Design Patterns: Elements of Reusable Object-Oriented Software “四人帮或Martin Fowler的不同作品。尽管书中描述的一些内容可能已经过时，但您可以使用它们来了解模式如何演变到今天。

其次，不要急于了解那里的每一件新事物。我知道很有可能会关注Hacker News上出现的每一件新事物，但很多事情只是噪音。相反，请留意社区中已经存在一段时间的事情，并且已经超越了初步讨论的炒作。不要屈服 FOMO 。如果你至少注意一些正在发生的事情，那么没有重要的事情会被忽视。

Bonus Tips

我们在本文中已经讨论过很多内容，但在结束之前还有一些我想强调的要点。这些小技巧更多地关注你的个人特质而不是专业特征，但我仍然认为它们对你的工作生活有很大的影响。

Share the knowledge

通常人们认为囤积宝贵的知识会使它们成为不可或缺的。在你的团队中有这样的人会让你接触到“ bus factor “如果这样的人要离开这个项目，你可能会陷入困境。如果您是这些人中的一员，请考虑除了让您不可或缺之外，您的专业知识也会使您无法驾驭和“不可取消”。您可能会错过组织中的其他职业机会，因为您担任此职位。相反，与同事分享知识，如果可能的话，将您的部分工作委托给他们，并使用此协作在他们的工作之上构建更多的东西。

不要怪自己或别人

Don’t be an asshole

Wrapping it up

关于我们工作的最好的事情是它没有限制。旅行和龙都有新的道路要杀。无论您是刚刚开始旅行还是经验丰富的专业人士，请记住这些事情。他们应该帮助您找到自己的方式，并在每个步骤中成为更好的开发人员。

英文原文： https://medium.com/devtrailsio/how-to-become-a-better-software-developer-dd16072c974e