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

#1 楼

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

因此，如果说您的代码是一团糟的人不仅是卑鄙的，而且不是另一回事。在程序员中常见的“我会做得更好”这一疾病，您应该问他（她）代码到底有什么问题以及如何改进它。

#2 楼

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

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

#3 楼

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

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

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

#4 楼

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

有：


程序员可以快速发布，
程序员在语义上总是正确的代码，总是能提供最佳解决方案和最快算法的程序员，
程序员的代码就很容易。

他们很难，如果有的话，最终是同一个人。

还有一些蠢蠢欲动的程序员需要成长，并且：


问什么问题，
不发表评论，衡量他们作为一个人的价值；
意识到团队中有语法准则，必须遵循这些准则，而且它们是任意的，因此不应无聊地讨论它们，因为没有最佳解决方案，也不是最终的决定；
在注释其代码方面变得更好；
在注释其代码方面变得更好； （sic）

发现更容易调试，更不聪明，解决简单，平凡的任务的解决方案；
用SQL上一堂课（我会派出世界上一半的人口来上课在SQL中，只是为了安全起见）


这不是艺术，而是一种手工艺品。
我们认为您很聪明：您正在对计算机进行编程，
仍然AMD64和x86不受您散文的影响。保持简单。

#5 楼

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

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

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

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

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

#6 楼

我感到很难过和受伤。我真的很喜欢编程，让他们说
那样的话真的很伤害我。我真的很想自我改善。


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


但我好像不是电影中的天才程序员。


不确定您看过的那种电影，但是电影中90％的程序员都是假的，直到序列结束时我都流下了眼泪。


能不能给我一些建议， ？


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


您是否曾经遇到过一些批评您的代码的事情，并且感到很受伤？在这些事件上您怎么办？。


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

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

#7 楼

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

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

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

#8 楼

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

他们一定会回答您的，您将可以执行以下操作之一：


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

#9 楼

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

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 ...您做得很好-别抱怨。不断发展自己的技能，让您对编程的热情继续前进。祝你好运:-)

#10 楼

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

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

您的代码不是您。记住这一点。

#11 楼

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

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

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

#12 楼

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

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

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

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

#13 楼

大多数时候，您应该对告诉您的人说“谢谢”。

机会是他们在乎自己的职业，在乎自己的工作，在乎自己的团队，在乎关于你的事。

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

我已经编程很长时间了（30年），我的风格和代码在不断完善一直（我希望）。我知道它会有所改善的唯一方法是当其他人告诉我或者我回头查看我的代码时。

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

#14 楼

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

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

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

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

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

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

#15 楼

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


杰伊的建议书是不错的答案，但听起来您的工作正处于转折点

过去：


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


现在：


现在很紧，在对代码进行更改之前，我们需要先获得批准和代码审查。


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

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

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

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

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

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

#16 楼

您能给我建议如何做得更好吗？您是否曾经遇到过批评您的代码的事情，感觉真的很受伤？您如何处理这些事件。


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

How to be better? 

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

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

#17 楼

我要感谢他们的反馈，然后请他们解释是什么使它变得不好，以及如何加以改善。

如果您同意提供反馈的人是有意义的，请考虑在未来。但是请记住，仅仅是因为有人说这并不意味着事实是真的。

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

#18 楼

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

结构

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

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

样式

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

因此，任何时候有人说您的代码是一团糟，如果他们在谈论代码的话，就需要了解。结构或样式。它们是两个截然不同的事物。结构是客观的，而样式则是绝对主观的。

话虽如此，其他程序员的任何建设性反馈对您来说都非常有价值。这完全取决于您以及如何接受批评。随着时间的流逝，您将了解谁会深深地怀念谁的观点，或者谁会一针见血。

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

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

#19 楼

认识到自己的代码何时会变得混乱很重要（在程序员中，这是非常典型的感觉，尤其是随着他们的经验越来越丰富以及他们的代码年龄越来越早），而在别人告诉您时，倾听甚至更重要。

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

代码审查是必不可少的学习机会，因为它可能使您接触到您在编写代码时没有的新知识（否则您将使用它，并且不会造成混乱）。

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

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

当我审阅或审查我的代码时，我会在大致类似的类别中对有关代码问题的信息进行排序：


违反了严格的技术要求

普通错误（不起作用或未达到要求）
在其他情况下（环境/配置更改）将失败
使用已弃用的功能并将在可预见的将来打破


违反行业最佳实践，缺乏诸如

使用经验证的方法来解决特定问题的性能

向后兼容
易于维护
编码样式
文档


违反了工作场所的最佳实践

与行业相同，但更多特定于公司/同事，并且在细节上可能与行业不同


与个人专业知识不符

可以通过某种方式进行改进



否从非常客观的东西（“部署到我们的生产服务器时会破坏”）到非常主观的东西（“我不喜欢如何命名变量”）。

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

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


完整的地址问题

将损坏的
格式修复为所需的编码样式
等等
/>

如果应该全部解决或部分解决问题，则会有所妥协，因为可能没有资源

（例如时间或预算）

（只会实现微不足道的改善，损害稳定性等）


了解到提出的问题是无效的

反馈（尤其是主观意见类别）完全是有害的，不应盲目地采取行动。




您已经了解到，获得负面反馈让人感到痛苦，并且每次都可能很痛苦。未来。但是，您已经离开了学习这是多么重要的学习机会，以及该过程如何帮助您提高专业水平和工作场所来获得更好的代码库。

#20 楼

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

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

#21 楼

TL; DR


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



我直接说，“太很久没读过（所有答案-抱歉，希望以后能有时间再编辑/修改））”答案/提示：


同行评议很好。要求具有不同集体思维，专业知识水平和/或具有侵略性的不同工作人员来审查您的代码。
只说明一下我所说的“不同”同龄人群体的含义：StackExchange散居国外的人群可能是最了解的，专业和受人尊敬的团队，因为与Reddit相比，加入该团队相对困难。 Reddit在更流行的子Reddit中往往非常激进-但奇怪的是，编程子Reddit非常友好（根据我的经验）。

一个好，也许是最好的激进示例，帮派类型的帮派心态是XDK论坛人群，也是我交给Android论坛/ IRC频道民众的CyanogenMod奖杯中最差的奖杯。

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