如何处理实习生的不专业行为？

我不认为一笑置之不理是正确的做法。他们需要了解到他们已经不在学校了。

我建议你对他/她坚定一点，说些大意如下：

我们之所以要讨论命名规则，是因为它们非常重要。这段代码需要在以后的工作中可维护性。这里的很多人都是经过努力才走到今天这一步的，他们可能并不欣赏这种类型的笑话。请大家以后不要使用这类名字，因为这会让人质疑你的专业性。

首先，这似乎是一个笑话，他们很清楚地知道，这就像一个玩笑，被编入了代码，不会被用来做任何事情，也不会再被阅读。我认为你对这一事件的理解太深了。重要的是，你告诉了他们关于命名惯例，他们并没有忽视你，他们确实用了更长的、更有描述性的名称（尽管是讽刺性的）。自主性 2. 掌握 3. 目的性 你要求他们做的事情是不自主的，可能对他们中的一些人来说是微不足道的困难，在他们眼里没有任何目的性。我知道这看起来并不重要，但为了评估你的技能，并给你分配一些我们认为能帮助你成长的工作，我们需要你完成这个任务。

TL;DR*。我反对这个方法的名字，因为它（在我看来！）表达了对老板和/或 “规则"（这里是：风格指南）的不屑一顾。在职场上，我期望人们遵守 "爱它，改它，或者离开它 "的规则。在这种情况下，这位实习生似乎认为这个准则是没有必要的，他要么就是无论如何也要接受这个准则；要么就是继续讨论这个准则；要么就是停下脚步去做他所做的事情。而不是放进相当于在马桶上涂抹一些污点。如果是真正有趣的、有创意的方法名，我是完全不反对的。如果你（OP）觉得这个法名只是有趣，而不是像我一样觉得 "不好"，那就请忽略这个答案吧_

作为一个背景，我过去指导过几个高智商、（自我）上进的实习生，从来没有一次会不会专业的问题。作为实习生，把学校里的傻子带到工作场所来_作为一个实习生，这已经超出了可以接受的范围，所以我建议大家不要乱来。为了自己，尤其是为了他们的利益，

我想知道如何正确处理这种情况

首先，忘了编码习惯。这个问题和计算机、编程无关

—-不要说假话。不要拐弯抹角，不要一笑置之，因为这真的不是笑谈。 –不要针对个人。这不是关于你_OP，也不是关于你和他们的关系。 - 解释一下事情的原委。你绝对可以告诉罪犯，你可以告诉他，你有点明白他怎么会有这样的想法，而且你个人并没有对他发火或其他什么的（保持情绪化），而是把这次实习看作是对谁的一次筛选，以后要带谁上岗。

不过，他们在实习期间的表现会影响到他们被录用的机会，像这样的情况也会对以后的工作起到一定的作用。别再拿 "以后能起作用 "来忽悠了。像这样的行为，可以、应该、也会让他们在实习后收到offer的机会为零。你可以用你平时用什么方式和他们说话，平白无故地说，

试着去找根源。如果你发现要么…..

-…他们在这里违背了他们的自由意志（也许是他们的父母，或者学校或者其他什么的，让他们选择了一些实习岗位，而他们恰好选择了你的公司）…

-…他们对 "商业 "式的软件开发根本不感兴趣…

…那么提出中止实习也不是你能做的最坏的事情。问题不是你的时间被浪费了（你已经分配了大量的时间来监督他们，他们并没有让你的工作变得更糟），问题是他们的时间被浪费了。

或者我应该告诉他们一些这样的事情，让他们更有动力去学习一些东西？

我会说 "每个人都可以学习，但没有人可以被教。” 我想你会发现你很难激励那个人去学习编码约定的有用性，因为他们已经证明他们对这些东西没有兴趣。你可以教那些对你所讲的东西感兴趣的人；但如果有人不感兴趣，你就无能为力，真的。实习是用自己能提供的有限的服务，与实际工作场所的工作经验做对比，是一种交换。如果他们对同化经验不感兴趣，那么真的没有任何意义。大概，你的公司并不依赖有他们的 “人力 "去做一些真正的项目。

