【外评】如何判断自己已成为高级程序员

程序员| 2024-07-09

资深者的担心

“你能改变代码中的这个条件吗？要怎么做？”

过去，我在改变算法、修改函数参数、创建或销毁流程等方面要快得多。我的目标首先是完成客户的要求，其次才是确保代码的可维护性，或者所做的选择是一系列经过深思熟虑的方案中最好的。

后来我老了，开始使用测试来了解我的代码在修改后是否仍然良好。我开始撰写文档，以理解我为什么以某种方式进行推理，并开始进行代码审查，以提高代码理解和维护能力。这种新的 “复杂 “方法使我的工作变得更加复杂，或者说：它延长了从一个请求到最终解决方案的过程。以前 10 分钟就能完成的修改，现在需要一整天的时间，因为我必须评估修改可能带来的所有影响，运行所有自动化测试，在无法实现自动化的地方执行一些手动测试，编写文档，与主代码合并，等待构建和集成测试，验证一切正常，最后宣布问题已解决，希望我没有忘记任何事情。

几年过去了，曾经那个无忧无虑、不经测试就推送代码的孩子不可避免地演变成了坚定的开发者，在向主分支（不，”master “已不再使用）添加代码时，小心翼翼地修复空格。

曾经快乐而热情的 “是的 ”

变成了 “是的，但我也会这样做”，

慢慢地变成了 “也许”。

慢慢变成 “也许”

直到变成 “不”，或者更糟，变成 “看情况”。

高级程序员并不坏

发生这一切并非出于恶意，而是出于对围绕一行代码所发生的事情的认识。他们意识到了更改可能带来的错误或影响，也意识到了广泛的回归往往会破坏 “更改单一条件不会出现问题 “的确定性。这并不意味着不应该进行更改；这只是意味着应该始终对影响进行评估，以免造成比你试图解决的问题更大的问题。通常情况下，随着年龄的增长，程序员脑海中的影响会成倍增加。

想想软件的生命周期及其设计。最初，开发产品相对容易：我们看到了自己的目标，知道如何实现目标，确保客户和利益相关者满意，如果幸运的话，我们还能创建一个在技术和人力方面都很团结的团队。但这并不总是必然的，因为有时一个异类就会破坏整个团队的稳定。一旦实现了这一目标，当需要做出改变时，所有团队成员都会保持一致，并意识到需要做什么。

当你从这个集体亢奋和创造性的阶段走出来时，开发团队就开始从最初的形式发生变化。与此同时，客户也会因为进入维护阶段而减少预算，如果不给予应有的重视，对产品的掌握就会开始悄悄溜走。

不，能支配产品的当然不是测试，而是构思产品的头脑。

项目更替是一个不可避免的过程，除非你发现自己身处极地中央的冰屋之中，没有互联网连接，而开发项目的可怜程序员甚至连简历都无法发送，除非他们把简历贴在封条上（尽管程序员总是有可能致力于钓鱼，他们的巨大热情被代码所压制）。

当团队成员发生变化时，产品知识的一部分就会丢失，掌握的知识也会开始流失。因此，每次干预都会变得更加昂贵、冗长和危险。

项目维护会改变规则吗？

在正常的产品生命周期中，有些部分需要频繁更新，而其他许多部分由于成熟、缺乏需求或稳定，则不需要更改。不经常进行修改会减少程序员对其所写代码的了解。这就意味着，两年前编写这些代码的人很可能已经不记得这些代码了，而需要对它们进行复查，以回忆起创建这些代码的过程。

越是垂直的变更，就越难记住其背后的原因：你可能不记得为什么在连接外部资源时使用了一个参数而不是另一个参数，为什么使用了一个加密套件而不是另一个加密套件，或者你可能有一个开放了几个月的分支，等待客户对一个突然变得不那么重要的紧急功能进行验证，但现在你需要将其合并到一个有 400 多个推送的基线中，你不知道是重新开始更有意义，还是将变更应用到一个重建基中更有意义。

在这类干预中，还有日常任务、功能更改、错误修复、新功能请求、修复错误时引入的错误修复、对产品知之甚少的同事引入的代码、更新或新组件引入的行为更改，这些都需要更改代码并间接引入异常。

你，写代码的人不记得了。你明白，面对几种变化，要做的修改比预期的要大，但你必须想办法做到这一点，因为你还记得以前代码背后的原理，并明白这不是一个简单的变化。试想一下，如果有人需要修改相同的代码，而他又是第一次接触，

正如赫拉克利特所说：

没有人会两次踏入同一条河流，因为这不是同一条河流，他也不是同一个人。

这句话可以很容易地应用到代码中：每一次改动，无论多么微小，都会改变代码及其存在的环境，而这种环境与创建代码的环境是不同的，人与编写代码的人也是不同的。

意大利一家知名银行的使用案例

试想一下，你是一家 “随机银行 “的高级程序员，有人告诉你要进行系统更新和相关的固件更新，并保证不会造成任何伤害，而且更新将在生产中进行。在你的生活中见过很多次这类干预，首先想到的就是进行测试。然而，无论是在规模还是使用案例方面，都没有一个与生产环境完全一致的测试环境。您建议不要进行大规模更新，但解决方案提供商保证不会出现任何问题。安全部告诉您，为了遵守公司规定，必须在某个日期之前实施更新，如果出现问题，可以回滚。

您勉强同意了，部分原因是 “我们采用敏捷方法工作，必须为变化做好准备”，而且 “我们不能总是消极”。

在安装操作系统更新和相关固件更新后，在线服务访问（如应用程序、投资应用程序、网上银行和智能商务）出现中断，导致不稳定情况。我们诚挚地向您道歉，并非常感谢您的理解。

一个 “简单 “的操作系统和固件更新导致了整整 5 天的不稳定状况。

显然，在这种假设情况下，问题不在于更新本身，而在于缺乏测试、缺乏覆盖生产的测试环境、缺乏即时回滚、缺乏灾难恢复计划或低估了风险。

项目外部对变更的看法如何？

通常情况下，项目外部人员对软件开发有完全不同的看法，他们会要求尽快进行变更。

我昨天就需要。

这句话很经典，但人们往往不明白，即使是一个简单的变更，也会导致一系列问题，而这些问题远远超出了变更本身。

我只要求变更一个条件，为什么马里奥会给我带来这么多问题？现在我要把任务分配给布鲁诺，他将在两分钟内解决这个问题。

在项目中，有些情况下可以快速修改代码，而在另一些情况下，即使是简单的修改，也可能需要深思熟虑：即使只是几行代码，甚至只是一个附加条件。每个程序员都会根据自己的经验、产品知识和对代码的理解，以不同的方式进行修改。程序员对产品的经验越丰富，他们就越有可能仔细评估变更，因为他们知道潜在的后果。程序员对产品的了解越少，他们就越有可能迅速做出更改。