你怎么告诉别人他们写错了代码？

Question

我一直在与一小群人一起开展编码项目，以获得乐趣。这是一个有组织且相当有凝聚力的团体。我与之合作的人都拥有与编程相关的各种技能，但其中一些使用较旧的或完全错误的方法，例如过多的全局变量，较差的命名约定等。虽然事情有效，但执行情况很差。礼貌地询问或介绍他们使用更好的方法论的好方法是什么，而不是质疑（或侮辱）他们的经验和/或教育？

Answer 1

介绍问题，让他们意识到他们所做的事情是错误的。例如，问这些问题：

  

你为什么决定把它变成一个全局变量？

     

你为什么给它这个名字？

     

这很有趣。我通常这样做是因为[插入你为什么更好的原因]

     

这种方式有用吗？我通常[插入你会如何让他们看起来很傻]

我认为理想的解决方法是巧妙地问他们为什么以某种方式编码。您可能会发现他们认为其他方法有益处。除非我知道他们的编码风格的原因是由于错误的信息，我绝不会在没有充分理由的情况下判断我的方式更好。解决这个问题的最好方法就是问问他们为什么选择这种方式;一定要对他们的推理感兴趣，因为这是你需要攻击的，而不是他们的能力。

编码标准肯定会有所帮助，但如果它是每个软件项目的答案，那么我们都会在天堂的私人岛屿上品尝鸡尾酒。实际上，我们都容易出现问题，软件项目的成功率仍然很低。我认为这个问题主要源于个人能力，而不是常规问题，这就是为什么我建议当一个问题出现问题时，我可以将这些问题作为一个整体解决。

最重要的是，不要立即假设您的方式更好。实际上，它可能是，但我们正在处理另一个人的意见，他们只有一个解决方案。永远不要说你的方式是更好的方式，除非你希望他们把你视为一个自鸣得意的失败者。

Answer 2

开始进行代码审查或配对编程。

如果团队不会参加，请尝试每周设计评审。每个星期，约会一个小时，谈论一些代码。如果人们看起来很咄咄逼人，那就选择一个没有人情感依赖的旧代码，至少在开始的时候。

正如@JesperE：所说，专注于代码，而不是编码器。

当你看到你认为应该有所不同的东西，但是其他人看不到同样的东西时，那么首先提出导致缺陷的问题，而不是指出它们。例如：

全球：您认为我们想要不止一个吗？你认为我们会想要控制对此的访问吗？

可变状态：您认为我们是否想要从另一个线程中操纵它？

我也发现专注于我的限制很有帮助，这可以帮助人们放松。例如：

长期功能：我的大脑不够大，不能立刻掌握所有这些。我们怎样才能制作出我能处理的小件？

坏名称：在阅读清晰代码时，我很容易感到困惑;当名字误导时，对我来说没有希望。

最终，目标不是教你的团队如何更好地编码。这是为了在团队中建立学习文化。每个人都希望其他人帮助他们成为更好的程序员。

Answer 3

介绍代码标准的概念。关于代码标准最重要的是它提出了代码库中一致性的想法（理想，所有代码应该看起来像是由一个人一次编写），这将导致更易理解和可维护的代码。

Answer 4

你必须解释为什么你的方式更好。

解释为什么功能优于切割功能？粘贴。

解释为什么数组比$ foo1，$ foo2，$ foo3更好。

解释为什么全局变量是危险的，并且局部变量会使生活更轻松。

简单地编写一个编码标准并说“做这个”是没有价值的，因为它没有向程序员解释为什么它是一件好事。

Answer 5

首先，我要小心不要太快判断。很容易将一些代码视为糟糕，因为可能有很好的理由（例如：使用遗留代码处理奇怪的约定）。但我们现在假设他们真的很糟糕。

您可以根据团队的意见建议建立编码标准。但是你真的需要考虑他们的意见，而不仅仅强调你对良好代码应该是什么的看法。

另一种选择是将技术书籍带入办公室（Code Complete，Effective C ++，Pragmatic Programmer ......）并提供借给别人（“嘿，我已经完成了这个，任何人都想借吗？“）

Answer 6

如果可能的话，请确保他们明白您正在批评他们的代码，而不是他们个人。

Answer 7

以非对抗的方式提出更好的选择。

“嘿，我觉得这种方式也会奏效。你们觉得怎么样？” [在屏幕上显示更好的代码的手势]

Answer 8

进行代码审核，首先查看您的代码。

它将使人们对整个代码审查过程感到放松，因为您通过查看自己的代码而不是他们的代码来开始这个过程。从代码开始也会给他们提供如何做事的好例子。

Answer 9

他们可能认为你的风格也很臭。让团队一起讨论一套一致的编码风格指南。同意某事。这是否适合你的风格不是问题，只要它的一致性是重要的，任何风格都可以解决。

