如果有人告诉您您的代码一团糟，您将如何反应？

我是一个很好的程序员，或者我以前就这么想过。我一直喜欢编程。我想学习很多有关编程的知识，以使我成为一名更好的程序员。我学习了1年的编程知识，现在我从事程序员工作将近2年。简而言之，我有将近3年的编程经验。

我们的团队由5位程序员组成，其中我们4位是新手，其中1位具有3年以上的经验。我们已经为一个程序工作了将近一年，没有人审查过我的代码，并且给了我一个可以使用的页面。我们从未进行过代码审查，而且我们都是新手，所以我们不知道干净的代码是什么样。我认为程序员可以自己学习？

我们在没有进行全面测试的情况下将程序部署到了程序中。现在已经很严格了，在对代码进行更改之前，我们需要首先获得批准和代码审查。有人第一次审查我的代码，他说这是一团糟。

我感到很难过和受伤。我真的很喜欢编程，让他们说这样的话真的很伤害我。我真的很想提高自己。但似乎我不是电影中的天才程序员。您能给我建议如何做得更好吗？您是否曾经遇到过批评您的代码的事情并且感到非常受伤？你在那些事件上做什么？

事实是，大概两年后，当您看到当前代码时，您会同意这是一团糟。学习编程是一个永无止境的过程，总会有人比你做得更好。

因此，如果说您的代码烂摊子的人不仅是刻薄的意思，而且不是程序员之间常见的“我会做得更好”疾病的另一种情况，您应该问他/她代码到底有什么问题以及如何解决？改进它。

不要为您的编码水平感到自豪。对您的学习水平感到自豪。然后得知您的代码需要改进，这为您提供了一个机会来证明自己在学习中的表现，而不是因为批评自己是多么糟糕的程序员。

如果您不知道我在说什么，请阅读http://www.perlmonks.org/?node_id=270083。

20多年后，我知道自己的一些代码仍然很烂。最终的结果是在编写最佳代码与编写完成工作所需的内容之间做出决定。在约定的时间范围内完成工作比任何时候都对技术完美无止境的追求更为重要。

诀窍是学会接受它。学会接受自己可以做得更好。学会忍受缺陷。学会接受这次您可能并不会在下次也无法使其完美的选择，并且这是一个刻意的选择，因为替代方案无法实现。更糟的是。

免责声明：任何这些都不应理解为“错误代码可以”。

每个人的代码都是一团糟，没有优秀的程序员。

有：

• 出货速度很快的程序员
• 总是会发送语义正确代码的程序员，
• 总是想出最佳解决方案和最快算法的程序员，
• 程序员，其代码易于使用。

他们几乎永远也不会成为同一个人。

并且有but脚的程序员需要成长并且：

• 问什么问题
• 个人不发表评论，以衡量他们作为一个人的价值；
• 意识到团队中存在语法准则，并且必须遵循它们，而且它们是任意的，因此它们无济于事，因为没有最优的解决方案，也没有最终的答案；
• 更好地注释他们的代码；
• 更好地注释他们的代码；（原文如此）
• 发现更容易调试，不太聪明的简单，平凡任务的解决方案；
• 上SQL课
  （为了安全起见，我会送世界上一半的人口参加SQL课）

这不是艺术，而是工艺。
我们理所当然地认为您很聪明：您正在编程计算机，天哪。
仍然AMD64并且x86不受您散文的影响。保持简单。

好吧，一个人说您的代码是一团糟，即使他们是正确的，也不是建设性的。他们有没有给您说明混乱的原因？就像方法太长，职责混合在一起，分支太多，等等。老实说，一年前我写的任何代码我都说完全是废话，因为从那时起我学到了很多东西。因此，不要为此感到难过。如果您仍然喜欢阅读很久以前编写的代码，我会更加担心。

您的代码库越干净，花费在与代码库进行战斗以解决给定问题上的时间就越少。一年是很重要的一年，因为您会感觉到在项目早期做出的任何设计决策的痛苦。

在我当前的项目中，由于对技术堆栈更加满意，我们进行了多次重构。应该鼓励这样做，并且由于当前的代码库，您应该记下比原本需要花费更多时间的任务。

您是否遍历了所编写代码的某些较旧部分？您可能会看到您现在想做不同的事情或重构的事情。