我们都不喜欢这样做，但有时候你只需要用权威来解决问题。把实习生叫来开会，要求知道为什么不遵守命名规范

我在之前的会议上就交代过命名规范要遵守的问题。我遇到了一些没有遵守命名惯例的情况。比如说，convertToMillilitersBecauseIAmUsingSuchCleanCode。能否请你解释一下为什么选择了这个名字？

他们的 “回答 "无关紧要，这应该足以作为一个 "第一次警告"，即违背上司的指示（我猜你是），在职业环境中，违背上司的指示，开他的玩笑，是不能接受的。这甚至很符合实习生的一个目的，那就是让学生们知道如何在专业环境中工作。

如果他们继续这样幼稚的行为，那么好吧，我想你已经得出了这样的结论：

有些实习生将来会根据自己的表现被公司录用。

哦，一帮子的螺丝钉，是吗？

拿一些工作代码，做一些故意破坏它的事情。然后通过一个混淆器，把所有的类、变量和方法名都改成 “a_\_1318798_"和 "xy23\7a963"；或者更糟糕的是，变量名中的字母O、字母I、数字0和数字1等字符。让他们的任务是记录下代码是怎么做的，并将其修复。

这样就能治好那句玩笑话。

我知道这可能不是什么大事，但我是第一次帮助实习生，我想知道如何正确处理这种情况。但是，他们在实习期间的表现还是会影响到他们被录用的机会，像这样的情况在以后会起到一定的作用。或者我应该跟他们说些这样的话，让他们更有动力去真正的学习一些东西？

当你在代码审核过程中遇到这种傻事的时候，先笑一笑，停止代码审核，然后告诉他们去掉幽默的地方后再来，我想他们也不傻，已经知道这个过长的名字不合适，就算是让他们笑出声来也是可以的。如果不是，那就解释一下为什么

希望你一直在跟踪他们的表现，能注意到这种情况发生的频率。

我会在私下里，用一种坦诚、严肃但不严厉的语气，和他们每个人谈心，类似于这样的事情：

“实习生，我看到你的笑话法名。我明白你为什么要这么做，但我自己也不觉得有多好笑。所以我突然想到了问你，你来这里做什么？你想达到什么目的？”

如果实习生说他只是在那里瞎折腾，那就跟管理层说，结束他的实习期。你这是在浪费你的时间。"

如果他说他是在那里学习，那就说这样的话：

“我意识到，你知道不会在生产中使用的东西，你可能很难认真对待。但请你意识到，你不仅是在花你的时间，也在花我的时间。公司给你提供的实习机会，实质上就是一种面试。唯一阻挡我们的是希望能找到好的人选，而不是纯粹的施舍。所以，这值得我花时间，但前提是你要认真对待。”

“如果你不能认真对待，像写重要的生产代码一样工作，我们怎么能正确评价你，决定是否给你提供工作？而且，即使我们不给你提供工作，如果你还是不认真对待，那你还怎么能掌握这些技能，还能在比你有更多经验的人的宝贵指导下练习呢？”

“如果我是你，我会尽我所能地跟着指导你的人，他们在某种程度上是在慈善地抽出无偿的时间来投资你。考虑到无论我们是否录用你，你都会从这次实习中受益! 如果你能认真一点，我个人会很感激你。你自己去做吧! 如果你不想为自己做，那就出于尊重，或者仅仅是出于感激，我从正常的生产性工作中抽出时间来投资于你和你的未来。”

大概应该有点直接针对行为本身，以及为什么要把这件事搞得有点大惊小怪的原因。你可以考虑这样说：

“说白了，这种行为在企业界被认为是不尊重，甚至是嘲讽。我相信你并不是那个意思[即使你不相信，也要说出来]，但请你以后只管按照我的指示去做，不要在代码里放些尖酸刻薄的东西。”

