【译文】软件工程中的软技能

软件开发| 2024-02-23

前言

如果你正在经营一家公司，”我们需要重构这个模块。”这句话你肯定不愿意听到。除非你是技术出身，否则这句话毫无意义。事实上，这是一个可怕的说法，因为这意味着你需要改变一些之前以某种方式运行的东西。正如肯特-贝克（Kent Beck）在他的著作《整洁第一？一书中解释的：”没有新功能，可能会造成损坏，而且最后什么也得不到。不，谢谢”。

管理者了解问题空间、领域以及如何管理组织，而不是技术实施细节。他们并不关心你在 Livewire 中使用的是 Next.js、React、Symfony 还是 Laravel。对于用户来说，这也是一个有效的说法。他们不关心技术实现；他们关心的是服务。

管理者负责在特定领域获得市场份额。他们优先考虑的是能够可靠运行并满足最终用户需求的产品。然而，当工程师与商业世界的现实脱节时，问题就出现了。我们期望经理们能理解我们的技术观点，甚至在他们不理解时感到失望。我们希望他们理解 “我们需要重构这个 “的意义。因为这对我们来说真的很重要。如果你的经理是工程师出身，那就再好不过了！今天，我们将讨论另一半，即经理和工程师脱节的情况。

为什么管理者不理解软件工程师？

因为我们不知道如何解释自己。我们拘泥于技术术语。我们所说的 “重构 “或 “技术债务 “等术语对大多数人来说毫无意义。他们不懂如何取舍。如果一项任务可以快速完成，我们就应该快速完成它。我们不应该再说：”是的，我可以尝试在一周内完成，但这真的很难”。这就意味着，如果你不能在一周内完成任务，你就不是很努力。所以，你只是给自己制造了一个问题。我们经常无法进行有效的沟通，因为我们不太考虑自己的语气。我们没有努力去了解业务是如何运作的。因为我们拘泥于技术细节。我们没有时间去思考我们的用户、我们的业务以及他们的需求。我们无法提出非技术性的解决方案。我们看起来不专业。

我想说明的是，这并不是对工程师的攻击。事实上，在我职业生涯的早期，我也曾处于同样的境地。这只是一种诚实的自我批评。我感到沮丧的是，似乎没有人理解重构的重要性。

让它变得重要：它不仅仅是糟糕的代码

我们需要解释的是，如果我们投入一些资源来重构有问题的模块，就可以腾出精神空间来关注产品的其他方面。然而，这不应该仅仅是技术原因。我们应该提供对所有人都有意义的其他合理理由，而不仅仅是开发人员。

很难维护不是一个论点。你的工作就是维护它。难不难并不重要。对你来说很难，而不是对业务的另一方来说很难。只有当你让它变得重要时，它才会变得重要。许多工程师都很难理解这部分内容。他们知道有问题的模块会损害业务。但是，他们不知道如何用非技术语言来表达这个问题。我们需要找到一种大家都能理解的共同语言。我们为什么不用实际数字来表达呢？比如

我们必须重构预订模块，因为它不仅难以维护，去年还造成了 11 个中度错误和 2 个严重错误。严重 bug 造成的损失超过 47500 美元，中度 bug 造成的损失约为 43000 美元。我们总共收到了 197 份用户报告，其中一个错误甚至造成了严重的安全问题，可能会导致法律后果。我们已经制定了一项具体计划，将在未来两个月内对这一领域进行重构。我们将组建一支由 3 名开发人员组成的工作团队，每人负责不同的领域。您可以在下面找到该计划和详细列表。这两个月的重构工作将在今年为我们节省大约 65,000 美元，明年也几乎是同样的数额。这不仅能解决当前的 bug，还能改善用户体验 (UX)，帮助我们快速解决未来的问题。目前，即使是小问题，我们也要花费大量时间。预订模块目前就像一个迷宫，让每个人都很难进入。我们可以把精力投入到开发新功能上。

这和说 “我们需要重构这个 “感觉不同，不是吗？当然，写一句话要花费更多的精力，但如果把所有的抱怨加在一起，可能会花费更多的时间。不要说维护它很难。解释它是如何损害你的业务和用户体验（UX）的。试着设身处地地为企业和用户着想。解释每个人如何从这一改变中受益。管理者可能很难理解，为什么一个盈利的企业要花时间去修复一些赚钱的东西。

