您如何告诉某人他们在编写错误的代码？[关闭]

我一直在和一小群人一起从事一个编码项目，这很有趣。这是一个有组织且相当团结的团队。与我一起工作的人都有与编程相关的各种技能，但是其中一些人使用了较旧或完全错误的方法，例如过多的全局变量，不良的命名约定等。虽然事情正常，但实现效果很差。礼貌地要求或介绍他们使用更好的方法，而又不会质疑（或侮辱）他们的经验和/或教育的一种好方法是什么？

介绍问题以使他们意识到自己在做什么是错误的。例如，提出以下问题：

您为什么决定将其设为全局变量？

你为什么给它起这个名字？

那很有意思。我通常以这种方式进行挖掘，因为[插入您变得更好的原因]

这样行吗？我通常[插入您将如何使它们看起来很傻]

我认为解决此问题的理想方法是巧妙地问他们为什么以某种方式编码。您可能会发现他们认为其他方法也有好处。除非我知道他们的编码风格的原因是由于错误的信息，否则如果没有充分的理由，我将永远无法判断自己的方式是否更好。最好的方法就是问他们为什么选择这种方式。确保对他们的推理感兴趣，因为这是您需要攻击的，而不是他们的能力。

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

最重要的是，不要立即假设您的方法更好。实际上，可能是这样，但是我们正在处理另一个人的意见，而对他们来说，只有一个解决方案。除非您希望他们将您视为自鸣得意的失败者，否则请不要说您的方式是更好的方式。

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

如果团队不愿意这样做，请尝试每周进行设计审查。每个星期，开会一个小时，讨论一段代码。如果人们看起来很防御，请选择旧代码，至少在开始时，不要再有任何情感上的依赖。

就像@JesperE：所说的，专注于代码，而不是编码器。

当您看到某些东西时，您认为应该有所不同，但其他人则不这么认为，然后从提出导致缺陷的问题开始，而不是指出这些缺陷。例如：

Globals：您认为我们想拥有不止一个吗？您认为我们将要控制对此的访问吗？

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

我还发现，专注于自己的局限性会有所帮助，这可以帮助人们放松身心。例如：

长功能：我的大脑还不够大，无法一次容纳所有这些。我们如何制作我可以处理的小件物品？

坏名字：阅读清晰的代码时，我很容易混淆；当名字令人误解时，对我来说就没有希望了。

最终，目标不是要教您的团队如何更好地编码。这是为了在您的团队中建立一种学习文化。每个人都向其他人寻求帮助，以成为一个更好的程序员。

介绍代码标准的思想。关于代码标准的最重要的事情是，它提出了代码库中的一致性的想法（理想情况下，所有代码应看起来像是一个人坐在一起坐的），这将导致更易于理解和维护的代码。

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

解释为什么功能比剪切和粘贴更好。

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

说明为什么全局变量是危险的，而局部变量会使生活更轻松。

简单地编写一个编码标准并说“执行此操作”是没有用的，因为它没有向程序员解释为什么这是一件好事。

首先，我要谨慎判断，不要太快。当可能有很好的理由时，很容易将某些代码视为不好的代码（例如：使用具有奇怪约定的旧代码）。但是，让我们暂时假设它们确实很糟糕。

您可以根据团队的建议，建议建立编码标准。但是，那时您确实需要考虑他们的意见，而不仅是将您的愿景强加于什么好代码。

另一种选择是将技术书籍带入办公室（代码完成，Effective C ++，实用编程器...），并提出将其借给他人使用（“嘿，我已经完成了，有人想借吗？” ）

如果可能，请确保他们了解您是在批评他们的代码，而不是他们自己的代码。

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

“嘿，我认为这种方式也行得通。你们怎么看？” [使用手势明显改善屏幕上的代码]

进行代码审查，然后从审查您的代码开始。

这将使人们在整个代码审查过程中都放心，因为您是通过审查自己的代码而不是他们自己的代码来开始该过程的。从代码开始，还将为他们提供如何做事的良好示例。

他们可能会认为您的风格也很臭。召集团队一起讨论一套一致的编码风格准则。同意某事。不管是否适合您的风格都不是问题，重要的是只要能够保持一致就选择任何一种风格。

举个例子。向他们展示正确的方法。

慢慢来。不要马上就为每一个小错误而them之以鼻，而要从真正重要的事情开始。

