在什么时候对代码进行“建设性”批评会变得毫无用处？

我最近开始是一名初级开发人员。作为团队中经验最少的人之一，我也是一名女性，在男性主导的环境中工作时会遇到各种挑战。我最近遇到了麻烦，因为我觉得自己的工作受到了太多不必要的学问批评。让我给你举一个最近发生的事的例子。

团队负责人太忙了，无法推动我开设的某些分支机构，因此他直到周末才加入他们。我检查了我的邮件，但实际上并没有做任何工作的意思，发现我的两个分支已根据变量名被拒绝，使错误消息更具描述性，并将一些值移至配置文件。

我不认为在此基础上拒绝我的分支是没有用的。周末有很多人在工作，我从未说过我会工作。实际上，有些人可能因为我没有时间进行更改并重新提交而被阻止。我们正在开发一个对时间非常敏感的项目，在我看来，完全基于对客户透明的事物完全拒绝代码是没有帮助的。我可能是错的，但似乎我有时间时应在补丁类型提交中处理这类事情。

现在，我可以看到在某些环境中这是正常的。但是，批评似乎分布不均，这就是导致我遇到下一个问题的原因。这些问题中大多数的基础是由于我处于别人编写的代码库中并且试图做到微创的事实。我在模仿文件中其他地方使用的变量名。当我这样说时，我直言不讳地告诉我：“不要模仿别人，做对的事。” 这也许是我本该被告知的最没有用的东西。如果已经签入的代码是不可接受的，那么我该如何判断对与错呢？如果混淆的基础来自底层代码，我认为不是

在这种情况下，我感到非常单调和沮丧。我对遵循预期的标准有了更好的了解，例如，当我将一段代码重构为以前缺少的ADD错误检查时，我感到沮丧，我只是被告知我没有使错误足够详细（并且在此基础上分支被拒绝）。如果我从未添加过该怎么办？如果它是如此错误，它是如何进入代码的呢？这就是为什么我这么单调的原因：我经常遇到这个现有的有问题的代码，以至于我要么模仿要么重构。当我模仿它时，这是“错误的”，并且如果我重构它，我会因为没有做足够的事情而受到指责（如果我一直走下去，引入错误，等等）。再说一次，如果这是一个问题，我不明白任何代码如何进入代码库，

无论如何，我该如何处理？请记住，我在最上面说的是我是女人，并且我确定这些人在查看其他人的代码时通常不必担心礼节，但是老实说这对我不起作用，这使我的工作效率降低。我担心如果我和经理谈这件事，他会认为我无法处理环境等。

您有可能被单挑为女性，但也有可能您只是一个初级开发人员，并且刚开始工作。

错误检查和表达性消息很重要。如果要在代码中添加一些内容，请确保其正确无误并符合团队的标准。同样，如果您要修改其他人的代码，请尝试在可能的地方进行改进-不要重写整个代码，但要尝试使其比您发现的代码干净一些。

您的团队是否遵循编码标准的书面版本？如果没有，最好将其全部写下来。您可以通过写下所犯的错误并将其形成检查清单中的表格来带头进行工作，然后再将更改提交审核。作为副作用，您可以使用该书面标准来对将来的拒绝提出异议。

听起来您和团队负责人之间可能缺乏了解。要求与他进行一对一的会面并讨论您可以做些什么来改进，这可能对您有所帮助。您可能会遇到类似“我感觉我仍然缺少应该做的事情的细微差别。作为初级开发人员，我想要成长和进步。您能帮助我到达那里吗？” 看看会发生什么。

听起来您可能个人太喜欢这个东西了。别; 这种事情一直在发生。

拒绝签到的原因（变量命名，评论质量，配置位置）对我来说似乎很标准。

时机由您的团队领导决定，如果您是我，我不会担心。如果周末有人被挡，团队负责人可以选择允许值机，然后要求您修复。如果他认为适当的做法可以将其收回，即使这可能会阻止其他开发人员，那是他的责任。

至于团队负责人告诉你不要模仿别人，而是要做对的事，听起来他正在努力给你一些主动性，以使代码基础更好。这是一个好兆头。他相信您会使用您的判断力，所以请继续做您所知道的正确的事情。这并不意味着您必须去更改其他人的代码，而是意味着您应该对编写的代码质量负责。

其他答案的补充：

作为首席开发人员，我通常对初级开发人员比较挑剔，因为他们比已经工作了几年的人更具延展性。（我的ppl技能还不是很好。）

