5 位高效程序员的更多特质

将近 7 年前，我写了一篇题为《高效程序员的 5 大特质》的小文章，得到了很好的反馈，并且随着时间的推移一直很受欢迎。

当然，开发人员会随着时间的推移而成熟。我写上一篇文章时，职业生涯还处于早期。在过去几年里，尤其是在微软，我有机会见证了各种各样的行为。我对自己能够更好地区分新手和真正高效的开发人员有了更好的认识。

如果你不习惯看到它，技能上的差异可能令人震惊。一个新手程序员，或者一个没有从经验中学习多少的程序员，其生产力可能比一个优秀、经验丰富的开发人员低一个数量级或更多。你不会想在这种排名的底部待很长时间。其中一些只是经验，但在许多情况下，这只是一种心态——有许多“经验丰富”的开发人员实际上并没有学会进步。这在许多职业中都是如此，但在编程中尤其如此——你不能停滞不前。你必须不断学习。世界在变化，编程在变化，十年前的真理现在已经过时得可笑了。

我在上一篇文章中列出的特质仍然适用。它们仍然有价值，但还有更多。请注意，我并非在本篇文章中声称我已掌握了这些特质。我仍然渴望在这些领域中的每一个领域达到更高的标准。请记住，宣扬好想法，即使在努力实现它们的同时，也不是虚伪。这些是需要达到的标准，而不是我认识的任何一个人的描述（尽管我认识很多在这些领域中至少有一项表现出色的人）。

主人翁意识

主人翁意识意味着很多事情，但主要是你不会等待问题找上门来。它意味着，如果你看到一个问题，你就假定解决它或找到能解决它的人是你的工作，然后确保它得到解决。这意味着不忽略电子邮件，因为，嘿，不是我的问题！这意味着认真对待问题并确保它们得到处理。有主人翁意识的人永远不会把问题藏起来，或者轻易地希望别人会处理它。

你可以将主人翁意识等同于责任，但我认为它超越了责任。“责任”通常带有负担或分配不受欢迎的任务的色彩，而“主人翁意识”则暗示你对结果有所投入。

主人翁意识通常意味着走出你的舒适区。你可能认为你不是处理某件事的最佳人选，但如果没人去做，那你就绝对是。挺身而出，承担问题，然后把它完成。

主人翁意识并不意味着你做所有的工作——这会耗尽精力、令人沮丧，而且最终是不可能的。它并不意味着你规定了你责任的界限，并禁止他人侵犯。特别是，它并不意味着代码所有权，因为只有你才能更改你的代码。

主人翁意识是一种心态，它拒绝严格的控制层级，而倾向于更平等的机遇主义。

与主人翁意识密切相关的是为自己的错误承担责任。这意味着你不会试图为自己辩解，推卸责任，或不必要地最小化问题。如果你造成了一个问题，就直接说出来，解释发生了什么，你将如何防止它再次发生，然后继续前进。

总而言之，这些关于主人翁意识的想法会让你获得一个声誉，那就是你是一个希望团队或产品变得最好的那个人。你想成为那样的人。

记住，如果你有这样的想法：有人应该去…——停下来！那个人就是你。

数据驱动

一个好的开发人员不会做假设。经验固然好，但数据更好。远比好得多。我在我的新书《编写高性能 .NET 代码》的第一章中提到，在解释任何关于 .NET 的具体内容之前，性能优化的最重要的事情就是测量。在最后一章，我讨论如何培养团队的性能导向文化时，又回到了这个想法。我写的一件事是，有数据支持的吹牛资本才更有说服力。

知道如何测量事物比能够改变事物更重要。如果你在不测量的情况下进行更改，那么你只是一个随机编码的猴子，只是猜测你正在做一些有用的事情。尤其是在性能方面，构建一个自动测量性能的系统比实际的性能更改更重要。这是因为如果你没有那个系统，你将花费比实际开发多得多的时间进行手动测量。请参阅下面的自动化部分。

测量可以很简单。对于一些 bug，测量仅仅是 bug 是否重现。对于数据中心服务器应用程序的性能调优，它很可能要复杂得多，并且会涉及专门用于测量的系统。

确定做出决定所需数据的量并不总是容易的。你确实需要权衡这一点与效率，而且你不希望好的想法因为不必要的测量而受阻。然而，你应该很少在完全盲目的情况下，没有任何数据就去做任何事。作为一个开发人员，你的每一个行动都应该能够独立地证明其合理性。

性能优化的口号是**测量，测量，测量**。这应该是所有软件开发活动的口号。事情是在改善还是没有？更快了还是没有？多少？客户更开心了还是没有？任务更容易完成了吗？我们省了更多的钱吗？它消耗的内存更少了吗？我们的容量更大了吗？ UI 响应更快了吗？确切来说是多少？

你在多大程度上衡量这些问题的答案，很大程度上取决于它们对你底线的重要性。

我的日常工作涉及开发一个运行在数千台服务器上的应用程序，该应用程序支撑着 Bing 的很大一部分。对于这样的应用程序，即使是看似微小的决定，最终也可能产生巨大的影响。如果我让某个东西效率稍低一些，就可能导致我们需要购买更多的机器。太好了，我现在这个未经充分测量的编码更改每年将给公司带来数十万美元的额外成本。糟糕。