代码标准的想法是一个好主意。

但是，请考虑与您的朋友不说话，尤其是因为这很有趣，尤其是因为这很有趣。只是代码而已...

盖里·温伯格（Gerry Weinberg）的书“计算机编程心理学”中有一些非常好的建议-他的“无我编程”的整个概念都是关于如何帮助人们接受对代码的批评，而不是对自己的批评。

不良的命名习惯：总是不可原谅的。

是的，不要总是认为自己的方法更好……这可能很困难，但必须保持客观性。

我曾经在一个具有如此可怕的功能命名的编码器上工作过，代码比不可读更糟糕。这些功能掩盖了他们所做的事情，这些代码是荒谬的。而且他们可以保护/抵制其他人更改其代码。当他们非常礼貌地面对时，他们承认它的名字不好，但是想保留对代码的所有权，并且会回去并在“稍后的日期”对其进行修复。现在已经过去了，但是您如何处理已确认但又受到保护的错误呢？这种情况持续了很长时间，我不知道如何突破这一障碍。

全局变量：我本人并不喜欢全局变量，但是我知道一些其他非常喜欢它们的优秀程序员。如此之多以至于我开始相信它们在许多情况下实际上并没有那么糟糕，因为它们可以使代码清晰，易于调试。（请不要对我开火/投票：））归结为，我看到了很多非常好，有效，无错误的代码，这些代码使用了全局变量（不是我自己输入的！）和大量的越野车，无法读取/维护/修复精心使用正确模式的代码。也许有IS的地方（尽管可能萎缩）为全局变量？我正在考虑根据证据重新考虑我的立场。

使用某些Wiki软件在网络上启动Wiki。

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

指出每个人。允许反馈。

当您发布软件时，请负责将代码放入构建版本中的人员推回开发人员，将他们指向其上的Wiki页面。

我已经在组织中做到了这一点，人们花了几个月的时间才真正开始使用Wiki，但是现在这是必不可少的资源。

如果您甚至有一个宽松的编码标准，也可以指出这一点，或者表明您不能遵循该代码，因为它的格式不正确可能是值得的。

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

我总是沿用“这就是我要做的”这一行。我不会尝试教他们，也不会告诉他们他们的代码是垃圾，而只是提出一种替代观点，希望可以向他们展示明显更整洁的东西。

让有问题的人员针对他们所编写的代表性模块的代码向小组中的其他人进行演示，然后由问题与解答来解决（相信我，它会，并且如果它是一个好的小组，它甚至不应该变得难看）。

我确实喜欢代码，并且从没有生活过任何与信息学相关的课程，我一开始就很差劲，也开始从示例中学到东西，但是自从我读了《四人帮》这本书以来，我一直记得并牢记的是：

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

考虑到这一点，在代码中有很多事情要做；）

我不能足够强调耐心。我已经看到这种确切的事情完全适得其反，主要是因为有人希望立即进行更改。不少环境需要进化的好处，而不是革命的好处。而且，通过今天强迫改变，它可以为所有人创造一个非常不愉快的环境。

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

听起来您所处的环境具有很多“个性”。所以...我不会建议一套编码标准。您将遇到这个您想参加的“有趣”项目，并将其变成一个高度结构化的工作项目（哦，太好了，接下来的功能文档是什么？）。相反，正如其他人所说，您必须在一定程度上进行处理。

保持耐心，并朝着您的方向教育他人。从边缘开始（指向您的代码与其他人进行交互的地方），然后在与他们的代码进行交互时，尝试以此为契机讨论他们创建的接口，并询问他们是否可以更改（通过更改）您或他们）。并充分说明您为什么要更改（“它将帮助更好地处理更改的子系统属性”或其他内容）。不要挑剔，尝试改变您认为错误的所有内容。一旦您与其他人进行了互动，他们就应该开始了解它如何对他们的代码核心有所帮助（如果您有足够的动力，请更深入地开始真正地讨论现代技术和编码标准的好处）。如果他们仍然看不到...也许您

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

祝好运。

我不穿长袍，打开一罐苏格拉底式的方法。

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

许多答案都与代码格式相关，而这些格式如今已不再特别重要，因为大多数IDE都会以您选择的样式重新格式化您的代码。真正重要的是代码的工作方式，发布者可以正确查看全局变量，复制和粘贴代码以及我的惯用语，命名约定。有这样的事情，例如错误的代码，它与格式无关。