Answer 10

代码标准理念很好。

但是考虑不说什么，特别是因为它是为了好玩，大概是与你成为朋友的人。这只是代码...

Answer 11

以身作则。以正确的方式展示它们。

慢慢来。不要因为每一个小小的错误而鞭打它们，只要从真正重要的事情开始。

Answer 12

在Gerry Weinberg的书“计算机程序设计心理学”中有一些非常好的建议 - 他的“无我编程”的全部概念都是关于如何帮助人们接受对他们的代码的批评，而不是批评自己。

Answer 13

错误的命名行为：始终不可原谅。

是的，不要总是假设你的方式更好......这可能很困难，但必须保持客观性。

我有一个编码器的经验，它有如此可怕的功能命名，代码比不可读更糟糕。这些功能谎称他们做了什么，代码是荒谬的。他们保护/抵制让别人改变他们的代码。当他们非常礼貌地面对时，他们承认它的名字很糟糕，但是想要保留他们对代码的所有权，并且会在以后“重新修改”。 现在这已经过去，但是你如何处理他们的错误被确认但是受到保护的情况？这种情况持续了很长时间，我不知道如何突破这一障碍。

全局变量：我自己并不喜欢全局变量，但我知道一些非常优秀的程序员喜欢它们很多。这么多，以至于我开始相信它们在许多情况下实际上并不是那么糟糕，因为它们允许清晰，易于调试。 （请不要火焰/ downvote我:)）归结为，我已经看到很多非常好，有效，无bug的代码使用全局变量（不是我的！）和大量的bug，无法读取/维护/修复精心使用正确模式的代码。也许 IS 可能是全局变量的一个地方（虽然可能会缩小）？我正在考虑根据证据重新考虑我的立场。

Answer 14

使用一些wiki软件在您的网络上启动Wiki。

在您的网站上开设一个名为“最佳做法”或“编码标准”的类别。

指望每个人都这样做。允许反馈。

当您发布该软件时，让其工作的人将代码放入构建回送给开发人员，将其指向其上的Wiki页面。

我已经在我的组织中完成了这项工作，人们花了几个月才真正开始使用Wiki，但现在这是不可或缺的资源。

Answer 15

如果你有一个松散的编码标准，能够指出它，或者表明你不能遵循代码，因为它不是正确的格式可能是值得的。

如果您没有编码格式，现在是获得一个编码格式的好时机。类似这个问题的答案可能会有所帮助：https://stackoverflow.com/questions/4121/team-coding-styles

Answer 16

我总是选择'这就是我要做的'。我不试着给他们讲课，并告诉他们他们的代码是垃圾，但只是给出一个替代的观点，可以向他们展示一些显然有点整洁的东西。

Answer 17

让有关人员就他们所编写的代表性模块的代码准备向小组其他成员做一个演示，让Q＆amp; A照顾它（相信我，它会，如果这是一个很好的团队，它甚至不应该变得难看。）

Answer 18

我穿上宽大的东西，开启了一种社交方法。

以古典希腊哲学家苏格拉底命名的Socratic Method是一种哲学探究形式，其中提问者探索其他人立场的含义，激发理性思考和阐明思想。这种辩证方法通常涉及一种反对的讨论，其中一种观点的辩护与另一种观点相对立;一个参与者可能会以某种方式导致另一个参与者自相矛盾，从而加强询问者自己的观点。

Answer 19