同样，当您提到缺乏测试时，这总是需要注意的地方。在我们的项目中，我们没有进行自动化测试，因此产生了许多高度耦合的代码。即使您不定期编写单元/集成/任何测试，花一小会儿也会使您养成使代码更具模块化（从而减少混乱）的习惯。

我感到很难过和受伤。我真的很喜欢编程，让他们说这样的话真的很伤害我。我真的很想提高自己。

那很好。这比“我的审稿人不知道他在说什么”，“我的审稿人太挑剔”或只是“我的审稿人不喜欢我”而忽略它们这样的反应要好得多。这种态度是一件好事。

但似乎我不是电影中的天才程序员。

不知道您会看哪种电影，但是电影中90％的程序员都是假的，直到序列结束时我都哭了。

您能给我建议如何做得更好吗？

阅读和练习。查阅诸如Code Complete或The Pragmatic Programmer之类的书籍。在亚马逊上寻找类似的书。

您是否曾经遇到过批评您的代码的事情并且感到非常受伤？你在那些事件上做什么？

为什么感到受伤？首先，我对自己是个白痴感到失望。我用这种动机来清理代码，确保我不会再犯同样的错误。我想做的最后一件事不是从中学到东西。您已被放下一次，出于相同的原因，不要让它再次发生。

没有一个程序员天生就是完美的，甚至是亲密的。您编写的代码越多，获得的评论和提供的评论就越多，这将使您成为一个全面的更好的程序员。

对于我来说，成为一名开发人员最好的事情之一就是每天都是学习过程。总会有某个人不知道你在做什么，而总会有某人知道你在做什么。我当然不会认为自己会处于初级/初级水平，但是我很感激任何批评，只要它既合理又受到尊重。

可能合适的类比涉及我在大学期间担任写作导师的时间段以及参与创意写作课程的时间段。就所有意图和目的而言，编写代码都非常像写诗，短文，小说或小说。每个人都有自己的解决方法，但与此同时，即使是最优秀的作家（或者，在这种情况下，开发人员）也会犯错或任重道远。我们常常可能无法注意到这些事情，因为我们已经习惯了自己的声音（或者在这种情况下，再次是代码风格）。

就像在任何领域一样，有些人被认为是专家。如果这些人不存在，我们将没有人可以学习。假设所讨论的这个人确实是专家，我会听他说的话，然后问他会建议您做什么以改进您的代码。但是，永远不要忘记，他不是唯一可以提供帮助的人。我们很幸运，存在大量资源，例如SE / SO。

混乱是相当主观的。您所能做的最好的事情是实际上问那个人（或评论报告）：为什么它很乱？（从他们的角度来看）

他们一定会回答您的，您将可以：

• 反对它（当然，如果您有充分的理由这样做）
• 感到非常高兴，因为您刚刚学到了一些新知识，并且由于您现在知道如何通过他们的建议减少混乱，因此将来的代码注定会更加出色。

您担心的事实是一个好兆头。让我们开始吧。您提到您喜欢编程，但是您喜欢成为专业程序员吗？发烧友和专业人士之间有很大的不同。作为专业人员，您将不断对您的工作产品进行审查。

Our team is composed of 5 programmers, and 4 of us are new

您已经工作了两年，没有任何对抗，这一事实告诉我，您的工作很轻松，如果您实际上想成为一名专业人士，那就不好了。请注意，世界上一些最好的程序员都在Linux基金会上工作，请放心，他们在犯边际错误时不会受到友善的对待 ……更不用说“凌乱的代码”了。

为了快速回顾一些相当标准的编码准则，Linux Community Contributors Standards应该使您对追求产品的责任等级有所了解。请参阅正确获得代码。

为了进一步肯定这一点，您应该学会接受审查，因为大多数优秀软件都经过了全面审查。这支持了Linus的法律声明...

“如果有足够的审稿人，所有问题都很容易解决。”

就我个人而言，我见过技能娴熟，负责任和可靠的开发人员会拿斧头来处理一些简单的事情，例如忘记留下评论……所以，如果有人告诉您您的代码一团糟，那可能就是……克服它……重构。这是演出的一部分。

I feel so sad and hurt. 

去做一个悲伤的应用程序，以评估不使用自己时的沮丧程度。

您回答了您的问题...您没有测试！

