如何处理初级开发人员的“差不多好”的代码？[关闭]

我有一个有关团队管理的问题。现在，我正在与一个初级开发人员打交道，该人员正在编码工厂远程工作。这个家伙很容易受到批评并且乐于学习，但是我有些怀疑我应该投入多少。

现在，当某些事情变得直截了当且显而易见时，就会违反良好做法：例如违反SRP，上帝反对，方法或变量的无意义名称；我指出他必须解决的问题，并尝试解释为什么这是错误的。

我的问题是：何时停止？现在，如果存在一些轻微的违反编码风格的行为，例如变量名使用了错误的语言（以前的团队使用西班牙语和英语混合，并且我试图解决该问题），或者如果我遇到一些结构性的小问题，我可以放手进行修复，如果我有任何空闲时间或碰巧需要修改有问题的课程。我觉得这对团队士气是有好处的，所以我不会不断地向初学者介绍代码，这些细节看起来像是很小的细节，这可能会令人沮丧，但是我也担心过于“软化”会阻止这个家伙从学习如何做一些事情。

我如何在教这个人与不因不断批评而把他烧光之间平衡？对于一个大三学生来说，如果您告诉他重做一些他眼中正在工作的东西，那可能会令人沮丧。

如果您认为在合并之前应固定代码，请进行注释。最好加上“为什么”，以便开发人员可以学习。

请记住，代码阅读的频率远高于书面代码。因此看起来“次要”的事情实际上可能真的很重要（例如，变量名）。

但是，如果您发现自己的评论看起来很乏味，则可以考虑：

• 您的CI流程是否应该抓住这些？
• 您是否有清晰的“开发人员指南”可供参考（或者所有记录在您的脑海中）？
• 这些注释实际上有助于代码质量吗？

许多人在过程或完美的祭坛上牺牲了生产力。注意不要这样做。

如果可能，请尝试亲自拜访您的同事。或使用视频通话。建立关系会使批评（甚至代码审查）更易于管理。

如果发现一段代码在问题上来回过多，请请求对较小的一段代码进行检查。渐进式更改更可能避免一些更重要的设计问题，因为从定义上讲，它们较小。

但万万没有合并的东西，然后回去，并修复它。这是消极的进取心，如果开发人员发现您这样做，您将扼杀他们的士气。

保留对代码的批评而不是对代码的批评。

任何作品都带有内在的情感依恋。考虑通过尽可能取消编写者的代码关联来缓解这种情况。准则的质量应始终作为双方共同面对的共同目标，而不是彼此之间的摩擦点。

实现这一目标的一种方法是明智地选择您的语言。尽管STEM个人喜欢将自己视为高度逻辑，但情感是人性的一部分。所用的修饰语可能是伤害或幸免的感觉之间的差异。说“如果此函数名使用英语，则该函数名将与约定更加一致”，胜于“您输入的此函数名错误，应使用英语”。尽管后者仍然很温和，而且单独看起来还不错，但是与前者相比，它的缺点变得很明显-当准备亲自或电子邮件说什么时，请检查您的上下文，文字和重点是否是问题所在，而不是问题所在这个人。

身体语言

虽然单词很重要，但大多数交流都是非语言的。注意肢体语言，甚至看似微不足道的细微变化，例如定向混乱，例如许多高级与初中的互动都是面对面发生的，但是并排使用的方法会更有利于您期望的结果。

提供诚实正面的反馈

大量研究表明，当我们奖励良好的行为而不是惩罚不良的行为时，可以更快地学习信息并更好地保留信息。有时只是注意到通过简单的“好工作”或更具体的表现已经提高了性能，“我最近注意到您的风格已经将我们的标准与三通，出色的工作相匹配！” 甚至通过让他们补充这种对改进的认识，反过来就修改过的问题向他人提出建议，也可以对您的初级开发人员和他的工作有所帮助。

这个家伙很容易受到批评并且乐于学习，但是我有些怀疑我应该投入多少。

尽力而为。如果这个人正在学习，并且查看他的代码是您的工作，那么，如果他做得很好，那么你们俩都有很多收获。

这将意味着更少的代码供您将来审核，并有可能给您的团队一个招聘目标。

另外，如果您退缩，您将无济于事，而是光顾。

仅仅因为您在此处发布问题，询问您是否做得太多，就已经向我表明您不需要此特定建议，但是对于其他人而言，这就是事实：只要记住努力就并不意味着混蛋

成为一名导师并非易事。您还必须给他一些空间，让他犯一些错误并自己纠正，只要确保他会在不会造成实际损害的地方这样做即可。

根据您的描述，我将其保留为：“这很好。我会做一些不同的事情，但它们并不是很重要。”

如您所知，批评是有代价的，如果您花费大量时间讨论细节，这将成为士气问题。理想情况下，将自动检查所有编码标准，除非您遵循它们，否则您将无法进行构建。这可以节省大量时间，并让您开始工作。如果您对“重要的事情”保留批评，您的建议将产生更大的影响，并且您将被视为重要的导师。区分不好的事情和不完全正确的事情是非常关键的。

我相信“ 教学时刻”的概念。如果开发人员具有足够的思维能力，他可能会要求您提供有关您将采取的其他措施的详细信息。（S）他可能没有，没关系。人们会精疲力尽，并且在职业生涯的早期，可能会花费大量的精力来完成以后看起来很简单的事情。

我会考虑在他的工作可以接受而不是完美时接受他的工作。然后，下一个任务是在讨论之后，通过进行所有想要的小而重要的更改来立即重构它。

因此，当工作被首次接受时，您的信息是，它还不错，并且有些地方会接受它足够好-但是您不想成为初级开发人员并希望正确学习其交易的地方。