即使是对于较小的应用程序，这也可能是一件大事。例如，进行一项更改，在某些情况下导致 UI 响应速度慢了 20%，如果你没有充分的测量系统，可能不会被注意到，但如果因此收到一个注意到此问题的用户的差评，并且有足够的竞争对手，那么这个决定就可能导致重大的收入损失。

可靠的测试

请注意，我没有说“测试”，没有限定词。好的测试、可靠的、可重复的测试。这些才是值得拥有的。

如果你看到一个代码更改没有伴随的测试更改，不要害怕问这个问题：“测试在哪里？”答案可能是现有测试涵盖了该更改，或者更大范围的测试，或者不同更改中的测试会涵盖它，但关键是要问这个问题，并确保有一个令人满意的答案。“手动测试”有时是一个有效的回答，但这应该非常罕见，并且有理由。

我无法计算有多少次，由于数百个单元测试对我的代码进行了充分的测试，我被挽救了，尤其是在我尝试进行大规模的内部重构时，通常是为了提高性能。

好的测试固然重要，但同样重要的是要淘汰坏的测试。不要在无用的事情上浪费资源。坚持一个干净、可靠的测试套件。我不确定哪种情况更糟：没有测试，还是你无法依赖的测试。最终，不可靠的测试就等同于没有测试。

自动化

一个高效的开发人员总是试图让自己失业。说真的。工作量远远超出了你分配的时间。自动化那些让你烦恼、让你绊倒、重复的、频繁的、容易出错的事情。一旦你能将一个过程分解成一个可以编写脚本让其他人遵循并获得相同结果的确定性步骤，那么就确保那个人是一个程序。

这不仅仅是简单的服务器管理维护脚本。这是你工作中的任何一部分。收集数据？让它自动输入到需要它的系统中。生成报告？如果你已经生成了两次相同的报告，不要第三次再做。你的构建系统需要多个步骤？你有什么问题？

你必须解放自己，去做更有趣、更有创意的 H 工作。你是一名高薪程序员。要像那样行事。

示例：我去年的一项工作是定期运行性能剖析，分析结果，并将它们发送给我的团队，并提出未来关注的建议。这涉及许多步骤

1. 登录到数据中心中的随机一台机器。
2. 开始一个 120 秒的 CPU 剖析。
3. 等待 120 秒再加上几分钟的处理、符号解析等。
4. 压缩文件，复制到我的机器
5. 分析文件——根据各种规则对数据进行分组、过滤和排序。
   1. 查找我总是报告的一些标准内容
6. 对 900 秒的内存/异常/线程/等剖析执行相同的操作。

每次花费大约一小时，有时更多。

我意识到这个过程的每一个部分都可以自动完成。我编写了一个部署到每个数据中心机器上的服务。每天几次，它会检查是否需要剖析，机器是否处于适合剖析的状态等。然后它运行剖析器，收集数据，甚至自动分析数据（有关我如何做到这一点的一个提示，请参阅《编写高性能 .NET 代码》第 8 章）。所有这些都会上传到文件服务器，分析结果会显示在网站上。完全无需干预。我不仅不再需要自己做这项工作，而且其他人也可以自行查看数据，并且我们可以轻松地随着时间的推移添加更多的分析组件。

不怕沟通

我想谈论的最后一件事是沟通。这对我和我来说一直是个挑战。我绝对是那种喜欢把自己关在洞里敲键盘几天，然后拿出一些神奇的代码出来的人。如果可以的话，我会从我的电脑上删除 Outlook。

这种态度可能对你有一段时间的帮助，但最终会限制你的发展。

随着你职位越来越高，沟通变得至关重要。有效的沟通技巧是你用来提升职业生涯的工具之一。

有效的沟通可以从简单地确认某人的问题，或解释你正在处理某件事开始，并定期向所有相关人员进行后续跟进。没有人喜欢被蒙在鼓里，尤其是在处理紧急问题时。对于时间紧迫的问题，提供“下一小时更新”可能是至关重要的。

有效的沟通也意味着能够说明你正在做什么以及为什么它很酷。

最终，它意味着更多——能够以简单、易懂、逻辑的方式向许多人展示复杂的想法。

良好的沟通技巧可以让你超越独自实现软件，而是帮助整个团队更好地实现软件。通过帮助和教导他人，你可以产生更广泛的影响。这对你的团队、你的公司和你的职业生涯都有好处。

你有一个良好的工程文化吗？

我认为所有这些特质都取决于一个重要的先决条件：你必须有一个稳固的工程环境才能运作。如果管理层轻视员工的幸福感、健全的软件工程原则，或者工作场所本身就充满毒性，那么也许你需要首先专注于改变这一点。

如果你的领导层目光短浅，无法容忍你自动化工作而不是仅仅完成任务，那就是一个问题。

如果提出问题或承认错误会影响你的职业生涯，那么你很快就需要离开。那是一个最终会因为没有人愿意解决的累积性失败的重负而崩溃的团队。

不要满足于这种类型的工作场所。要么努力改变它，要么找个更好的地方。