如何向同事证明他们制作了糟糕的代码？

Question

我发现在目前的工作中工作有点困难。

最近代码库变得有点疯狂（但绝对不是我见过的更糟糕），而且我很难处理代码的某些部分。我可能是愚蠢的，但很可能只是因为它让我很失望，开始研究一些难以理解的事情。

我的老板已经意识到了我的想法 - 我表达了感觉这样工作的感觉。他让我举例说明出了什么问题。当我指出两个或三个小问题时，他说“是的，好的”，但重构花了他很多钱，我们必须把产品拿出来（不是我第一次听到这个）。

我不得不承认这些例子并不是最引人注目的，但问题实际上很难解释。它由整个代码库中的许多微小“错误决定”组成。 （我们也看到这个问题绝对是主观的）。例如，错误的命名，处理空值，样板，不使代码可重用（或相反）等等。再次重新考虑别人的代码以证明我会以不同方式做到这一点可能会很累。

你对如何处理这个问题有什么看法吗？ 我有点厌倦了每次都要乱砍 quick'n dirty 代码库！

Answer 1

有时你的程序员与你做的事情有很大不同，而你可能觉得错误的事情实际上可能有积极的方面。我们都有自己的学校。我想我经常遇到那些抱怨我不理解的事情的程序员，因为我自己也觉得有些东西需要被抱怨。

确保您可以推断出您抱怨的具体劣势。如果没有其他原因，那么你可以激励中层管理人员改进。难以推断出可衡量的事实的事情通常源于品味/风格的差异而不是质量（有关这个主题的阅读有些博弈）。 smacl 发布的答案有很好的具体建议！

如果你能把你的担忧推到一个真正的劣势，那么当人们说必须“接受”这样的情况时，我真的不同意。我不止一次地接触过这个问题，让我告诉你，重构不是问题的解决方案。 重构仅修复症状。

接受这样的情况就像说“质量差的产品线，昂贵而令人沮丧的维护是我公司可以忍受的”。这在很少的情况下是这样的。然而，管理（即那些有优先顺序的项目的管理人员）往往在技术上并不知道问题是什么，或者为什么开发费用昂贵。他们不应该为此而烦恼。

这就是为什么你需要一个拥有技术主管，首席架构师，良好的组织结构和分层模型的开发组织。经验丰富的软件专业人士，如果你忽略了开发的某些方面，他们已经看到了这条道路的发展方向。这是关于改变团队的“文化”。

要么你坚持你的公司，并试图改变你从根本上做事的方式，要么你找到另一个工作的地方，并确保你在面试中找到他们在每个人的工作方式 - 发展日。

祝你好运

Answer 2

我最近遇到了一个非常类似的问题，一位朋友给了我一些帮助很大的建议。他说：“让自己远离它。”

他的意思是，你必须传达这些问题，因为它们是真实的，代价高昂的问题，在时间和金钱方面都会产生影响。但是当你进行沟通时，只讨论组织的后果。不要提及对你的影响，，因为那时它听起来像是抱怨而且会被忽略。 / p>

例如：

不让自己远离它：

“其他开发人员使用这些模糊不清的误导性标识符然后我必须花费数小时来查看代码，试图发现他们的意思。它占用了很多我的时间。“

让自己远离它：

“对类和变量名称进行一些重构以及围绕标识符建立一些编码标准将是非常有用和经济有效的。直接的回报将是一个易于理解的代码库，适用于每个人，从而提高生产力。长期的回报是，以后我们将能够更快地修改代码并修复问题。如果在发布之前发现了一个关键错误，那么可理解的代码库将非常重要。“

我希望有所帮助。

Answer 3

1）使问题更加明显并获得管理层支持

在大约一个月的时间内，详细记录在各种编码任务上花费的时间。在本月底，分析和总结老板的内容，即浪费时间，浪费金钱，以说明某种形式的变化是必要的。

2）考虑一种经济有效的前进方式

例如;而不是重构整个代码库，从实现中分离接口，并在接口层强制执行更严格的标准，包括单元测试，命名约定等。因此，每个程序员都可以放心使用他们没有编写的代码。虽然这在一定程度上将地毯下的垃圾清扫干净，但这是一种准备大规模重构的好方法。

从管理角度来看，重要的是工作流程不会中断，并且可以看到积极的结果，因此需要进行相应的计划。

3）与您的同事达成更长期的条款改进

坐下来与其他程序员商定未来代码的合理编码标准。

Answer 4

也许您可以设置每月会议，在那些会议中，您可以展示好的和坏的代码。显然你不想指责，所以你想要使用基于你在项目中看到的东西的通用代码示例。通过这种方式，您可以建立性地从您的风格中收集其他人的支持。您可能希望在会议结束后编译这些内容，以便人们可以轻松地引用它们。

我认为指出问题真的很容易，并且抱怨但是指导人并帮助他们改变需要付出努力。这不是一项容易的任务，但如果你在工作上遇到困难，或许这会给你带来很好的动力。你可能会学到很多东西。

Answer 5

你会发现这是常见的。你可以做的是接受不同的人做不同的事情。在修复错误或添加功能时，您将获得一个可以改进的应用程序子部分的简短窗口。当你处理代码时，你可以让它变得更好，而且他们不需要知道你是零碎的改进代码。

但是要非常小心。有时代码是以看起来“被黑”的方式编写的，但却解决了一个不容易识别的错误。特别是如果它是经过试验和测试的旧代码。

另一方面，抱怨只会让你被视为抱怨者。想想你想要什么样的结果，以及最有可能产生这种结果的行动。当你问'我能否完成X天的工作而绝对没有明显的结果时，你总会听到答案'不'吗？

