原文：https://arendjr.nl/2023/04/mvp-the-most-valuable-programmer
作者：Arend van Beelen
译者：ChatGPT 4 Turbo
编者注：几个收获，1）代码本身没有价值，他解的问题才有价值，2）代码是负债，写的越多负债越多，3）代码风格应该交给工具，不要浪费时间修改和讨论，4）正确性是有边界的，用不到的正确性不会产生任何价值，5）DRY 过度反而适得其反，6）性能可能不是瓶颈。
缩写 MVP 通常代表最小可行产品，至少如果你在软件工程领域工作的话。但今天我想谈论的是另一种 MVP：最有价值程序员（The Most Valuable Programmer）。
就像最小可行产品一样，最有价值程序员并不是一个具体的概念。相反，这是一个你努力追求的目标。而且，这不是关于在你的同伴中成为最有价值的人。而是关于成为最好的自己。让我详细说明……
一个年轻的我
前几天我想起了大约 15 年前和一位资深开发者的一次对话。我不太记得当时我脑子里在想什么，但我自告奋勇去微优化了几个大的 PHP 文件。那还是在我们使用操作缓存之前的日子，所以每个请求都要反复解析文件。为了优化这个问题，我把所有双引号字符串都改成了单引号字符串，因为我在某个地方读到，解析这些字符串会快 11%（或类似的效果），因为它们没有转义序列。
所有这些导致了一个相当大且充满了繁琐变更的差异文件。正是这位资深开发者有幸审查这些变更。他因为我在没有事先讨论的情况下创建了这么大的差异文件而给了我一些指责，这给他带来了不小的头痛，但他说话出奇的礼貌。可能是我的幸运之处，在他看来，我应该是使用了代码自动格式化工具，因为他提到，正常思维的人不会花时间手工做这种事情。我同意了。
但这也是在自动格式化工具真正普及之前，实际上我确实是手工完成了所有工作。哦，愚蠢的我。我非常清楚，当时承认这一点并不符合我的最佳利益，但我确实愚蠢到浪费了几个小时去替换字符串引号和进行其他乏味的更改，结果导致我的前辈浪费时间审查所有这些。
这节课的教学可能甚至有一些有趣的教学方面。他真的以为我在使用自动格式化工具，还是只是给我留了面子？是不是因为他礼貌的讽刺让我感到羞愧，这节课的内容才深刻地印在了我的心里？无论如何，我学到了这一课，它帮助我向成为一名更好的程序员迈出了许多步中的一步。如果你愿意的话，一个更有价值的程序员。
代码与价值
我已经编程大约 28 年了，我曾经为我的代码感到非常自豪。我喜欢绘制架构图，我有严格的编码风格，遵循细致的接口指南，并且始终把性能放在首位。难怪我会为我的代码感到骄傲，因为它确实是美的化身。至少我是这么认为的。
我想这可能是一种奢侈，因为我在上高中之前就开始编程了。这让我能够在没有就业压力的情况下，甚至不考虑真正重要的事情，就完善我的技艺。我从那些早期的编程年代学到了很多，但我认为我对代码本身的欣赏可能在很多年后仍然阻碍了我。
如果你想成为一个更好的程序员，请接受这个建议：不要试图成为最好的程序员。 无论如何，没有人会同意什么是最好的程序员，所以这是一个徒劳的目标。追逐风。相反，试着成为最有价值的程序员。价值虽然仍是一个相当抽象的概念，但至少它可以与更具体的目标挂钩，例如商业价值。
我认为我最大的错误之一是多年来我坚信的一个抽象概念：代码是有价值的。它不是。代码是一种负债。 一旦代码被写出来，它就需要被审查，需要被维护，可能需要被调试、重写，甚至被丢弃。但一旦它存在，它就变成了一个时间黑洞。代码本身没有价值。真正的价值只存在于价值本身。这可能是一个同义反复，但它是如此基本，值得重复：你从解决代码解决的问题中获得价值，而不是从代码本身获得价值。解决问题所需的代码越少越好。
考虑这个：如果你是一名工程师，你被雇来解决问题。代码可能是你的选择武器，但你得到报酬并不是为了交付代码。你得到报酬是为了解决问题。你解决的问题越多，你提供的价值就越大。你交付的代码越多，你就变得越成为负担……
那么，你如何避免成为一个负担，又如何成为一个能解决许多问题的宝贵程序员呢？优先排序。 教你自己优先排序的一个好方法是改变心态：你不是在努力成为一个有价值的程序员。你就是一个有价值的程序员。你是你自己最宝贵的资产。那么你最稀缺的资源是什么呢？时间和精力。一天中只有那么多小时，你能够激发的精力也只有那么多。不要浪费在代码格式化上，而是帮助解决业务或你的项目最需要解决的问题。
代码风格
我本可以就此打住，但脑海中浮现了许多话题，我不打算浪费它们。既然这些都是大多数程序员在某个时刻应该自问的问题，我们不妨继续讨论。我们已经提到了代码风格的话题，所以从这里开始是很自然的。这也是一个很好的例子，用来突出这一切中的一个基本矛盾：许多事情同时重要，它们都值得我们关注。优先排序并不仅仅是挑选最重要的事情而放弃其他所有事情。它关乎找到一个平衡，确保你的基本需求得到满足，这样你就可以将大部分时间集中在最重要的事情上。
代码风格出于许多原因而重要。我们希望我们的代码具有可读性，这样同事可以审查，如果我们日后需要重新深入研究，我们自己也能理解。如果团队中的每个人都遵循自己的风格，这往往会分散对代码要实现的目标的注意力。与你习惯的风格不同的代码更难阅读，因为它违背了你的预期。将其比作两个人使用不同方言交谈：他们可能都在说英语，但这会使人更难集中注意力于信息本身。
但归根结底，你说哪种方言并不那么重要，只要大家说的是同一种。对于软件来说，这意味着要就代码风格达成一致并保持一致性。关于所有细节的无数辩论随处可见，所以我不打算在这里重复它们。作为一个团队，做出让你们感到开心的选择，并坚持下去。
并确保你使用自动化来验证你的风格。没有比让机器来做这件事更好的方式来避免浪费别人的时间在吹毛求疵上。
正确性
哦，正确性的乐趣。两者都至关重要，原因显而易见，也可能是一个潜在的无休止的时间黑洞，原因则要微妙得多。确保你的代码正确是程序员的主要职责之一。错误可能会伤害你的用户，那对业务不好。更不用说追查它们也是一个讨厌的耗时工作，没有人喜欢做。最好是一开始就避免它们。
那么我们的代码应该总是正确的，对吗？嗯，这得看情况。
例如，假设你正在编写一个脚本来处理仓库中的一些自动化任务。也许这个脚本无法处理那些不是有效 UTF8 的文件名。这确实很遗憾，你可以说这不太正确。但是，如果你的仓库中没有任何文件会给它造成麻烦，那它肯定是足够正确的。
当你构建一个分发给最终用户的客户端应用程序时，情况就大不相同了，这个应用程序需要能够处理他们机器上的任意路径。人们可能会使用各种各样的地区设置，迟早你可能会遇到文件名不是有效 UTF8 的情况。正确性的标准可能会因情况而异。
一般来说，我们编写的程序应该对所有合理预期的输入产生正确的结果。也许你在一个错误可能造成生命威胁的行业工作，在这种情况下，你可能对“合理预期”有非常严格的解释。但超出你问题领域的要求往往是编写大量价值不大的代码的做法。很少有人会因此感谢你。
DRY
DRY 代表不要重复自己。与其复制粘贴代码并修改细小部分以适应不同的使用场景，通常更好的做法是编写稍微可复用的代码，这样可以适用于所有的使用场景。但这本身也呈现了另一个新手程序员可能会陷入的陷阱。
当口号被极端化时，通常会导致它们在某些情况下适得其反。DRY 的初衷是为了提高可维护性。毕竟，如果你后来需要更新代码，你可能只需要在一个地方更新，而不是去寻找所有复制过去的地方，可能还会遗漏一些。这很好，但是如果你不断地扩展一个函数，加入各种选项和分支，以覆盖越来越多的用例，那么这个函数本身将成为维护的隐患。
在这个特定情况下，将一个大函数拆分成几个小函数可能会更好。然后你可以将它们重新组合成更大的、特定用例的函数，即使这样做会引入一些样板代码。但是更通常的意义上，总是试图质疑给定指南的目的是什么。遵循指南并不是坏事，但要学会识别何时是远离它们的好时机。
性能
程序员的宠儿。如果没有人欣赏你代码的美，至少你可以为自己节省了多少内存分配而沾沾自喜。我懂 — 我曾经替换了成百上千个引号，因为据说这样可以使它们的解析速度提高 11%，尽管那段代码从来都不是瓶颈。
请意识到，除非你在 Linux 内核或某些特殊的嵌入式领域工作，否则过分追求性能只会浪费你自己的精力，而不会带来任何真正的价值。
这并不是说性能不重要（所有这些话题都很重要），但是提供良好的性能再次非常取决于选择你的战斗。如果你有的话，优化你的关键路径。批量请求，而不是用数十个或数百个请求轰炸你的 API 或数据库。但是，试图优化本来就足够快的东西并不增加任何价值。
增值
我们已经举了很多例子来说明节制是好的。不要过度，你就已经成功了一半，成为一名有价值的程序员。但是你应该把精力集中在哪里呢？你如何增加价值？
这里是一个随机的想法列表，这绝不是权威的……
- 尝试理解业务对功能需求的动机。一旦你很好地理解了问题领域，你可能能够提供更简单的替代方案，这些方案需要较少的实施努力。
- 识别未解决的问题领域。这些问题可能是技术性的，比如常见的导致错误的原因，也可能是与流程或组织有关的，比如导致速度降低或团队士气下降的原因。做好研究，然后提出解决方案。提出自己愿意去解决这些问题。很多时候你会发现你并不是第一个注意到这些问题的人，但可能只需要有人愿意付出努力。
- 在审查同事的代码时不妨慢慢来。查看拉取请求时，尝试理解他们试图解决的问题，以及他们的解决方案在该背景下是否合理。你能想到他们可能遗漏了什么吗？这也是知识共享的绝佳机会。不要只指出他们遗漏了什么，如果你熟悉这个系统，你或许还能提供一些为什么事情会是这样的背景信息。你甚至可能会想到提高可维护性的方法，这样下一个人就不会错过同样的问题。
- 沟通。确保其他人知道你在做什么，并且对其他人在做什么有所了解。如果其他人不知道你的工作，他们也无法提供建议。你可能认为你有一个好主意，并想用一个有效的解决方案来给同事一个惊喜。但在一个组织中，惊喜很少是好事，你也不希望你的好主意干扰到别人。
别忘了自己
感谢你坚持到这里。希望我能为你提供最后一颗宝石，因为对一些人来说，这可能是本文最重要的建议：不要忘记自己。
我之前提到过，时间和精力是你最稀缺的资源。我还提到，优先级的设定是为了找到一个平衡点，确保你的基本需求得到满足。如果你用光了时间，你可能会错过截止日期，这对业务不利。如果你耗尽了精力，你可能会面临倦怠风险，这对任何人都不好，尤其是你自己。
但在你耗尽它们之前，你通常会进入一个可以识别的负面循环。如果你时间紧迫，它会引起压力，这可能导致你更快地消耗能量。如果你精力不足，你会开始缺乏动力，并且完成基本任务的时间会变得更长。如果你注意到这些迹象，这是一个非常明确的指示，表明你的基本需求没有得到满足，你需要说出来。如果你的经理不得不问为什么错过了截止日期，那就太晚了。如果你不得不请病假来从精疲力尽中恢复，那绝对是太晚了。
有许多方法可以预防这种负面循环，或者一旦你注意到早期迹象就从中走出来。首先，不要过度承诺，因为这是接受超出你能力范围工作的必然结果。但是，如果你注意到某个特定任务正在消耗你的动力，向同事寻求帮助，或者将其放到次要位置，而不是强迫自己立刻完成它。如果你觉得截止日期不合理，提前告知你的经理。如果你做不到，不要自责。
确保你为自己、家人和/或爱好留出时间。对我个人而言，阅读和尝试新技术曾是我的消遣方式，尽管如今我常常发现自己更喜欢写小说。我喜欢和我的妻子以及儿子一起度过时光，完全不去想工作或编程，我也会感到非常满足。
没有哪一点会影响成为一名有价值的程序员的理念。你需要放松并保持健康才能快乐。只有这样，你才能保持能量不断提升自己。快乐的程序员往往更有生产力。
毕竟，你是你自己最宝贵的程序员，所以要照顾好自己。
Love, Arend.