给实习生的 “出局 "说 "哦，是的，我没有不尊重的意思"，让他挽回面子，用最不痛不痒的方式修复关系。没有必要提取一个承认他确实是不尊重的意思，也没有必要为了获得一些巨大的道歉。这里的关键不在于权力至上，而在于成功的实习。

如果在这一切之后，负面的行为还在继续，你可以更正面的处理。你没有理由不给实习生一个绩效目标，就像你对问题员工一样，或者使用其他任何你对普通员工使用的策略。但要记住，实习生在工作中并没有经验，应该给他们一两个休息时间，而你要温和而坚定地让他们适应专业工作的标准。

涉事的实习生是在浪费你的时间和耐心。你的时间和耐心对于公司和实习生来说是昂贵而有限的资源，而公司对他们的投资是有限的，这种投资受制于公司的资源，

他们愿意无谓地浪费公司的资源，这也是公司对他们的绩效考核的相关内容，可能会导致他们提前终止实习，只把公司的资源花在那些真正有兴趣学习的实习生身上，让他们成为有价值、有责任心、可靠的职场中的一员，既能接受任务又能接受指导的实习生。

我会告诉所有的实习生，展示一些例子代码，不提它的作者，不要花超过2分钟的时间在上面，如果这个代码后来被修复了，而且类似的事件不会再发生，就不要再提。然后，你需要决定你是否欠其他实习生一个人的人情，把那个破坏他们成功实习的机会的人赶走。

这听起来有两个主要问题。1)他们是不敬业；2)虽然现在长了，但这个功能的名字还是很烂。

斥责他们开玩笑，可能不会让他们更尊重你的权威，所以我会把重点放在这个问题上，就像其他任何一个名字不好的功能一样。我不一定会装傻，装作不知道这是一个玩笑，但我会质疑他们为什么选择了这样的名字：

“这个函数名称中似乎有一些多余的词，无法解释这个函数的作用。”

这样，对他们来说，这是一个学习的机会，让他们知道什么是一个好的函数名称，而你并没有直接与他们对抗。作为一个额外的奖励，他们可能会承认他们只是在胡闹，并可能会因为浪费了大家的时间而感到羞愧。

如果你必须提醒别人说你是负责人，那么你从来就不是负责人，

最好是进行一次代码演练，让开发人员向有权力的人解释他们的代码。这样可以灌输个人对项目结果的责任感 2. 提供即时的专业反馈 3. 让开发人员有完成项目的紧迫感

4.发挥你的领导力，作为团队中的一员，维护组织的标准。然后，帮助年轻的员工达到这些标准，避免呈现出不合格的作品的尴尬。

只要告诉违规者（亲自或通过邮件），实习生几乎不适合开这样的玩笑，如果他们想出人头地，就必须认真对待。

要求他们修复代码，或者（如果你想表现出一些权威性的话）直接回滚他们在版本控制中的修改。

很明显，你需要让他们停止，但仅仅告诉他们停止可能并不能说明原因。

我知道每行80个字符的准则并不是一个硬性规定，但坚持遵守它是一个很好的做法，所以有一个48个字符的变量名是非常愚蠢的。有点像 “你已经铺好了床，现在躺在床上 "的感觉。

你会尝试着把新的做法锤炼到他们的脑海里（假设他们还没有把行写得很短），那些不明白为什么长变量名不好的实习生们会发现，而那些 "聪明的 "实习生很快就会发现他们并不像他们想象的那么聪明。

对于更有经验的代码员来说，为什么convertToMillilitersBecauseIAmUsingSuchCleanCode特别不好，这一点是显而易见的，但与其告诉他们 "那是不好的"，不如强迫他们找出原因。我敢打赌，你会遇到更少的人骂人，如果运气好的话，以后也不会再有那么多的人试图用尖酸刻薄的方式来搪塞你。

这不一定是 “One Size Fits All"。 All Sizes Fit Some:

每一种建议的方法都可以有很好的效果，而且可能是最好的方法，视情况而定。下面是我对每一个被问到的方法的反应：

我的反应应该是

–一笑置之（"是的，这很有趣，但请把它删除"）

这是个很好的主意，当。你和这些同事关系很好，已经成为好朋友的

–只是礼貌地要求删掉它

这是个很好的主意，当。你想直接说出来，这样就不会有误解

–告诉别人我不喜欢别人浪费我的时间，他们应该更认真地对待代码审核

这是个好主意，当。你希望传达出恼人的意思，并坚持一种专制的方式。

（我倾向于认为你也许可以把所有这些方式结合成一种非攻击性的、有礼貌的、有趣的方式，确实传达出有一点实际的恼人。"这种事情必须停止，因为它只是让我去[[嘲讽]"可能是一种幽默的方式来完成。我信奉这种做事的方式。然而，我愿意承认，有时这种方法的效果并不那么好。

**但什么是最好的？"我需要去一个地方，我应该用独轮车吗？我应该使用独轮车，pogostick，自行车，还是公交车？”

任何一种交通方式都可能是最好的。同理，回答 “你应该如何应对 "的问题：你的最佳反应可能不是我的最佳反应。

这也是一个关键的原因，尽管不同的答案似乎都认同实习生的行为不适合生产结果，但不同的答案似乎偏向于不同的方法。如前所述，我们可能没有一个 "一刀切 "的方法，对每个人来说都可能是普遍适用的。

我们在这里面对的是人，所以在某些情况下最有效的方法在其他情况下可能并不那么有效。其中一个关键因素就是你。你能在不烧毁桥梁的情况下保持严厉的态度吗？你是否能通过轻松愉快的方式与他们交朋友，但又能确保有足够的服从性和激励性，以达到预期的效果？对我来说，最适合我的东西可能对你来说是非常可怕的。最终，你需要对这些方法中的哪种方法做出判断。

灵活的教学：*不要只承诺采用一种方法。确保你不要做得太过火了（坏的/冒犯性的幽默，或者为了严格而创造一个令人不舒服的威胁性环境）。只要你没有造成什么大的问题，只要积极、迅速地处理好，这可能是非常可以挽回的。这也是为什么你不应该太过担心试图做出最完美的决定的原因之一。如果事情进展不顺利，你的情况也会很顺利。人是不同的，学习也是不可预知的，第一次的做法需要修改，也不必感到羞愧。只要你恢复得快，这都不是问题。

关键是，一旦开始发现不理想的结果，就要马上做出改变。期待需要****快速适应。当某些方法不奏效时，要做好快速修改方法的准备，甚至完全将其抛出窗外。如果你正在做的事情不奏效，那就确定你是否有可能在突破的边缘，或者你是否需要尝试不同的方法。(获得反馈将有助于这个判断。)如果你需要尝试其他的东西，那就去做。

只要你迅速行动起来（在长期的感觉如苦涩的感觉开始出现之前），小的不完美很容易被忽略，因为相对于你所取得的积极成果而言，小的不完美很容易被忽略。只要确保如果事情不完美，问题是小问题就可以了）。而重大的搞砸了的事情可能就更难忘记了。比如说，企图的幽默可能是危险的）

比如说，如果你发现他们开始讨厌你，畏惧环境等，一定要澄清任何误解。向他们保证你是站在他们这边的。鼓励他们的行为。

两年前，我和你们公司的实习生的情况类似。我可以想象出我也会做类似的事情的情景。我觉得有些实习生对你的权威有问题，迂腐，不专业。这主要是由于我们这一代人对长辈和高位者缺乏尊重。我会尝试以下方法来解决这种情况。

—-通过出言不逊于 “领导"、"阿尔法 "来赢得实习生的尊重。

–用迂腐的函数名作为教训给大家，最佳函数名长短：金锁区。