Answer 6

你可以放弃并希望找到更好的东西。

或，你可以坚持下去并尝试改进你可以控制的代码，当你可以控制它时。无论开发人员的用心程度如何，如果有多个开发人员，代码库将由合格的开发人员标准“丑陋”。与其他开发人员合作，在您进行增强时提高他们的能力和重构代码。

Answer 7

您是否考虑过将fxcop添加到自动构建中以强制执行编码风格？除此之外，您可以尝试建议TDD，它可以为编写测试的人提供强大的功能，因为每个类的接口都以特定的方式构建。

脱离我的头脑，这就是我能想到的全部。

Answer 8

首先：

1. 强制使用静态代码分析工具。每种语言都有一些众所周知的工具。

2. 在重构的代码示例之前和之后展示一些，并解释为什么你认为它更好。尽量不要让任何一个人当场。

3. 经验丰富的开发人员的代码审核。

4. 请记住，无论您尝试多少，一些开发人员都无法得到帮助...

5. 如果有人批评你的代码是礼貌和开放的，你可能会学到一些东西。

6. Cyclomatic complexity /更改集/错误的数量。复杂的代码更容易破解，导致更多的错误导致更多的更改，这会花费更多的钱！

Answer 9

99％的时间你从未选择与你合作的人。并非所有关系都有效，无论是工作还是其他方面。

最好是你的项目分解得足够好，这样每个开发人员都可以根据对方的需求做出贡献，这样程序员就不会踩到彼此的脚趾。

让人们改变他们的编码风格很难。它需要一个铸铁技术领导致力于这样的事情，并将在你提出它时提供帮助。管理类型不能做到这一点，领导需要提供技术细节。

Answer 10

听起来我对代码没有问题，就像你的同事一样。您可能很难强制要查看的更改。您最好的选择可能是开始更新您的简历并睁大眼睛寻找其他机会

Answer 11

我认为，一旦你处于杂草的中间，你就没有很好的机会把事情做好，你只需要完成它们。我想说大多数开发人员不喜欢消防，并且想要理想的代码库，但在我看来，这需要你花时间预先计划系统。

我建议您尝试与您的经理合作，以确保您认为现在缺少的区域在下一个项目中并不缺乏。也许它会让你领先，与同行进行更多的代码审查，也许这是对整个团队的进一步培训。

无论哪种方式，我认为这是我们大多数人都经历过的事情。我同意另一个人对此提出一些警告。我知道我昨天写的代码在当时看起来很棒并且回顾它，可能会找到其他10种方法来使它看起来更干净。

Answer 12

如果您与您的经理有良好的关系，您可以使用它来自己成为“高级”或“领导”开发人员角色。您可以建议，如果团队中的一个人对代码库进行技术领导，那将是最好的。审核其他人的代码并要求他们在您认为有必要时进行改进将是您的工作。如果你走这条路，就一定要慢慢走。如果你要求很快，那么你最终可能会惹恼所有其他开发人员。

Answer 13

我尝试做的一件事可能对你有所帮助。如果代码的一部分是坏的，并且你打算修改它的想法是最好的，但是给出了“没时间”的理由，为什么不重写呢？说你自己的时间？如果你决定坚持这份工作一段时间它只能帮助你。只有你会学习并成为更好的程序员。

请注意，这是一个好主意，我甚至会说需要，在办理登机手续之前对该变更进行完整的代码审查，并且您应该尝试将签到时间设置为一个完整的注册测试周期之前发布。这样你的重构就完全被测试了。在6个月左右的时间内，它将开始显示有益的影响，然后您可以要求为此分配时间，并提供证据以备份。

Answer 14

唯一有机会说服管理层的事情就是证明你所引用的问题会成为实际问题。

为了尝试利用这一点，尝试将“抱怨者”的语气降至最低，也就是说，关注这会影响底线而不是它如何影响你的感受。指出你认为做出的糟糕决定可能带来的后果。如果这些后果成为现实，并且它们的成本高于前期解决方案所带来的成本，请温和地提醒管理层您预见到了困难并提供了一个有用的建议，即如何通过一些前期努力来避免未来的类似成本。

问题是，在许多组织中，问题永远不会给管理层带来足够的问题，或者如果他们这样做，他们就不会看到你对问题的看法与实际问题之间的联系。发生。在这些情况下，你最终会成为一个不必要的技术人员，这不是你想要的声誉。

所以我的建议是，挑选你的战斗。如果有一些非常令人震惊的事情，其他人即将放弃，那么你可以说出来，也许可以在以后得到证明。对于那些只是扼杀你的小细节，我担心除了忍受之外没什么可做的。

Answer 15

向他们展示他们自己被遗忘的代码伪装成你的批评。

• 拿走他们忘记的旧代码
• 假装你写了
• 让他们弄清楚它的内容
• 确保他们指出代码无论出于何种原因有多糟糕
• 添加您自己的项目。头脑风暴应该做什么，因为这是你的错。
• 让他们知道你不知道如何冒犯他们，但这是他们的代码。

如果他们回忆起他们写了它，他们可能会抓住......

Answer 16

生活中的事情并不完美，如果你开始挑剔，羽毛会被褶皱，关系会变得很糟糕。

最好的方法是仔细挑选你的战斗。如果某些东西足够小，请忽略它并与之共存。如果它很大且值得（即管理层看到投资回报率支持你），那就去吧。

这适合您的情况......

上帝，赐予我宁静的接受，我无法改变勇气，改变我能做的事情和知道差异的智慧。