向开发人员提供建议的编程心理学

我之前写过，编程有两个受众：CPU 和你的编程伙伴。

还有一些优秀的文章，比如《面向苦难编程》 ，可以帮助你在编程时调整目标——让它工作、让它漂亮、让它快速，这是那篇文章的建议。

“让它工作、让它漂亮、让它快速”是绝妙的编程建议，也是我从第一次读它开始就一直牢记在心的建议。

编程建议程序首先以 CPU 为目标——即“使其工作”。

1. 合理的编程建议

然后建议针对您的编程伙伴，即必须维护或查看代码的人，让代码漂亮。

一旦您的代码成功满足其计算要求，并满足与我们一起共事的普通人能够理解的要求，那么，如有必要，我们就可以专心致志地不断完善它。事实上， 代码“漂亮”意味着有可能更容易找到改进的机会，因为在大多数情况下，使代码“漂亮”意味着更小的、独立的函数，从而使得更易优化。

我最近在网上和一位朋友聊天，他提出了一个问题，这也反映了我的经历：他的任务是集成一组代码，这些代码是在没有团队监督的情况下创建的。这些代码缺乏测试，并且是独立编写的，没有遵循与主项目相同的编码标准。

这是一个艰难的处境。集成这样的代码意味着要试图弄清切入点——这是测试的职责——但由于没经过测试，你不得不相信编码者实际上满足了需求，因为在理想情情形下，测试也要证明这一点。

你会怎么做？你会给什么编程建议？

2. 无冲突面对

如我所言，我遇到过类似情形，虽然我承认还可以处理得更好，但同时我也认为自己已经做得够好了。

人们不喜欢被面对，面对什么并不重要。迪特里希·邦霍费尔（Dietrich Bonhoeffer）有一个深刻的洞察，即个体可能很愚笨，但群体可能超级愚笨——更糟糕的是，抵触挑战，抵抗力会随着参与人数的增加而增加。（你可以很容易地改变一个朋友的想法——但是改变一群七个人的想法却难于上青天。）

所以我所做的就是把自己描绘成一个受到他们的代码库挑战的人。我没有评论实际代码或它们有多可怕：我让自己专注是于学习代码，因为我不理解它。

这个功能的测试在哪里？”我问道，尽管我知道没有测试。毕竟，我可能是错的……问测试在哪里是对他们的温和刺激，以便我能从他们那里有所收获。

这个问题给了他们很大的回旋余地。

3. 强迫自我反省

他们可以指出测试在哪里确实满足了我的需求；也许我只是没看到？（在这种情况下，不存在测试，我知道，但这不是重点。我需要他们考虑可能性。）

他们也可以自己观察到，也许测试不存在，作为交接的要求，也许他们可以写一个。

当您还没有设计用于测试的代码时，测试很困难，但在您接受代码之前，这不是您的问题，这让他们有机会修改自己对代码的理解，而不必在意我对他们代码的看法。

当然，也许你没有权限要求这样的测试。在这种情况下，您可能需要向利益相关者（负责交付代码的人）请求帮助，并指出未测试代码的集成引入了可变的可靠性（即，它是不可靠的，因为您不能假设它是可靠的）。

与利益相关者就可靠性进行对话可能会让您有权回去进行结构和测试的对话。

4. 编程建议心理学

再者说，这种对话完全可以颠倒过来。如果他们编写了意大利面条式的代码并为此感到自豪——谁不会呢？—您会简单地要求他们编写它，以便您的小脑袋可以像理解根据组织约定编写的代码一样容易地理解它。

“哇，那个 243 行的函数太厉害了，就是看不懂。你能告诉我我们如何将它分解并重构为具有更小的函数和组合吗？ 而这个对“j”的引用，是一个索引吗？我们能把它命名为它实际代表的东西吗？是窗口句柄吗？ 请帮帮我，我真的不明白。”

这是基本的心理学原理。在某种程度上，这是一种操纵，但我们每天和每次互动都以温和（希望是善良）的方式操纵人们：当我们与人打招呼时，我们会微笑，以触发特定的内啡肽，我们首先提到好消息（或许不是）创造有利于我们想要的特定心态。为自己的目的使用人们的思维和感知方式并不奇怪，如果结果是正面的，那么这样做也不是坏事。

不要害怕用心理学来帮助你编程。这可能很难，因为有时它意味着你不能对那些可能真的需要大喊大叫的人大喊大叫——但大喊大叫往往会适得其反，如果目标是富有成效，那么我们需要考虑如何创造我们的工作环境，而不是通过按住别人来满足我们的私欲。

注：本文译自：The psychology of offering programming advice to developers - Coffee Talk: Java, News, Stories and Opinions (theserverside.com)