在看到您说出您的Java开发人员的评论后，我几乎不高兴。因此，如果我正确理解您的说法，即您和您的开发团队正在Java商店工作，并且没有针对您的应用程序的测试框架...

谎言擦

“我们在没有进行全面测试的情况下将程序部署到了程序中。”

抄写UML创建者Grady Booch ...

业余软件工程师总是在寻找魔术，某种轰动的方法或工具，其应用有望使软件开发变得微不足道。知道不存在这样的灵丹妙药是专业软件工程师的标志。

Alistair Cockburn在他的网站上提供了大量有关使用敏捷方法为您和您的团队提高绩效和质量的信息。

编程{和生活}最重要的方面之一就是了解自己的长处和短处。如果您不擅长于自己的弱点，那么您将不会拥有全面的技能。

Outro ...您的情况还不错-别抱怨。不断发展自己的技能，让您对编程的热情继续前进。祝好运 ：-）

不要让您的情绪阻碍代码的改进。代码审查的目的是发现问题，因此，如果有问题，您不要太惊讶。话虽如此，它们也不应该是一场编码狂。

他们也不应该只是说“ Ewwww”而已。在编程中总是有某些原因是错误的。例如，到处乱放很多注释掉的代码是错误的，但是这是错误的，因为它会使代码混乱，使代码难以阅读，而不是因为有人在书中这么说。

您的代码不是您。请记住。

我将在这里成为鸡巴，并根据..很好的意见提出建议。显然，您的代码是一团糟，或者您要问的问题是“为什么有人说我的代码是一团糟？” 但是您没有挑战这个假设。您只是在表现伤害，坦率地说，可能会哭泣，但是没有理由证明编程的合理性。

但是真的，你为什么要问？您知道您的代码很烂，或者您会问另一个问题。如果有人告诉我我的后端Web代码很烂，我会笑着说“好吧，这是怎么了？” 如果他们告诉我我的JavaScript臭味，我会给他们社会程序员一个像胖子一样的嘴，而且我永远也不会征求有关如何应对的建议，因为这些小母狗显然是错的！

拥有自己的专长。我真的是要对此负责。因为只花了一点时间就可以猜到你。不要要求许可才能好。只知道你的东西。结束。

记住这一点：您将看到的最糟糕的代码是您自己的！

codinghorror.com的Jeff Atwood写了很多关于该主题的文章，您可能想从这里开始：http : //www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

如果要改进，请开始阅读有关编码样式，模式，工作流以及基本上所有可以接触的内容的知识。另请了解更多编程语言，了解它们的用途。如果您要进行OOP，请阅读以下内容：http : //en.wikipedia.org/wiki/Design_Patterns

还可以与其他程序员交谈，并进行配对编程或观看其他代码。

犯错误是不可避免的，重复犯错是不可避免的。

大多数情况下，您应该对告诉您的人说“谢谢”。

他们有可能在乎自己的职业，在乎自己的工作，在乎自己的团队，在乎您。

很难接受批评。不要为此生气。想想他们想告诉您什么，不要让您的情绪变得更好。

我从事编程已经很长时间了（30年），我的风格和代码一直都在改进（我希望如此）。我知道其改进的唯一方法是当其他人告诉我或者我是否回头查看我的代码时。

尝试查看您职业生涯开始时编写的代码。您现在看起来像什么？它看起来是否像您编写时所认为的一样好；）

首先，您必须了解编程是一个迭代过程，就像写一篇文章或一本书一样。首先，您要编写程序的“草稿”，以使其正常工作。在这一阶段，您的代码将变得一团糟。因此，您进行重构以使代码干净。然后，您分析并查看需要进行哪些优化以使其快速完成。诀窍是要不断进行重构，否则混乱会加剧。您必须定期清洁代码，就像必须清洁房屋一样。

代码审查是绝对必要的。您必须至少用另一双眼睛查看您的代码。当您花费大量时间查看代码时，就会习惯了，并且很容易错过同事可能立即注意到的错误或代码异味。

另外，向他人解释您的代码的行为也是查看您是否错过任何内容的好方法。这就像阅读要大声写的论文。您的大脑以不同的方式处理音频和视频信息，并且您可以通过切换模态来发现推理中的缺陷。另外，如果您向同事解释代码，但对她而言没有任何意义，则表明您应该重构代码。