我喜欢代码，从来没有任何关于信息学相关信息的任何课程我开始非常糟糕并开始从示例中学习，但是自从我阅读{{3}后我始终记得并记住了本书是：

“每个人都可以编写机器可以理解的代码，但并非所有代码都可以编写人类理解的代码”

考虑到这一点，代码中有很多工作要做;）

Answer 20

我不能足够强调耐心。我已经看到这种事情完全适得其反，主要是因为有人希望现在发生变化。 相当多的环境需要进化的好处，而不是革命。今天通过强制改变，它可以为所有人创造一个非常不愉快的环境。

买入是关键。您的方法需要考虑您所处的环境。

听起来你在一个拥有很多“个性”的环境中。所以......我不会建议一套编码标准。你会想到把这个“有趣”的项目变成一个高度结构化的工作项目（哦，很棒，下一个......功能性文件？）。相反，正如其他人所说，你必须在一定程度上处理它。

保持耐心，努力朝着你的方向教育他人。从边缘（代码与其他人交互的点）开始，当与代码交互时，尝试将其作为讨论他们创建的界面的机会，并询问他们是否可以使用它们（如果它已被更改）（通过你或他们）。并完全解释为什么你想要改变（“它将有助于更好地处理更改子系统属性”或其他）。不要挑剔并试图改变你认为错误的一切。一旦你与其他人进行交互，他们应该开始看看它们如何在他们的代码核心中受益（如果你获得足够的动力，更深入并真正开始讨论现代技术和编码标准的好处）。如果他们仍然没有看到它......也许你需要在自己内部处理这个问题（特别是在一个“有趣”的项目中）。

耐心。进化，而不是革命。

祝你好运。

Answer 21

编写错误代码的人只是无知的一种症状（与愚蠢不同）。以下是与这些人打交道的一些提示。

• 人们自己的经历留下的印象比你说的要强。
• 有些人对他们制作的代码并不热衷，也不会听你说的任何话。
• 配对编程可以帮助分享想法，但可以切换谁在驾驶或者他们只是在手机上查看电子邮件
• 不要用太多的东西淹死它们，我发现连续集成甚至需要向一些较老的开发者解释几次
• 让他们再次兴奋，他们想要学习。它可能像一天编程机器人一样简单
• 信任您的团队，在构建时检查它们的编码标准和工具通常不会被读取或烦人。
• 删除代码所有权，在某些项目中，您会看到代码竖井或蚂蚁山，人们会说这是我的代码而您无法更改它，这非常糟糕，您可以使用配对编程来删除它。

Answer 22

我不是我项目的首席开发人员，因此不能强制执行编码标准，但我发现糟糕的代码通常会导致问题的提前而不是更晚，而且当它出现问题时，我会提出更清晰的想法或溶液

当时不插入并采取更自然的方法我已经获得了更多的信任，他经常转向我的想法，并包括我在项目使用的架构设计和部署策略。

Answer 23

不要让他们编写代码，而是让他们维护代码。

直到他们不得不维持他们热气腾腾的意大利面，他们才会明白他们在编码方面有多糟糕。

Answer 24

没有人喜欢听别人说他们的工作很糟糕，但任何理智的人都会欢迎指导和避免不必要工作的方法。

一所教学学校甚至说你不应该指出错误，而应该把注意力放在正确的地方。例如，你应该指出他们的代码特别容易阅读的地方，而不是指出难以理解的代码。在第一种情况下，你正在鼓励其他人思考并表现得像蹩脚的程序员。在后一种情况下，你可以像熟练的专业人士那样思考。

Answer 25

这里的许多答案都与代码格式有关，而现在这些代码格式并不是特别相关，因为大多数IDE都会以您选择的样式重新格式化代码。真正重要的是代码是如何工作的，海报是正确的，看看全局变量，复制和放大。粘贴代码，我的宠儿，命名约定。有这么糟糕的代码，它与格式没什么关系。

好的部分是，大部分原因都是不好的，这些原因通常可以量化和解释。因此，以非对抗的方式解释原因。在许多情况下，您甚至可以为作者提供问题变得明显的场景。

Answer 26

我与我合作过的人有类似的情感......他们没有像我那样接触编码，但他们在编码方面仍然很有用。

而不是我让他们做他们想做的事情，然后回去编辑整个事情。我通常只是坐下来向他们展示两种做事方式。他们的方式和方式，我们讨论每种方法的优点和缺点，从而更好地理解并更好地总结我们应该如何进行编程。

这是真正令人鼓舞的部分。有时他们会提出一些问题，即使我没有答案，经过研究，我们都会得到更好的方法论和结构概念。

1. 讨论。
2. 向他们展示为什么
3. 甚至不认为你总是对的。有时甚至他们会教你一些新东西。

如果我是你，我会怎么做：D

Answer 27

即使有人明显犯错，重要的是要激励和指导人并表现出尊重。但是，不仅应该有教练的方式，还应该指出错误是错误的。糟糕的代码应该做得更好。它不是可选的。员工应该知道哪些代码是可以的，哪些代码从他的主管的角度来看还不行。它仍然应该尊重并激励那些负责改进的人。

Answer 28

取决于程序员。有些人实际上喜欢听到“糟透了”，因为他们知道代码闻起来但不确定原因。

其他程序员需要多做一点宝宝。我发现告诉他们一些不好的事情; “这不是编写代码的好方法”，接下来是“在这里进行一些指导，看看我们是否这样做，它更具可读性/更少警告/无论如何”。这是有帮助的建设性批评;如果你不能把钱放在嘴边而且实际做得更好，你最好不要发表评论，即使你知道这很糟糕。

这两种方法都失败的唯一一个人就是一个笨蛋管理员助理，他在VBscript中编写了巨大的宏并向后推进了一切。她实际上有胆量告诉我，我对计算机编程一无所知，我可以从她的1337 sk1l50rz中学习。

Answer 29

这完全取决于你所写的文化。在一个自由软件项目中，你告诉他们他们写的是错误的代码，有积极的建议，改进方法和反馈。您也可以向他们的代码发送补丁。

友善的电子邮件也不会受到伤害。

Answer 30

根据我的经验，曾经有一段时间我们想要将Windows应用程序更改为Web应用程序并进行优化，因为它更易于更新和维护。但由于我的朋友是Windows应用程序的主要贡献者，他不允许改变，其余的是历史。

道德：为了代码优化和更好的维护，不仅要重视组织的目标，还要在任何编程环境中发挥重要作用。 < / p>

Answer 31

我真的很喜欢EnderMB's answer，但我想补充一点：

培养鼓励讨论代码质量而不是被视为敏感或禁忌的环境。例如，我参与了一个开源项目（一个Python库），其中经常与该组讨论新的代码和错误修正。不仅可以说“嘿，我觉得以这种方式做得更好”，但这实际上是鼓励以及我们用来维护高质量代码的过程的一部分。

我意识到并非每个环境都有利于这种过程，但它确实对我们有效。每个代码提交都不一定是委员会会议，但希望您能够完全接受讨论可疑或非最佳代码并寻求改进。毕竟，更好的代码对于团队中的每个人来说都更好，而团队合作的一个主要概念是合作而不是作为一个松散的个人群体。

Answer 32

我建议对这个问题采取积极的态度。不要指责你的同事使用不好的风格，而是要对整个团队可以遵循的风格和评论指南提出一些建议。

例如，如果你们主要是.NET商店，建议遵守微软的C＃风格和评论指南，因为这会使你更加符合该社区的标准做法。

您还可以指出一些示例以遵循统一的代码样式 - 例如，如果不熟悉代码库的人查看它，他们就不必破译多个样式。可以这样想：如果你正在读一本书并且很容易说出每一章都是由另一个人写的，你可能会在几章之后感到困惑吗？

我认为重要的是不要以负面的方式批评你的同事。最好是向某人推销变革带来的好处，而不是说服他们写出糟糕的代码。

Answer 33

在他面前只需重构他的代码并显示两个版本之间的区别。他肯定会喜欢那样。

Answer 34

并不是说我真的在这方面做了很多，但我必须同意，在你的方法中要考虑的两个最重要的事情是解释你的推理，并允许有问题的程序员解释他们的推理。糟糕的代码并非来自任何地方（并且，是的，“糟糕的代码”肯定是一个讨论的术语 - 我在某种程度上假设您能够定义什么是好代码和坏代码）。

我发现质疑，教育方法适用于我的团队。我试着在没有任何讨论或解释原因的情况下永远不要说“这样做”。

虽然你应该对它有点敏感，但你不能解决这个问题。理想的情况是，您的团队正在考虑他们正在编写的代码，而不仅仅是代码的作用，而是代码的编写方式。

最后，我补充一点，有很多书值得探讨这个主题 - 我最喜欢的是Brad Abrams的“框架设计指南”和微软的.NET BCL团队的Krystof Kwalina（等） 。它在讨论和解释所做出的决策方面做得非常出色，并展示了内部未遵循指南的地方以及由此产生的影响。

Answer 35

您可能希望专注于不良代码的影响，而不是仅仅因为您对其风格是好还是坏的主观意见而被忽视。

Answer 36

我坦率地相信，当更容易更改，调试，导航，理解，配置，测试和发布（哇）时，某人的代码会更好。

那说我认为如果没有第一次让他/她解释它的作用或者之后有人应该如何增强它（例如，创建新的功能或调试），就不可能告诉别人他/她的代码是坏的它）。

只有这样，他们的思绪才能实现，任何人都能看到：

• 全局变量值变化几乎总是无法检测
• 巨大的功能难以阅读和理解
• 模式使您的代码更容易增强（只要您遵守他们的规则）
• （等......）

也许一对结对编程应该可以解决问题。 至于执行编码标准 - 它有所帮助，但它们离真正定义什么是好的代码太远了。

Answer 37

私下询问一些“坏”代码段，着眼于它实际上是合理的代码的可能性（无论你有多少倾向），或者可能有所减弱情况。如果你仍然相信代码是完全不好的 - 并且源实际上就是这个人 - 那就走开吧。可能发生以下几种情况之一：1）该人注意并采取一些纠正措施; 2）该人没有做任何事情（不注意，或者不像你那样关心）。

如果＃2发生，或者＃1从你的角度来看没有带来足够的改善，并且它正在伤害项目，和/或对你施加足够的影响，那么可能是时候开始建立一个/在团队内执行标准。这需要管理层的支持，但在从基层煽动时最有效。

祝你好运。我觉得你的痛苦兄弟。

Answer 38

效果可能有点晚了，但这是一个商定的编码标准是好事。