抱怨与解决问题

软技能对于创造美好的职业生涯和人脉关系来说非常宝贵。如果你无法解释自己，就没有人能理解你和你的问题。你有责任让别人理解你，而不是理解他们。这句话同样适用于你的个人生活。你是真的想解决问题，还是想抱怨？抱怨可能会让人感觉很方便，但它只能提供暂时的缓解，而不能解决实际问题。我有过这样的同事，他们每天一进办公室就抱怨一切。他们希望每个人都能理解自己的问题，却从不去理解别人的问题。老实说，我并不怀念与消极的人共事的日子，他们总是抱怨，却不试图解决任何问题。他们只会传播负面情绪。你不应该成为这样的人。抱怨解决不了任何问题，包括你的问题。

有些人倾向于抱怨，但他们也试图找到解决方案，更好地了解情况。有时感到不知所措和抱怨是完全正常的，尤其是当你关心某件事情并想要改善它的时候。我想说的是，在表达你的不满时，你应该保持逻辑性和客观性。也许你面临的问题并不只是你一个人的问题，你也不一定非要自己解决。寻求帮助是完全可以的。但请记住，只抱怨而不采取任何行动对任何人都没有帮助。

交流

我们使用计算机和代码来解决问题，但我们解决的不是计算机问题。归根结底，我们是在解决人类的问题。计算机不是我们的客户。沟通和联系永远存在。如果我们与客户、团队和经理脱节，就无法理解我们需要解决的问题。我们应该专注于实际问题，避免沉溺于技术细节。这就是为什么理解和实践领域驱动设计（DDD）和测试驱动开发（TDD）会有所帮助。我们会更加关注实际问题，而不是仅仅关注实现细节。有效解决问题需要沟通。这也是公司、经理和其他人正在寻找的，他们正在寻找能够沟通的问题解决者。

表达思想的能力

你能向世界表达什么，你就是什么。你能解释多少，别人就能理解你多少。我们中的许多人都曾有过这样的经历：我们知道一些事情，但却无法用语言表达出来。这甚至让我们怀疑自己是否知道那件事。出现这种情况通常是因为我们难以表达自己的想法。有时，只是缺乏理解或词汇。有时，对方没有技术背景。有时，我们不知道如何简化。我们不知道如何将概念抽象化。你需要组织你的想法，让它们清晰明了。要以结果为导向。如果你在解释你所知道的和给你带来麻烦的事情时遇到困难，也许是时候开始多读多写了。你不必与人分享。写作是一种很好的放松方式。在白纸上解释自己，最终会有助于向别人解释自己。你会明白自己的声音是怎样的，并找到让它变得更好的方法。它可以让你与自己进行头脑风暴。

建设性自我批评

我们的个人生活和职业生涯受到自身诸多方面的影响，这一点很难接受。我们很难接受自己、队友或合作伙伴之外的影响。没有人教过我们这项技能，也很难理解。有时，我们会不断地评判自己，这可能会成为一种不健康的习惯。但一般来说，我认为建设性的自我批评是一种有效的工具。我关注的是我可以改变的行为，而不是全局性的、无法改变的问题。此外，我不考虑感受，而是优先考虑结果。这些结果不仅会影响我自己，还会影响其他人。你不需要对自己咄咄逼人，而是要从他人的角度来理解情况。建设性的自我批评给你空间和理解。这是一种帮助我们对自己形成反馈的工具。

你花了几个小时开发的功能可能不会给产品带来任何价值。你的代码审查可能只是在阻碍其他开发人员，而不是提供建设性的反馈。如果你总是脾气暴躁，可能会让别人不想与你共事。如果你总是没有同理心地催促别人，你可能就不是最好的领导者。这就是理解和换位思考。

结论

当然，外部因素也会影响我们的工作。有时，管理者不具备管理团队的技能，或者很难与之共事。还有的时候，他们可能缺乏同理心，或者进行微观管理，导致团队难以运作。我完全理解所有这些情况。它们是常见问题。这篇文章不是针对它们的。而是关于你的个人成长。如果你想打造最好的自己，就不应该只局限于技术技能。你应该培养沟通和解决问题的能力。不要让外部环境限制你的潜力。

本文文字及图片出自 Soft Skills in Software Engineering