在进行代码审阅时，对于作者和审阅者来说，在门口检查他们的自尊心非常重要。目的是使代码更好。因此，审稿人必须尊重他人，作者必须保持开放的态度。请记住，您的同事是必须维护您的代码的人，因此对他们来说必须很清楚。如果审阅者不了解变量的作用，则将其重命名。如果审阅者不了解代码块的功能，则将其重构为具有描述性名称的函数。无论您怎么想，如果您的同事无法理解您的代码，那是不好的。

说到重构，您绝对必须拥有一个单元测试框架，因为没有它，您将无法重构。

最后，我强烈建议阅读Robert C. Martin的“ Clean Code”。它将告诉您代码为何一团糟，以及如何清除它。

您能给我建议如何做得更好吗？

Jay推荐书的答案是一个很好的答案，但是听起来您已经处在一个转折点。

过去：

我们的团队由5位程序员组成，其中我们4位是新手，其中1位具有3年以上的经验。我们已经为一个程序工作了将近一年，没有人审查过我的代码，并且给了我一个可以使用的页面。

当下：

现在已经很严格了，在对代码进行更改之前，我们需要首先获得批准和代码审查。

听起来您的公司/团队/部门正在学习整个项目，团队管理以及编程方面的知识。如果受到适当的关注，那么开始审查代码是在几乎所有领域进行改进的绝佳机会。

以此为契机；假设您正在（与团队中的其他开发人员一起）进行同行评审，则他们会认为此过程很重要，每个人都可以从中学习。

在基线上，将进行快速回顾，结果是“是的，看起来不错”。通过更加集中的努力，您可以相互抵消想法，“是的，但是您可以以这种方式进行处理，这将使您的目标更加清晰……”。即使代码可以部署，也请记下以备将来使用。

如果这将是成功的，则需要让您的团队和经理站在一边，这通常意味着向他们解释好处。对于其他开发人员来说，这是一个学习的机会。对于您的经理来说，这是一个机会，可以用很少的成本提高团队的技能，因此可以创建具有更高价值的输出a）具有更高价值的输出或b）具有更快c）的维护成本（通常是大问题！）的输出。

这是一种文化变革，您不能自己强行改变，但可以帮助朝正确的方向推动事情！

别忘了，这是一种文化变革，对组织可以产生巨大的好处。优秀的经理会认识到您正在努力使整个团队变得更好，这是值得的。

您能给我建议如何做得更好吗？您是否曾经遇到过批评您的代码的事情并且感到非常受伤？你在那些事件上做什么？

答案可以在新一代公司中找到。我曾经去过Google和FaceBook之类的公司，我发现如果您虔诚地遵循Agile / Scrum流程，那么您可以编写更好的代码并在每次冲刺时都对其进行改进。

How to be better? 

答案是持续重构。像Visual Studio这样的现代开发工具拥有许多可在此过程中帮助您的工具。如果您遵循Scrum软件开发过程，例如说，您在sprint周期1中编写了错误的代码，而有人指出在审核中这是不好的，那么在sprint 2中，您就有机会重构代码。

由于缺乏良好的流程，这些问题首先发生。因此，解决方案是为您的团队提出一个良好的软件开发流程，并进行连续重构。

我要感谢他们的反馈，然后请他们解释是什么使它变得糟糕以及应该如何改进。

如果您同意提供反馈的人员是有意义的，请考虑在将来进行更改。但是请记住，仅仅是因为有人说那并不意味着那是真的。

您能举一个所谓的“烂摊子”的具体例子吗？

首先，有人说您的代码很烂是很模糊和主观的。对于不同的人来说，这可能意味着不同的事情。这就是为什么；有两件事必须要考虑。

结构体

您的代码结构受语言，行业标准和公司标准控制。显然还有其他因素。

这些是皮棉，测试工具和类似产品旨在识别的错误类型。它们定义明确，您或您的工具可以就其有效性/正确性做出客观决定。

样式

尽管有标准的代码结构/规则，但每个开发人员在编写和处理问题或任务时都有自己的风格。在任何团队环境中进行代码维护，随着时间的流逝，您将能够根据其样式对谁编写了代码进行有根据的猜测。您还将发展自己的风格，随着经验的积累和学习技巧的变化，风格也会发生变化。

因此，每当有人说您的代码很混乱时，如果他们在谈论结构或样式，就需要了解它们。他们是两件截然不同的事情；结构是客观的，风格是绝对主观的。