很难改变一个已经工作一段时间（并赚取体面的薪水）并且对自己的代码水平感到满意的人（即使可以提高质量）。这些家伙不在乎您是否试图引导他们成为更好/更好的程序员。他们很高兴在代码工厂工作。

像您这样的新人，OTOH通常渴望获得指导，并且知道什么是对的。而且，他们能够吸收费用返还并改变自己的方式。它们不是以其他方式设置的。

如果您将这些建议牢记在心，并使其成为日常生活的一部分，您会发现您将很快编写出优于许多现有代码库的代码。

所以...

..可能只是因为您有潜力从中获得更多反馈而获得更多反馈。:)

您完全有可能被选中，因为...您是一名初级开发人员。

根据您的描述，听起来您好像没有遵循团队领导认为的标准。

解决方案很简单：

• 如果这是标准，请遵循。
• 如果您不了解该标准，请进行澄清。
• 如果您对标准或说明的解释与团队负责人的解释不同，请澄清

不要为此而战。如果您试图使团队领导“错误”，那么即使您获胜，您也会输。学习适当的课程并继续成长。

作者注

几年过后; 我对此进行了编辑，以更准确地反映我对这种情况的感觉。我在回答中加入了更多细微差别，因为我在这些情况下对细微差别有了更多的了解。索取“黑白”答案很容易，但是我们都知道这不是那么简单。我的回答现在反映了这一点。

根据您的描述；您所经历的行为似乎与您的性别无关。这并不是说您没有经历过任何与性别相关的治疗（我希望您没有），只是您所描述的似乎与性别无关。

当我成为团队负责人时，我平等地对待每个人。技术上没有空间可以因为性别而对他人进行恶劣对待。如果发生在您身上，我不知道该如何处理。

重要的是，您必须相信自己的团队负责人平等对待男人和女人。如果有证据表明他不是，那么这句话就适用：改变环境或改变环境。

同样，我的意思是他在不尊重性别的情况下平等对待所有人。如果他的工作做得正确，那么你就不会看到他批评别人。他们不应该看到他在骂你。在团队成员面前，即使团队领导只是花了最后五分钟才私下纠正行为，对团队领导者来说，表现出信心也非常重要。

现在讨论您提出的问题：

您签入的代码不符合他设定的标准，因此他拒绝了您的分支。如果我穿上他的鞋子，我不会以同样的方式做同样的事情，但是我要确保我的下属（奇怪的词；因为我不认为领导者比他们的人民“优越”）导致；但是它准确地（不够充分地）描述了情况）知道正确的做法是什么。如果他们不知道标准是什么，那是我作为领导者的错。我要纠正它。在这种情况下，您可能犯了一个错误，但是纯粹的事实意味着您要么（1）没有告诉您正确的做法是正确的，要么（2）没有得到适当的指导。也不是你的错

成为一名程序员最重要的部分之一就是意识到，您从事的代码库必须可由许多不同的人维护。对客户而言，任何变数混乱或其他妨碍读取代码的事情都不是透明的，因为它需要更长的时间来解决难以阅读的代码中的问题。

如果您的团队有书面的编码指南，请遵循它们。如果没有，则您的语言应该有某种社区约定（对于.NET和C＃，Microsoft有许多公司都遵循的标准）。

询问您的团队负责人编码准则在哪里，以便您可以确保遵循它们。在您的会议中进行两次签到，其他两名开发人员未始终遵循准则，因此当他说没有任何内容时，您可以指出其他人似乎也有问题，每个人都将从中受益这些准则。

如果他公平地对待您，那么他会看到的，这应该在他要做的事情上。如果他不公平地对待您，那么您的弹药就会不断发生。

说“以后再说”是不好的。以后再也不会发生。花时间做正确的事。以后没有编程了。

当您是初级开发人员时，这很难。您感到执行压力很大，有很多人在看着您，您犯的每一个错误永远与您在源代码管理中的名字联系在一起。

在您的帖子中，没有任何地方提到周围的人如何受到对待。您不断重复说自己“感觉”到被“挑剔”，因为您是“女人”。

我认为无论您的性别如何，您都将被当作初级程序员对待，您应该为此感到感谢，因为这就是平等的意义。我还感觉到您正在对5分钟长的微小代码美感变化进行大惊小怪，现在要求您执行这些变化，而不是将它们放在待办事项列表中，并且从不进行处理。