–指出 "convertToMillilitersBecauseIAmUsingSuchCleanCode "函数的缺陷，建议重命名为合适的东西(/demeaning)

–不注意，忽略函数名；把时间集中在想学的人身上。

我的反应应该是

–一笑置之（"是的，这很有趣，但请删除它"） –只是礼貌地要求删除 –告诉别人我不喜欢有人浪费我的时间，他们应该更认真地审查代码

怎么样？ **“

每当有人做了你不期望或不希望他们做的事情时，你可以对其做出反应，以便让他们做你希望他们做的事情，或者你可以试着去了解他们为什么要这么做，

或许了解原因会有帮助。如果他们天性爱玩，但却没有机会宣泄他们对某件事情的不满，这就是有人可以疏导的方式。我们都可以同意，这不是一种积极的疏导方式。

***另辟蹊径

那么，什么是_是积极的疏导挫折感和俏皮的方式呢？我曾在公司工作过，在那里，人们有时会在10%的时间里做项目，比如用单片机编程，用数码相机自拍。他们不仅得到了自由支配权，还被赋予了将其变成可出货产品的责任。它从一个为期一天的黑客马拉松变成了现在公司网站上发布的代码示例。人们可以把这个例子变成一个深海相机的遥控器，只需按一下按钮就能打开。

我的观点是，像这样的恶作剧可以是未被开发的潜力的标志。如果你想要的实习生符合你公司的标准，这种潜力不适合你，在这种情况下，可以考虑让他们离开。然而，如果你看到了颠覆性的价值，让这些恶作剧者用他们的恶作剧创造出一些有用的东西。最终，这是由你自己决定的。**你想让这些实习生成为谁？

然而，作为一个专业的软件开发者近30年了，我想说的是，编码指南几乎总是过规定性。更糟糕的是，这往往被一些人抓住了，他们更关心自己的权威性，而不是产生可读的代码。这种初级工程师的被动攻击行为，正是你通常看到的情况。

在代码注释中放一些愚蠢的东西，甚至是标识符命名，这在软件开发人员中确实是一个历史悠久的传统。这里有一个由标准引起的抗议命名的例子，来自我自己的大三时代（得到了48个投票）。

如果这里有一个问题，那应该是他们的源代码在你的环境中存在着合法的可读性/可维护性问题。我不是说这里的顶级答案是错的。他们并没有错。但是，当你看到多个初级工程师的这种行为，那么在清理尸体之后，你真的应该研究一下，是否可能有一个潜在的原因导致你的金丝雀不断死亡的。

最终的目标需要是代码质量。编码指南应该只是帮助他们达到这个目标的工具，由开发人员为开发人员建立的，而不是一些关于如何编写程序的专制程序。

听起来，你有一个很好的例子向他们展示了为什么使用这种类型的编码习惯是不合适的，即使是这样的小项目也是不合适的。

我不会对他们太苛刻–毕竟，这对他们来说只是一个试用期–但我肯定会指出，在未来，这样的编码做法可能会给他们带来麻烦，尤其是如果他们的下一个老板不像你这样耐心地对待他们。

首先，我认为这并不_坏。他们在代码中放了一个关于主题（名称约定）的笑话，可能他们并没有完全掌握。在代码中放置一些内部笑话并不是什么新鲜事。另外，他们可能会认为这个代码是 “内部表"。

我也不同意他们这样做是在浪费你的时间的观点。如果他们做了一个提交只是为了重命名一个方法，那么是的，他们是在浪费你的时间，这个改动应该被拒绝。但如果他们需要一个新的方法，并且选择了一个可怜的名字，那么不管是哪一个名字，审查的时间都差不多。我不知道你是在审核前审核还是在审核后审核，但是当有人想让代码被批准/合并时，他们所做的事情实际上是对自己不利的，因为他们只是在为实际让代码被接受而增加了往返的时间。

对于你来说，用错误的名字来进行负面评价也是微不足道的，而没有真正看清代码的作用。

