成为一个有价值的程序员

MVP:最有价值的程序员

缩写 MVP 通常代表最小可行产品,至少如果你在软件工程领域工作。但今天我想谈谈另一种 MVP:最有价值的程序员。

就像最小可行产品一样,最有价值程序员也不是一个具体的概念。相反,它是一个你为之奋斗的目标。此外,这也不是说你要成为同事中最有价值的人。相反,它是关于成为最好的自己。让我详细说明一下……

年轻的我

有一天,我想起了大约 15 年前我与一位高级开发人员的谈话。我不记得当时脑子里是怎么想的了,但是我自己对几个大的 PHP 文件进行了微优化。这是在我们使用操作缓存之前的日子,所以每个请求都要对文件进行一次又一次的解析。为了优化这一点,我将所有双引号字符串改为单引号,因为我在某处读到:由于缺乏转义序列,解析这些字符串的速度提高了 11%(或类似的效果)。

所有这些都导致了一个巨大的差异,并且充满了乏味的变化。正是这位高级开发人员有幸审阅了这些文件,他责备了我一顿,因为我没有事先讨论就制造了这么大的分歧,这让他很头疼。但他对此却出奇地礼貌,他认为我在代码上使用了自动格式化器,这可能是我的可取之处,因为正如他所提到的,没有一个头脑正常的人会花时间手工做这样的事情。我接受了。

但那也是在自动格式化器普及之前,实际上我所有的代码都是手工完成的。哦,我真傻。我很清楚,当时承认这一点并不符合我的最大利益,但我确实愚蠢到浪费了几个小时来替换字符串引号和做其他繁琐的更改,反过来又浪费了我的前辈检查所有这些内容的时间。

这节课的教学方式甚至可能会有一些有趣的地方:他是否真的认为我在使用自动格式化器,或者他只是在假定我是无辜的?难道正是因为他那彬彬有礼的尖酸刻薄给我带来了耻辱,这个教训才让我印象深刻吗?无论如何,我从中吸取了教训,它帮助我迈出了成为一名更好的程序员的众多步骤之一:如果你愿意成为一个更有价值的程序员。

代码与价值

我已经写了 28 年的代码了,我曾经对自己的代码感到非常自豪:我喜欢画架构图,我有严格的编码风格,遵循细致的接口指南,并且总是把性能放在我的脑海里。难怪我为我的代码感到骄傲,因为它确实是一个美丽的东西。(至少我是这么想的)

我想这对我来说可能是一种奢侈,因为我在高中之前就开始编程了。它让我在没有任何工作压力的情况下完善我的艺术,坦率地说,没有考虑真正重要的事情。我从早期的编程中学到了很多东西,但我认为我对代码本身的欣赏可能是许多年后阻碍我前进的东西。

如果你想成为一个更好的程序员,请接受这个建议:不要试图成为最好的程序员。没有人会同意成为最好的程序员意味着什么,所以这是一个徒劳的目标,追逐风气。相反,要努力成为最有价值的程序员。价值仍然是一个相当抽象的概念,但至少它可以与更具体的目标联系起来,比如业务价值。

我认为我最大的错误之一是我多年来一直相信的一个抽象的想法:代码是有价值的。它不是!代码是一种负担。一旦代码被编写出来,它就需要被审查,需要被维护,它可能需要被调试,或者重写,甚至扔掉。但是一旦它存在,它就变成了一个消耗时间的水槽。代码本身没有价值,只有价值所在。这可能是一个重言式,但它非常基本,需要重复强调:你从解决代码所解决的问题中获得价值,而不是从代码本身中获得价值。解决问题所需的代码越少越好。

想想看:如果你是一名工程师,你被雇佣来解决问题。代码可能是您的首选武器,但您不会因为交付代码而获得报酬。你的工作是解决问题。你解决的问题越多,你提供的价值就越大。您交付的代码越多,您的负担就越大……

那么,如何避免成为负担,成为一个能够解决许多问题的有价值的程序员呢?优先考虑一个好的技巧是改变思维方式:你不是在努力成为一个有价值的程序员,而是已经是一个有价值的程序员。你自己是最有价值的资产。那么你最稀缺的资源是什么?时间和精力。一天只有那么多小时,你只能集中那么多精力。不要浪费时间在代码格式上,而是帮助解决业务或项目最需要解决的问题。