在您的帖子中没有任何地方提到您被命令在周末做这些事情。在星期一早上检查一下修复可能是完全好的。

您的团队负责人可能对我的品味有些ped腐，但从您的职位来看，他或她的要求没有任何问题。

请停止播放性别卡。我觉得这是不体面的，并且破坏了两性平等的概念。

我不认为在此基础上拒绝我的分支是没有用的。周末有很多人在工作，我从未说过我会工作。实际上，有些人可能因为我没有时间进行更改并重新提交而被阻止。我们正在开发一个对时间非常敏感的项目，在我看来，完全基于对客户透明的事物完全拒绝代码是没有帮助的。我可能是错的，但似乎我有时间时应在补丁类型提交中处理这类事情。

很难说什么有用的东西，因为既没有看到您的代码也没有对您的项目进度有所了解。但是，他知道，如果您的主管表现负责任并且做得很好，那么其他人并没有真正受到阻碍，冲刺也不会迟到。所以，不用担心。也许您高估了对提交的影响。否则：如果您的项目是时间紧迫的并且通过了所有测试，那么它太挑剔了而无法拒绝代码，这些代码可以在发布后眨眼间修复。

使它工作使其正确使其快速

因此，如果您的领导者决定拒绝您的承诺，那么作为专业人士，他应该知道他在做什么。

现在，我可以看到在某些环境中这是正常的。但是，批评似乎分布不均，这导致了我的下一个问题。这些问题中大多数的基础是由于我处于别人编写的代码库中并且试图做到微创的事实。我在模仿文件中其他地方使用的变量名。当我这样说时，我直言不讳地告诉我：“不要模仿别人，做对的事。”

作为初级用户，很难找到进入公司代码库的方法。

最好：有文件化的编码标准-希望您能掌握这些标准。

通常：有没有证件编码标准-你必须通过学习试验和错误或者我应该说犯和_reject？这通常很痛苦（如您的情况）。就代码质量而言，这有时是危险的，并且可能导致崇高的风格编程，在这种编程中，不仅要模仿变量命名，而且要真诚地复制和粘贴代码库中的结构和模式，必须那样做。不要那样做！甚至不要模仿现有的变量命名。

坚持清洁守则。这是一种很好的做法，可让您轻松捍卫位置。如果它是可读，可测试和可维护的代码，则大多数情况下您都赢得了讨论。

这导致了另一个（最后一个）建议：遵循童子军规则！

始终保持比以前更好的状态。即使您正在使用的周围环境的代码令人讨厌，也请使其干净整洁-并且如果您有时间修复周围的环境。

花一点时间来了解同事个性的各种细微差别。以我的经验，如果您绕过同事的怪癖，您可以避免不合理，不必要，不一致或只是毫无价值的批评。

例如，某些同事可能在星期一宿醉。他们可能非常烦躁，并且过于渴望拒绝某些代码分支或提交。如果您必须与这样的人一起工作，请避免在星期一提交代码。

另一方面，宿醉的同事可能太生气了，无法关心错误消息的冗长...因此，星期一早上可能是提交代码的最佳时机:-p

办公室或工作场所中的个性怪癖无休止。希望您能学习避免和何时避免他们。也不要对自己太苛刻:-)您总是可以辞职并找到另一份工作！

我从来没有在不遵守某些约定的情况下拒绝代码的环境中工作。如果我不满意，我很想在一个我更有能力做出正确决定，并且客户是主要重点而不是代码的地方寻找工作。

我并不是说干净的代码和标准并不重要，但是客户和产品时间线应该不会因为非技术人员，客户或执行人员无法看到的拼写错误而遭受损失。

话虽如此，听起来您可能正在期望不明确的环境中工作，或者出于某种原因而没有完全理解需求。

无论情况如何，都应由您控制并提出明确的问题。积极主动（如果还没有的话）。您的团队成员和团队负责人在提出问题以澄清签入规则时可能会更尊重您。您还可以要求进行“事后审查”，在其中您和团队负责人讨论您应该做些什么以及如何做可以分辨出什么时候采取某些行动以及什么时候不采取某些行动。

我建议您花点时间，因为您是新手，请看看您是否可以克服任何障碍，并通过经验，沟通和学习标准来解决这些问题。但是，如果几个月后情况没有改变，并且环境仍然因模棱两可而困扰，那么也许是时候在另一家公司找工作了。

并非每个组织都如此严厉，您可能会发现其他工作环境更适合您的个性，风格和沟通要求。