简介来自于 MDH 前端周刊第 96 期
本文讨论了成为最有价值的程序员（MVP）的概念。与 “最小可行产品” 类似，MVP 并不是一个具体的概念，而是一个追求的目标。这篇文章提供了一些建议，帮助程序员成为更有价值的人，包括不要过度关注代码风格、正确性、DRY 和性能，而是关注业务需求、解决问题以及与同事沟通。此外，作者还提到了保持身心健康的重要性，因为只有这样才能保持高效率和创造力。
翻译使用了 Bing Chat AI，并在部分段落以引用的形式展现了 AI 生成的总结，
MVP通常代表最小可行产品(Minimal Viable Product)，至少在软件工程领域是这样。但今天我想谈谈另一种MVP：最有价值的程序员(The Most Valuable Programmer)。
就像最小可行产品一样，最有价值的程序员并不是一个具体的概念。而是一个应该努力追求的目标。此外，它不是关于怎样在同行中最有价值。相反，它是关于如何成为最好的自己。让我详细说明…
年轻的我
前几天，我想起了大约15年前与一位高级开发人员的一次谈话。我不记得当时我的脑袋里到底想了什么，但我自作主张地对几个大型PHP文件进行了微优化。那时我们还没有使用op-caching，所以每次请求都会反复解析文件。为了优化这一点，我把所有双引号字符串都改成了单引号，因为我在某处读到过，由于没有转义序列，解析这些字符串快11%（或类似效果）。
所有这些都导致了一个相当巨大、充满乏味的 diff 。而这位高级开发人员需要审查这些文件差异。他因为我在事先没有讨论就创建了这么大的 diff 而责备了我一番，这让他非常头疼，但他却非常礼貌。他可能认为我是用自动格式化程序对代码进行了格式化，因为他提到，没有人会花时间手动做这样的事情。我同意。
但那也是在自动格式化程序真正普及之前的日子，事实上，我是手动完成了所有操作。哦，愚蠢的我。我当时非常清楚承认这一点并不符合我的最佳利益，但我确实愚蠢地浪费了几个小时替换字符串引号和进行其他乏味的更改，并反过来浪费了我的上级审查所有这些内容的时间。
有意思的地方在于。他真的认为我在使用自动格式化程序吗，还是只是往好处去想？这个教训被精确地记住了，是因为他礼貌地嘲讽让我感到羞愧吗？无论如何，我吸取了教训并向着成为更好程序员的步骤迈出一步。如果你愿意，可以称之为更有价值的程序员。
代码与价值
我已经编程大约28年了，我曾经为我的代码感到非常自豪。我喜欢画架构图，我有严格的编码风格，遵循细致的接口准则，并始终将性能放在首位。我为我的代码感到骄傲真的不足为奇，因为它确实是一件美丽的事物。至少以前我是这么认为的。
我想这可能是因为我在高中之前就开始编程，所以才有这种奢侈。它让我在没有就业压力的情况下完善我的艺术，也没有考虑真正重要的事情。我从那些早期的编程年代学到了很多东西，但我认为对代码本身的欣赏可能是阻碍我多年后发展的东西。
如果你想成为一个更好的程序员，请接受这个建议：不要试图成为最好的程序员。无论如何，无论如何，没有人会同意成为最好的程序员意味着什么，所以这是一个徒劳的目标。这徒劳无功。相反，试图成为最有价值的程序员。价值仍然是一个相当抽象的概念，但至少它可以与更具体的目标联系起来，例如商业价值。
成为最好的程序员是一个没有标准和共识的概念，追求这个目标没有意义和价值。
我认为我的最大错误之一是一个抽象的想法，我多年来一直相信：代码是有价值的。它不是。代码是一种负担。一旦代码被写出来，它需要被审查，需要被维护，可能需要被调试、重写甚至丢弃。但一旦它存在，它就成了一个时间漏洞。代码中没有价值。只有价值中才有价值。这可能是一个重言式，但它如此基础，值得重复：你从解决你的代码解决的问题中获得价值，而不是从代码本身获得价值。解决问题所需的代码越少越好。
编程不是为了写代码而写代码，而是为了解决实际的问题而写代码。写出过多或过于复杂的代码会给程序员带来额外的负担和风险，而不会增加程序的价值。
考虑一下：如果你是一名工程师，你被雇来解决问题。代码可能是你的选择武器，但你不是为了交付代码而获得报酬。你是为了解决问题而获得报酬。你解决的问题越多，你提供的价值就越多。你交付的代码越多，你就成为越大的负担…
那么，如何避免成为负担，如何成为一个解决许多问题的有价值的程序员呢？优先考虑。教自己优先考虑的一个好技巧是改变心态：你不是试图成为一个有价值的程序员。你是一个有价值的程序员。你是自己最有价值的资产。那么你最稀缺的资源是什么？时间和精力。一天只有这么多个小时，你能够集中的精力也只有这么多。不要浪费在代码格式化上，而要帮助解决企业或项目最需要解决的问题。
作为一名工程师，你应该专注于解决实际问题，而不是过分关注代码本身。代码只是一种工具，而不是目的。你应该合理安排自己的时间和精力，优先处理最重要和最紧急的任务。
代码风格
我想我本可以就此打住，但我脑海中有这么多话题，我不想浪费它们。而且既然它们都是大多数程序员在某个时候应该为自己回答的话题，我们不妨继续。我们已经涉及了代码风格这个主题，所以它是一个很自然的起点，它也是一个很好的例子，突出了所有这些事情中的一个基本矛盾：许多事情同时很重要，它们都值得我们的关注。优先级不仅仅是选择最重要的事情，而是要找到一种平衡，确保你的基本需求得到满足，这样你就可以把大部分时间花在最重要的事情上。
代码风格很重要，原因有很多。我们希望我们的代码可读，这样我们的同行可以审查它，而且如果我们以后要重新深入其中，我们自己也能理解它。如果团队中的每个人都遵循自己的风格，那么它往往会分散注意力，无法体现代码想要实现的目标。用不同风格编写的代码比你习惯的代码更难阅读，因为它违背了你的期望。把它比作两个人说不同的方言：他们可能都在说英语，但是要关注信息就变得更困难了。
但最终，你说哪种方言并不那么重要，只要大家说的是一样的就行了。对于软件来说，这意味着要就代码风格达成一致，并保持一致。关于所有细节的争论数不胜数，所以我不打算在这里重复它们。作为一个团队，做一个让你们开心的选择，并坚持下去。
并且确保你使用自动化来验证你的风格。没有比让机器来做这件事更好的方法来避免浪费别人的时间去挑剔了。
代码风格会影响代码的可读性和表达力，所以团队应该就一个风格达成一致，并使用自动化工具来验证风格
正确性
哦，正确性的乐趣。由于显而易见的原因，这两者都是最重要的，而由于更微妙的原因，这可能是一个无休止的时间漏洞。确保你的代码没有错误是程序员的主要职责之一。错误可能会伤害到你的用户，这对商业不利。更不用说追踪它们也是一项令人讨厌的耗时工作，没有人喜欢做。最好一开始就避免它们。
那么我们的代码应该总是正确的，对吧？这要看情况。
例如，假设你正在编写一个脚本来处理仓库的自动化。也许脚本无法处理不是有效UTF8的文件名。这很糟糕，你可以说这不太正确。但如果你的仓库中没有任何文件会给它带来麻烦，那么它肯定足够正确。
这与你构建一个分发给最终用户并需要能够在他们机器上处理任意路径的客户端应用程序时完全不同。人们可能使用各种各样的语言环境，迟早你可能会遇到文件名不是有效UTF8的人。每种情况下正确性的阈值可能非常不同。
总体而言，我认为可以说我们编写的程序应该为所有可能合理预期的输入产生正确的结果。也许你在一个错误可能造成危及生命情况的行业工作，在这种情况下，你可能对“合理预期”有非常严格的解释。但超出你问题领域的要求往往是编写大量没有什么价值的代码。很少有人会感谢你。
代码应该对所有可能合理期望的输入产生正确的结果，但不需要过度追求正确性，因为这可能会浪费时间和精力
DRY
DRY代表不要重复自己。与其复制粘贴代码并修改微小的部分以适应不同的用例，通常更好的方法是编写更具可重用性的代码，可以用于两种用例。但这本身又提出了一个初级程序员可能会陷入的另一个陷阱。
当口号被极端化时，通常会导致它们被应用于会适得其反的情况。DRY是为了提高可维护性而发明的。毕竟，如果你以后需要更新代码，你可能只需要在一个地方更新它，而不是寻找所有复制到的地方，可能还会遗漏一些。这很好，但是如果你不断地用各种选项和分支来扩展一个单一的函数，使它覆盖越来越多的用例，那么这个函数本身就会成为维护性的隐患。
在这种特定情况下，最好将一个大函数分解成小函数。然后你可以将它们组合成更大的、针对特定用例的函数，即使这样会引入一些样板代码。但从更一般的意义上说，总是试着质疑一个给定指导原则的目的是什么。遵循指导原则并不坏，但要学会识别什么时候是离开它们的好时机
DRY原则可以提高代码的可维护性，避免重复和错误，但是如果过度使用，也会导致代码变得复杂和难以维护。应该根据不同的情况，合理地分解和组合函数，以及质疑指导原则的目的。
性能
亲爱的程序猿们。如果没有人欣赏你代码的美，至少你可以沉浸在你节省了多少分配中。我知道——我曾经替换了数百个引号，因为据说这样可以使解析它们快11%，而这些代码本来就不是瓶颈。
但是，除非你在Linux内核或某些特殊的嵌入式领域工作，否则对性能的过分关注会浪费你自己的精力，而不会提供任何真正的价值。
这并不是说性能不重要（所有这些主题都是），但提供良好的性能很大程度上取决于问题的重要性(picking your battles)。优化你的关键路径，如果你有的话。使用批量请求替代使用数十或数百个请求轰炸你的API或数据库。但是，试图优化本来就足够快的东西并不会增加任何价值。
除非是在特殊的领域，否则过分关注性能优化是没有意义的，这没有创造真正的价值。对于优化需要有选择地进行，抓住主要矛盾。
增加价值
我们已经涵盖了许多例子来表明节制是好的。不要极端，你就已经在成为一个有价值的程序员的道路上行进了一半。但你应该把精力集中在哪里呢？如何增加价值？这里有一个随机的想法列表，绝不是权威的…
- 试图理解业务对功能需求的动机。一旦你很好地理解了问题领域，你可能能够提供更简单、实现起来更省力的替代方案。
- 确定未解决的问题领域。这些可以是技术上的，如常见错误原因，也可以是与流程或组织相关的，如减少速度或团队士气的原因。做好研究，然后提出解决方案。提供自己愿意解决它们。许多时候你会发现你并不是第一个注意到它们的人，但它可能只需要有人愿意付出努力。
- 花时间审查你同事的代码。当查看拉取请求时，试图理解他们试图解决的问题，以及他们的解决方案是否在这种情况下有意义。你能想到他们可能遗漏的东西吗？这也是一个很好的知识共享机会。不要只指出他们遗漏了什么，如果你熟悉这个系统，你也可以提供一些背景，说明事情为什么是这样的。你甚至可以想到改善可维护性的方法，这样下一个人就不会遗漏同样的东西。
- 沟通。确保其他人知道你正在做什么，并对其他人正在做什么有一些了解。如果其他人不知道你的工作，他们也无法提供建议。你可能认为自己有一个好主意，并想用一个可行的解决方案给同事带来惊喜。但在一个组织中，惊喜很少是好事，你不希望你的好主意干扰别人。
别忘了自己
感谢你能坚持看到这里。希望我能为你提供最后一颗宝藏，因为对于一些人来说，这可能是本文中最重要的建议：别忘了自己。
我之前提到，时间和精力是你最稀缺的资源。我还提到，确定优先次序是为了找到一种平衡，确保你的基本需求得到满足。如果你的时间用完了，你可能会错过最后期限 （deadline），这对商业不利。如果你的精力耗尽，你可能会有倦怠的风险，这对任何人都不好，尤其是你。
但在你耗尽时间或精力之前，你通常会进入一个可以识别的负面漩涡。如果你时间紧迫，它会导致压力增加，使你更快地消耗精力。如果你精力不足，你开始缺乏动力，并且开始花费更多的时间来完成基本任务。如果你注意到这些迹象，这是一个非常明确的信号，表明你的基本需求没有得到满足，你需要说出来。如果你的经理不得不问为什么错过了 deadline，则为时已晚。如果你必须请病假来恢复精力，则绝对为时已晚。
有许多方法可以防止这种负面螺旋或在注意到早期迹象后脱离它。首先，不要过度承诺，这会使你承担的工作超过你所能处理的范围。但是，如果你发现某项特定任务正在消耗你的动力，请向同事寻求帮助，或将其放在后台处理，而不是强迫自己一次性完成它。如果你觉得 deadline 不合理，请提前告诉经理。如果你做不到也不要自责。
确保你有时间陪伴自己、家人和你的爱好。对我个人来说，在技术上阅读和实验曾经是一种消遣方式，如今我自己在写小说。我喜欢和妻子、儿子在一起，并且完全可以不去思考工作或编程。
这些都不影响成为一个有价值的程序员的想法。你需要放松并保持健康，才能获得快乐。只有这样，你才能保持精力，不断提高自己。快乐的程序员往往更有生产力
而且，毕竟你是你自己最有价值的程序员，所以要照顾好自己。
Love, Arend.