话虽如此，来自其他程序员的任何建设性反馈对您来说都是非常有价值的。这完全取决于您以及如何接受批评。随着时间的流逝，您将了解到谁的观点值得深思，而谁的观点却令人吃惊。

随着您事业的发展，您将回顾自己的代码，并看到可以做得更好，更清洁，更快的事情。这是整个学习过程的一部分，看到自己过去的错误确实表明您正在磨练和提高自己的技艺。

不要让一些批评削弱您的情绪。充分利用它，如果它有意义且有价值，请将其添加到您的知识储备中。

认识到自己的代码何时变得混乱很重要（在程序员中，这是非常典型的感觉，尤其是随着他们变得更加有经验，并且他们的代码年龄更早），而在别人告诉您时，倾听则更为重要。

在您自己的代码中只能识别出很多问题，因为它是在当前编程知识的约束下产生的。

代码审查是必不可少的学习机会，因为它可能使你接触新上的代码（否则你会使用它，就没有乱）工作，而你没有知识。

我认为处理负面反馈有两个部分。

1.确定提出的问题的性质以及您应该从中学到什么

当我查看或检查我的代码时，我大致在以下存储区中对有关代码问题的信息进行排序：

• 违反严格的技术要求
  • 完全错误（不起作用或未达到要求）
  • 在其他情况下（环境/配置更改）将失败
  • 使用不推荐使用的功能，并将在可预见的将来打破
• 违反行业最佳做法，缺乏诸如
  • 使用经过验证的方法解决特定问题
  • 性能
  • 向后兼容
  • 易于维护
  • 编码风格
  • 文件资料
• 违反工作场所最佳做法
  • 与行业相同，但更特定于公司/同事，在细节上可能与行业不同
• 与个人专业知识不符
  • 可以通过一些方式改进

请注意，这范围从非常客观的事情（“部署到我们的生产服务器时会破坏”）到非常主观的事情（“我不喜欢如何命名变量”）。

2.确定将对代码进行哪些更改（如果有）作为审核结果

处理完信息后，将决定是否可行以及是否应更改代码。这不一定是您的决定，您的意见可能重要，也可能不重要，这取决于所涉及的各方和您的情况（高级等）。但是可能的结果大致是：

• 全面解决问题
  • 修复损坏
  • 格式化为所需的编码样式
  • 等等
• 如果应该全部或部分解决问题，可能会有所妥协，因为可能存在
  • 没有资源（例如时间或预算）
  • 不需要（只会实现微不足道的改进，损害稳定性等）
• 开始了解所提出的问题无效
  • 反馈（尤其是来自主观意见类别的反馈）可能完全是有害的，不应盲目地采取行动

您已经了解到，获得负面反馈会很痛苦，而且很可能在将来的每个时候都会很痛苦。但是，您已经离开了学习，这是多么重要的学习机会，以及该过程如何帮助您提高专业水平和工作场所，以实现更好的代码基础。

好吧，不要觉得坏。最终，您将从错误中学习。解决问题后，您可以与盖伊交谈，让他觉得您想改善。尝试多听，少辩论。

我已经经历了这种情况，我可以理解。

TL; DR

如果有人告诉您您的代码一团糟，您将如何反应？

我直截了当的说：“太久没读（所有答案-抱歉，我希望以后能有时间再编辑，如有需要，可以修改）”：答案/提示：

• 好老同行评审。要求具有不同集体思维，专业知识水平和/或积极性水平的不同人员检查您的代码。
• 只是为了详细说明我所说的“不同”同级组的含义：与Reddit相比，StackExchange散居社区可能是最知名，最专业和受人尊敬的组，因为加入该组比较困难。Reddit在更受欢迎的子Reddit中往往非常激进-但奇怪的是，编程子Reddit非常友好（根据我的经验）。

XDK论坛人群是侵略性，帮派类型心态的一个很好的例子，也许是最好的例子，也是我为Android论坛/ IRC频道的民众送给CyanogenMod的最差奖杯。

那比我打算的要长一些。我的意思应该是-得到各种各样的评论，但重点是要从了解他们的贸易并知道什么是建设性批评的人们那里得到诚实的批评。哦，可以接受任何形式的批评而不会令您失望。经验法则：如果您开始听到与可能与评论有共同之处的相似评论，那么请进行更彻底的自省。