因此，您不要说“我拒绝您的工作，因为它不够好”。您说（a）“我接受您的工作，因为它足够好”，然后说（b）“但是我希望它更好”。

悬而未决的问题，但是这里有一些想法。

1. 同行评论（由初级开发人员提供）

   某人学习“正确”方法的最好方法是让别人去做。您所有的开发人员都执行代码审查吗？让您的初级开发人员也执行它们可能不是一个坏主意（尽管您也应该至少要求高级开发人员进行一次审核）。这样，他将看到优秀的编码器在起作用，此外，他还将观察到针对他本人以外的工程师的评论意见，这意味着它不是个人的。

2. 早期反馈/任务审查

   允许开发人员参与自己的任务分解。让他在任务记录中记录其预期的设计，然后提交“代码复审”，其中没有变更集，而只是任务。这样，您可以在他编写单行代码之前查看他的计划。一旦检查了他的任务，他就可以开始编码（此后，他将提交另一个编码检查）。这避免了开发人员写了很多东西而您必须告诉他重写它的令人沮丧的情况。

如果代码客观上违反了书面的，明确的标准，那么我认为您应该继续努力直到解决所有问题为止。当然，对于开发人员来说，前几次提交可能会有些烦人，但他们最好还是比后来者更早地了解准则。

另外，如果您允许在这里和那里几次违反标准，那么它们将树立一个不好的先例-参见破窗理论。而且，如果已经一致地将其应用于代码库，则记住遵循标准会容易得多。所以说真的，每个人都赢了，包括有问题的初级开发人员。

只要写下编码标准，我认为士气不是大问题。只有当它进入更加主观的“嗯，我本来会做得不同”的领域时，才应该担心，因为开发人员的方法可能同样有效。

考虑采用代码审查工作流程，开发人员在该工作流程中将其提议的提交发布到Github Pull Requests或Phabricator Diffusion之类的工具上，并在将其更改登陆到共享master分支之前获得同级签核。

通过这种方式，而不是事后批评或问别人要重做什么已经完成，工作只是还没有完成，直到它通过同行评审。与同级之间的来回交互与编译器之间的来回交互一样，是软件工程过程的一部分。

您可以将您的疑虑作为评论发表在特定的行上，并进行有针对性的讨论。他可以对您的代码执行相同的操作。讨论始终集中在特定的拟议代码更改上，而不是某个人的总体性能或能力。

当代码审查发现拼写错误或迫使他们弄清楚事情时，即使是我公司的出色高级工程师也很感激。对于新员工来说，需要更多轮迭代是完全正常的。随着时间的流逝，您开始反思地解决已知的问题，然后再发布差异。第一次尝试接受更高比例的差异是您知道自己正在改进的方式。

我不是在不断地向新手介绍代码，这些细节看起来像是很小的细节，这可能会令人沮丧，但是我也担心太“软”会阻止他学习如何做某些事情。

这些既是现实的可能性，也是有效的关切。询问开发人员对此的感觉。

假设您有一些请求请求或代码审查工作流，并且看来您这样做了，那么我建议您注意“非关键”或“优先”的事情。

如果您看到的PR与所描述的状态相似，但存在一些较小的样式问题或需要进行非关键性的重构，请发表评论，但也可以随时批准。这样说，“将来，也许避免使用类似descriptiveMethodName之类的方法名”会记录您的意见，而不会强迫他们进行更改或阻止其发展。

现在他们知道您的喜好，并且如果他们正在尝试改进，希望将来会注意到这种情况。如果他们同意您的意见并认为它足够关键，那么这也给他们敞开了大门，让他们在那个时候实际改变它。

我正在与一个初级开发人员打交道，他们正在编码工厂远程工作。

不幸的是，这不是一个理想的情况：一个高级程序员负责一个新手程序员，并且地理上有隔separation。出现某种紧张并不奇怪，但是这种差距可以缓解。

我很好奇，“编码工厂”是什么意思？对我而言，该术语表示一种令人不安的态度，这可能会加剧您提到的某些管理问题。

…违反SRP，上帝对象，方法或变量的无意义名称；我指出他必须解决的问题，并尝试解释为什么这是错误的。

我认为问题是，您的初级开发人员在没有经过适当设计过程的情况下正在喷洒代码。作为经理和高级开发人员，这对于您提供指导和教导良好的软件开发习惯来说是失败的。如果您首先一起绘制轮廓，则可以防止一开始就编写不好的代码。就效率和士气而言，这比在代码生成后批评和重写代码更为可取。

您可能需要重新调整工作流程。听起来您目前正在期望他为您提供产品。您需要的是更紧密的协作，以便您可以在开发的每个步骤中提供指导。在开始编码之前，先讨论一下设计和接口。进行编码时，请执行更频繁的检查点，以尽早发现问题。如果可能，尝试通过屏幕共享和音频通道进行配对编程。

所有这些都将需要您付出更多的努力，但是考虑到当前存在的问题关系，这可能是值得的。

如果违反编码标准，请告诉他/她在哪里，以便他/她知道。如果您必须继续向他/她显示相同的错误，那么您可能会遇到一个不遵守规则或拒绝的人。不要用业余时间来纠正错误。此人应该纠正自己的错误，以免再次犯错。

始终告诉他们他们做对了什么，以及下一次如何改进。我们总是可以在某些方面变得更好。反馈对于改善任何方面都至关重要。

处理“太多批评”的另一个想法是不时自己做一个任务，然后让初级开发人员为您进行代码审查。这至少具有两个优点：

• 他们可以学习应该如何做。
• 在有多个好的解决方案或变量名称的情况下，我接受不同但（几乎是）同样好的方法的建议。当我由于某人的评论而修改我的代码时，我在向人们表明他们受到尊重，而批评总是只涉及代码-无论作者是谁。