好的方面是，大多数原因都是有充分理由的，是不好的，这些原因通常是可以量化和可以解释的。因此，以非对抗的方式解释原因。在许多情况下，您甚至可以为写手提供问题变得明显的方案。

我不是项目的主要开发人员，因此无法强加编码标准，但是我发现错误的代码通常会导致问题早于而不是晚，并且当我这样做时，我会提出更清晰的想法或解决方案。

通过当时不打扰和采用更自然的方法，我赢得了领导的更多信任，他经常求助于我，并为我提供项目所使用的体系结构设计和部署策略。

人们写不好的代码只是无知的一种症状（不同于愚蠢）。以下是与这些人打交道的一些技巧。

• 人们的经历给人留下的印象比你要说的要强烈。
• 有些人对他们产生的代码不感兴趣，不会听您说的话
• 配对编程可以帮助分享想法，但可以切换驾驶者，或者他们只是在手机上查看电子邮件
• 不要淹没他们太多，我发现甚至连持续集成都需要向一些年长的开发者解释几次。
• 让他们再次兴奋，他们将要学习。就像一天编程机器人一样简单
• 信任您的团队，在构建时对其进行检查的编码标准和工具通常永远不会被阅读或烦扰。
• 删除代码所有权，在某些项目上，您会看到代码孤岛或蚁丘，人们说那是我的代码，您无法更改它，这非常糟糕，您可以使用配对编程将其删除。

与其让他们编写代码，不如让他们维护自己的代码。

除非他们必须保持蒸腾的意大利面，否则他们永远都不会明白自己在编码方面有多糟糕。

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

一所学校甚至说过，你不应该指出错误，而要专注于正确的做事。例如，您应该指出它们的代码特别容易阅读的地方，而不是指出难以理解的代码是不好的。在第一种情况下，您是在引导他人像笨拙的程序员一样思考和行动。在后一种情况下，您将像熟练的专业人员一样思考。

我和我一起工作的人也有类似的感觉。.他们没有像我一样有编码经验，但是他们在编码方面仍然很有用。

而不是让我去做他们想要的事情，然后回去编辑整个内容。我通常只是坐下来，向他们展示两种做事方式。他们的方式和我的方式，由此我们讨论了每种方法的优缺点，因此对如何进行编程有了更好的理解和更好的结论。

这是真正令人惊讶的部分。有时他们会提出甚至我都没有答案的问题，经过研究，我们都对方法论和结构有了更好的理解。

1. 讨论。
2. 告诉他们为什么
3. 甚至不要以为你永远是对的。有时甚至他们也会教你一些新东西。

那就是如果我是你我会怎么做：D

效果可能会晚一些，但这是达成共识的编码标准的好地方。

我坦率地认为，当人们更容易更改，调试，导航，理解，配置，测试和发布（修改）时，其代码会更好。

话虽如此，我认为如果不先告诉别人他/她的代码不好，就不可能先告诉他/她的代码是不好的，或者后来有人应该如何增强它（例如，创建新的功能或调试它）。

只有这样，他们的头脑突然跳动，任何人都可以看到：

• 全局变量值更改几乎总是无法跟踪的
• 庞大的功能难以阅读和理解
• 模式使您的代码更易于增强（只要您遵守它们的规则）
• （等等）

结对编程会议也许可以解决问题。至于强制执行编码标准，它很有帮助，但它们与真正定义什么是好的代码相距太远。

您可能希望将重点放在不良代码的影响上，而不是仅仅作为您对样式好坏的主观意见而忽略的内容。

私下询问一些“不良”代码段，着眼于它实际上是合理的代码（无论您的性格倾向如何）或存在令人生厌的情况的可能性。如果您仍然确信代码是很糟糕的-源实际上就是这个人-那就走开。可能会发生以下几种情况之一：1）这个人注意到并采取了一些纠正措施，2）这个人什么都不做（被遗忘了，或者不像你那么在乎）。

如果＃2发生了，或者＃1从您的角度来看并没有带来足够的改进，并且正在损害项目和/或对您造成足够的影响，那么可能是时候开始开展活动以建立/加强标准了团队。这需要管理层的支持，但是从基层开始鼓舞是最有效的。

祝你好运。我感到你的痛苦兄弟。