代码风格

我想我本可以就此打住,但我脑子里已经有了所有这些话题,我不想浪费它们。因为这些都是大多数程序员在某些时候应该自己回答的问题,所以我们还是继续讨论吧。我们已经自然的触及了代码风格的主题。它也很好地强调了所有这一切的一个基本矛盾:许多事情同等重要,它们都值得我们关注。优先排序并不是简单地选择最重要的而放弃其他的。它是关于找到一种平衡,确保你的基本需求得到满足,这样你就可以把大部分时间花在最重要的事情上。

代码风格很重要,原因有很多:我们希望我们的代码是可读的,这样我们的同伴就可以审查它,这样我们自己也可以理解它,如果我们稍后必须回去。如果团队中的每个人都遵循自己的风格,这往往会分散代码试图实现目标的注意力。用与您习惯的不同风格编写的代码更难阅读,因为它违背了您的期望。比较一下两个人说不同的方言:他们可能都在说英语,但很难集中注意力在信息上。

但最终,你说哪种方言并不重要,只要每个人说的都一样。对于软件,这意味着在代码风格上达成一致并保持一致。在所有的细枝末节上都有无数的争论,所以我不想在这里重复。做出一个让你们作为一个团队感到快乐的选择,并坚持下去。

并确保您使用自动化来验证您的样式。没有比让机器去做更好的方法来避免浪费别人的时间了。

正确性

正确性编程的乐趣。显而易见的是,两者都是极其重要的,而且因为更微妙的原因,两者之间可能存在无穷无尽的时间联系。确保代码正确是程序员的主要职责之一。bug 可能会影响用户,这对业务不利。更不用说,把它们弄下来也是一项费时费力的工作,没有人喜欢做,所以最好从一开始就避免它们。

所以我们的代码应该总是正确的吗?Emmmm,这要看情况。

例如,假设你正在编写一个脚本来处理存储库中的某些自动化。也许这个脚本不能处理无效的 UTF8 文件名。这很糟糕,你可以说这不是很正确。但如果你的存储库中没有任何文件会给它带来麻烦,那么它肯定足够正确了。

这与构建分发给最终用户并需要能够处理其机器上任意路径的客户端应用程序时完全不同。人们可能使用各种语言环境,迟早你会遇到一些文件名不是有效的 UTF8 编码。正确性的门槛在每种情况下可能有很大的差异。

一般来说,我认为我们编写的程序应该对所有可能合理预期的输入产生正确的结果是有意义的。也许你所在的行业中,bug 可能会造成危及生命的情况,在这种情况下,你可能对“合理预期”有非常严格的解释。但是,超出问题领域的需求通常会导致编写大量没有价值的代码。很少有人会为此感谢你。

DRY

DRY 代表不要重复自己。与其复制粘贴代码并修改一小部分以适应不同的用例,不如编写可重用性更强的代码,并且可以用于两种用例。但这本身也会给初级程序员带来另一个陷阱。

这也像一个咒语,如果走极端,通常会导致它们被应用于适得其反的情况。DRY 的发明是为了简化可维护性。毕竟,如果您以后需要更新代码,您可能只需要在一个地方更新它,而不是查找它被复制到的所有地方,可能会遗漏一些地方。这很好,但是如果您继续用各种选项和分支扩展单个函数,使其覆盖越来越多的用例,那么该函数本身就会对可维护性造成危害。

在这种特殊情况下,最好将一个大函数拆分为几个小函数。然后,您可以将它们重新组合成更大的、特定于用例的代码,即使这样会引入一些样板文件。但在更普遍的意义上,总是尝试质疑给定指导方针的目的是什么。遵循这些准则并不是坏事,但要学会认识到什么时候是放弃它们的好时机。

性能

许多程序员的宠儿,如果没有人欣赏您的代码之美,至少您可以陶醉于节省了多少分配。我知道——我曾经替换了数百个引号,因为据说这样可以使解析它们的速度提高 11%,而这从一开始就不是瓶颈。

请注意,除非您在 Linux 内核或某些特殊的嵌入式领域工作,否则纠缠于性能是在浪费您自己的精力,并且不会提供任何真正的价值。