现在，钉钉到实际的问题上，我建议提出他们在名字约定上有一些问题，让他们回顾一下上周的工作，看他们是否用了正确的名字，想想几年后/如果是新来的那个项目，他们是否容易理解。让他们准备一份关于他们在那周添加的函数的简短报告，并在短时间内说明理由。

理想的情况是，每个函数大概要有一行，例如：

convertGalToml: 将加仑换算成毫升。

我估计在审阅代码的时候，他们可能会注意到新的问题，或者想出一个更好的名字，比如把convertGalToml重命名为convertGal2ml。虽然比起用户手册，它是一个技术性更强的受众，但在同行面前，他们应该会很自如地证明自己的选择。

从善意的假设开始，我的直觉告诉我，实习生这么做是因为他们真的看不出convert这样的名字有什么问题。我敢打赌，我敢打赌，这些被讽刺的名字并不是因为他们想反叛，而是因为他们不知道如何想出一个更好的名字，只是一个长的**名字。你也是这么跟他们说的吧? 短的不好，长的好。

如果你想让这些人进步，你只需要在日常的会议上，讨论一下，具体为什么convert是个不好的名字，而convertInchesToCentimeters是个更好的名字。如果你有一个例子，从你的经验来看，选择不好的名字会造成问题，这将会对他们有所帮助。这个 “为什么 "会让他们从现在开始选择好的名字–不管这些好名字是长的还是短的。

还要让他们知道，在合理的范围内向你或他们的同伴寻求帮助或咨询也是可以的，这不是一个测试，每个人都要单独行动，这是一个合作的过程。我希望这句话是真的！），也许这样可以让他们多问问题，多交流，尽早解决挫折，而不是等着在代码评审中出现这样被动的东西，才会让他们有机会去做。

只有当这种行为持续下去的时候，我才会觉得有必要解释一下，是的，这不是一个真正的应用，但这个练习和风格指南应该被认真对待，原因有很多。

• 在我可以去做 "真正的 "申请的时候，花在你们身上的时间是值得的，所以请你们尽最大的努力。在这一点上，很可能会使他们的行为沉默，但也不会帮助他们理解_为什么他们需要更好的名字或如何想出更好的名字。如果你走这条路，你可能会发现他们只是想出一些比较长的坏名字，并避开你严厉的目光。

你不是他们的经理，甚至你面试不面试都无所谓。你和我一样是个工程师，

所以你知道该怎么做，和你的经理谈谈，然后建议他们进行代码审查。然后建议他们不要通过代码协作器这样的系统来写这样的代码。你甚至不需要给他们发邮件，也不需要和他们互动，更不需要把这些东西放在心上。根据那个代码-review引入一个评分系统。不要试图控制他们，或者做他们的管理者，或者试图进行人员管理。这不关你的事。

和你的经理商量一下，把审查后拒绝或批准提交的权限留给自己。假设每个实习生最初都有10分，他/她应该通过你的打分，通过你的打分，他/她应该得到100分，如果他们真的想加入你的团队，就会有动力去打分。

如果我是实习生，而我在你的手下工作，而你只是一个高级工程师，即使我讨厌你做我的人事管理，这不是你的工作。这不是你的工作，

在我听来，你做得太过分了，已经失控了。作为一个工程师，要吸取这个教训。你是一个工程师，不是他们的经理人管理他们。

虽然实习生的行为可能是不专业的，但管理层不考虑他们可能是错误的，这也是不专业的。显然，convert在很多语境下可能太过简短的模棱两可，但convertGallonsToMilliliters对于一个标识符的命名来说_太长了。与其一刀切地强加任意的命名动词要求，你应该挑战你的实习生，让他们证明他们选择的名字真的很暧昧（他们不可能做到），并想出一些合理的东西来提高程序的可读性，而不是阻碍它。

这在我看来真的是一个常见的 “为什么我的下属不尊重我？"的案例，其实就是 "我自己的态度让人不尊重我的立场？”