这并不是说性能不重要(所有这些话题都很重要),但提供良好的性能又非常关键,需要选择你的战斗。如果有必要,请优化你的关键路径。批量请求而不是向 API 或数据库发送几十或几百个请求。但如果某些东西已经足够快了,你不需要尝试进行优化。

附加价值

我们已经涵盖了很多例子来说明克制是好的。不要过度,你在成为有价值的程序员的道路上已经走了一半。但你应该把精力集中在哪里?如何增加价值?

这里是一个随机的想法列表,绝不是权威性的建议…

  • 尝试理解业务对功能需求的动机:一旦您很好地理解了问题领域,您就可以提供更简单的替代方案,从而减少实现的工作量。
  • 确定未解决的问题区域:这些原因可以是技术性的,比如 bug 的常见原因,但也可以是过程相关的或组织性的,比如降低速度或团队士气的原因。你去做研究,然后提出解决方案,表现出你愿意解决这些问题。很多时候你会发现你不是第一个注意到他们的人,但这可能需要有人愿意付出努力。
  • 花时间检查同事的代码:在审查拉取请求时,试着理解他们试图解决的问题,以及他们的解决方案是否在这种情况下合理。你能想到他们可能遗漏了什么吗?这也是一个很好的知识分享机会。不要只指出他们遗漏的东西,如果这是你熟悉的系统,你还可以提供一些背景信息,解释为什么事情会变成这样。你甚至可以想到改进可维护性的方法,这样下一个人就不会再遗漏同样的东西了。
  • 沟通:确保其他人知道你正在做什么,并对其他人正在做什么有一些了解。如果别人不知道你的工作,他们也不能提供建议。你可能认为自己有一个好主意,想用一个可行的解决方案来给同事个惊喜。但在组织中,惊喜很少是好事,你不希望你的好主意干扰到别人。

不要忘记你自己

感谢您一直阅读到这里。希望我能为您提供最后一个宝石,因为对于某些人来说,这可能是本文中最重要的建议:不要忘记自己。

我之前提到过,时间和精力是你最稀缺的资源。我还提到,优先考虑是找到确保基本需求得到满足的平衡点。如果你时间不够,你可能会错过截止日期,这对业务来说不好。如果你精力不足,你可能会面临燃尽的风险,这对任何人都不好,尤其是对你自己来说更不好。

但在你失去任何一种资源之前,通常会进入一个可以被识别的负面循环。如果你时间不多,会引起压力,导致你更快地消耗精力。如果你精力不足,你开始缺乏动力,并花更多的时间完成基本任务。如果你注意到这些迹象,那就非常明显表明你的基本需求没有得到满足,你需要说出来。如果你的经理必须问为什么错过了截止日期,那就太晚了。如果你不得不请病假来恢复被消耗完的精力,那肯定太晚了!

有许多方法可以防止这种负面循环或在注意到早期迹象后退出它。首先,不要过度承诺,因为这是一种确保承担更多工作而无法处理的方法。但如果你注意到一个特定的任务正在耗尽你的动力,请向同事寻求帮助,或将其放在后炉中,而不是强迫自己立即完成它。如果你觉得截止日期不合理,请提前告诉你的经理。如果你不能做到,不要打击自己。

确保你有时间为自己、家人和/或爱好。对我个人来说,阅读和尝试技术曾经是一种非常的消遣,但现在我经常发现自己写小说而不是编程[1]。我喜欢和我的妻子和儿子在一起,我可以完全满足地不去想工作或编程。

这一切都不会妨碍成为一个有价值的程序员的理念。你需要放松身心、保持健康才能快乐。只有这样,你才能保持精力,不断提高自己。快乐的程序员往往更有生产力[2]。

毕竟,你自己是最有价值的程序员,所以要照顾好自己。

[1] Aron Silver — an author of little renown

[2] Happiness and the Productivity of Software Engineers

原文地址

作者: 张熠
文章链接: https://crazyoctopusdan.github.io/2023/04/28/%E6%88%90%E4%B8%BA%E4%B8%80%E4%B8%AA%E6%9C%89%E4%BB%B7%E5%80%BC%E7%9A%84%E7%A8%8B%E5%BA%8F%E5%91%98/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.