我对团队管理有疑问。现在，我正在与一个初级开发人员打交道，该人员正在编码工厂远程工作。这个家伙很容易受到批评并且愿意学习，但是我有些怀疑我应该推些什么。
现在，当某些事情变得直截了当并且明显违反了良好做法时：例如违反SRP ，上帝反对方法或变量的无意义名称；我指出他必须解决的问题，并尝试解释为什么这是错误的。
我的问题是：我什么时候停止？现在，如果存在一些轻微的违反编码风格的行为，例如变量名使用了错误的语言（以前的团队使用西班牙语和英语混合，并且我正在尝试解决该问题），或者如果我遇到一些结构性的小问题，请放手进行修复，如果我有任何空闲时间或碰巧需要修改有问题的课程。我觉得这对团队士气是有好处的，所以我不会不断向新手推送代码，这些细节看起来像是很小的细节，这可能会令人沮丧，但是我也担心过于“软化”会阻止这个家伙通过学习如何做一些事情。
我如何在教导这个人与不因不断的批评而把他烧光之间平衡？对于初中生来说，如果您告诉他重做一些在他眼中正在工作的东西，可能会感到沮丧。
#1 楼
如果您认为在合并之前应固定代码，请进行注释。最好使用“为什么”（Why），以便开发人员可以学习。请记住，代码的阅读频率远高于编写的代码。因此看似“次要”的事情实际上可能真的很重要（例如，可变名称）。
但是，如果您发现自己的评论看起来很乏味，则可以考虑：
您的CI流程应该抓住这些吗？
您是否有清晰的“开发人员指南”供参考（或者所有记录在您的脑海中）？
这些注释是否确实有助于代码质量？
许多人在过程或完美的祭坛上牺牲了生产力。请当心，不要这样做。
如果可能的话，尝试亲自去拜访您的同事。或使用视频通话。建立关系可以使批评（甚至是代码审查）更易于管理。
如果发现一段代码在问题上来回过多，请请求对较小的代码进行审查。增量更改更可能避免一些更重要的设计问题，因为从定义上讲，它们较小。
但是绝对不要合并内容，然后回去对其进行修复。这是消极的积极进取，如果开发人员发现您这样做，则会扼杀他们的士气。
评论
@ 9000令人惊讶的是，当人们甚至没有在任何地方记录这些标准时，人们常常对那些没有按照其标准做出贡献的人感到沮丧...
– enderland
17年6月6日在16:24
变量名对于描述代码的意图非常重要。方法/函数名称，甚至更多。正确命名名称并不是无用的完美主义，它是可维护性所必需的。
– 9000
17年6月6日在16:24
@Zalomon一定要跟他提；更多，将其变成讨论。作为初级开发人员，我曾与一些不同的高级开发人员一起工作。我最好的经历是与一位开发人员进行了交谈，他与我讨论了他的所有建议，甚至是“小”建议，例如变量的名称稍好。我不仅从他那里学到很多东西，而且感觉非常好，以至于他在听我的思想过程并将我包括在讨论中-这使我希望他更多地检查我的代码，以便我可以学习更多。 （继续）
– dj18
17年6月6日在16:44
@Zalomon（续）另一方面，一位资深开发人员在我背后进行了更改（即使您之后告诉他，它仍然在他的背后），这令人沮丧，这使我感到自己好像在与一个独裁者共事。必须找出如何取悦。
– dj18
17年6月6日在16:44
我指导初级开发人员的（小）经验表明，让开发人员认真思考专有名称并在变量名称中表达数据的目的是值得的。它可以帮助开发人员以比过去更少的手工方式真正了解他们的代码在做什么。有时，这会导致他们在所涉及的代码中发现逻辑错误，或者只是表达事物的更好方法。 （同样的事情对我有用；不同之处在于，由于我过去有严格的代码审查员，我的学科已经内部化了。）
– 9000
17年6月6日在16:49
#2 楼
保留对代码的批评而不是对编写者的批评。任何作品都带有内在的情感依恋。考虑通过尽可能多地取消与编写者的代码关联来缓解这种情况。始终将代码质量确立为双方共同面对的共同目标，而不是彼此之间的摩擦点。
实现此目标的一种方法是明智地选择您的语言。尽管STEM个人喜欢将自己视为高度逻辑，但情感是人性的一部分。所用的修饰语可能是伤害或幸免的感觉之间的差异。说“如果此函数名使用英语，则该函数名将与约定更加一致”，胜于“您输入的此函数名错误，应该使用英语”。尽管后者仍然很温和，而且单独看起来还不错，但是与前者相比，它的缺点变得很明显-当准备亲自或电子邮件说什么时，请检查您的上下文，文字和重点是否在问题上，而不是问题所在该人。
肢体语言
虽然单词很重要，但大多数交流都是非语言的。注意肢体语言，甚至看似微不足道的微妙姿势，例如方向混乱。许多高级与初中的互动都是面对面发生的，但是并排的方法会更有利于您期望的结果。当我们奖励良好的行为而不是惩罚不良的行为时，可以更快地学习并保持更好的状态。有时只是注意到通过简单的“好工作”或更具体的表现已经提高了性能，“我最近注意到您的风格已经将我们的标准与三通，出色的工作相匹配！”甚至通过让他们补充这种对改进的认识，反过来就改进的问题向其他人提供建议，也可以对您的初级开发人员和他的工作有所帮助。
评论
关于转折点：根据我在代码审查两边的经验，当您必须使用人称代词时，仅选择“我们”而不是“您”也可以取消批评。
–jscs
17年7月7日在13:15
#3 楼
根据您的描述，我将其保留为：“这很好。我会做一些不同的事情，但它们不是很重要。”您似乎已经掌握了批评这是有代价的，如果您花大量时间在细节上，那将成为士气问题。理想情况下，将自动检查所有编码标准，除非您遵循它们，否则您将无法进行构建。这是节省大量时间的工具，可让您开始工作。如果您对“重要的事情”保留批评，您的建议将产生更大的影响，并且您将被视为重要的导师。区分不好的事情和不正确的事情是非常关键的。
我相信可教导的时刻这一概念。如果开发人员具有足够的智力，他可能会要求您提供有关您将采取的其他措施的详细信息。 （S）他可能没有，没关系。人们会精疲力尽，并且在职业生涯的早期，可能会花费大量的精力来完成以后似乎很简单的事情。
评论
避免无休止的代码审查周期的一种方法是使更改变小。如果做出有益的更改，那么拉取请求就不会小得可笑（我分享了1个字符的PR）。越小越好。毫不留情地削减了发给初级开发者的门票的范围，并让他们把事情做好。一旦他们精通整个阅读理解代码测试复习部署过程，范围就会扩大。
– 9000
17年6月6日在16:56
我认为告诉开发人员“他们不是很重要”是否对OP足够重要以便以后回头再改，这不是一个好主意。
– enderland
17年6月6日在17:51
@enderland以我的经验，没有完美的代码。您以后可以随时对其进行改进，因此在此并不重要。 OP说这些是“如果有空闲时间可以解决”的问题。有两种问题。必须修复的事物和不需要修复的事物。后者可能是固定的，也可能不是固定的，听起来好像属于该类别。这在某种程度上是一个判断性要求，但是我认为，作为一个经验丰富的开发人员，如果不确定是否必须更改，那么您不确定是否值得这么做，但事实并非如此。
– JimmyJames
17年6月6日在18:08
#4 楼
我会考虑在他的工作可以接受而不是完美时接受他的工作。然后，下一个任务是在讨论之后，通过进行所有小的但重要的更改来立即重构它。因此，当工作被首次接受时，您的信息是：这还不错，并且有些地方会接受它的效果很好-但是您不希望成为初级开发人员谁想要正确地学习他的交易。
所以你不要说“我拒绝你的工作，因为它不够好”。您说（a）“我接受您的工作是因为它足够好”，然后说（b）“但是我希望它更好”。
评论
或“（b）而且我知道您可以做得更好。”。如果他问“教我”，您就知道他在正确的道路上。 :)
–马查多
17年6月6日在19:26
在我以前的职位上，我们使用Stash / BitBucket作为我们的代码审查工具。它可以选择通过设置未完成的任务或完全拒绝该请求来阻止请求。我只会将它们用于必要的更改。如果进行了外观上的更改（例如，较小的代码可读性，更好的数据结构，重构），我会提出一些建议，但不要添加阻止任务，如果有时间，请执行此操作。这也可以防止因小事而错过最后期限。
–Hand-E-Food
17年7月7日在0:05
#5 楼
这个人愿意接受批评，愿意学习，但是我有些怀疑我应该投入多少。
尽一切可能。如果这个人正在学习，并且查看他的代码是您的工作，那么如果他做得很好，你们俩都有很多收获。
这将意味着您将来需要审查的代码更少，并且可能给您的团队一个招聘目标。
此外，如果您退缩，您就不会帮助，但光顾。
就在您将问题张贴在这里，问您是否做得太多的情况下，就已经向我表明您不需要此特定建议，但是对于其他人来说，这就是：请记住，努力奋斗并不意味着成为一个混蛋。
成为一名导师并非易事。您还必须给他一些空间，让他犯一些错误并自己纠正，只要确保他会在不会造成实际损害的地方这样做即可。
#6 楼
相当开放的问题，但是这里有一些想法。同行评论（由初级开发人员提供）
最佳的方式是某人学习“正确”的方法就是看到别人去做。您所有的开发人员都执行代码审查吗？让您的初级开发人员也执行它们可能不是一个坏主意（尽管您也应该至少要求高级开发人员进行一次审核）。这样，他将看到优秀的编码器在起作用，此外，他还将观察到针对他本人以外的工程师的评论意见，这意味着它不是个人的。
早期反馈/任务审查
允许开发人员参与自己的任务分解。让他在任务记录中记录他的预期设计，然后提交“代码复审”，其中没有变更集，而只是任务。这样，您可以在他编写单行代码之前查看他的计划。一旦检查了他的任务，他就可以开始编码（此后，他将提交另一个编码检查）。这样可以避免开发人员写了很多东西而不得不告诉他重写的情况，这令人沮丧。
评论
我喜欢同行评审的想法，目前只有团队中的两个人，但我可以让他评审我的代码。如果他能理解我的工作并发现一些矛盾之处，那么对于代码质量和士气都可以帮上忙。当我学习seing时，这对我很有帮助，我不是唯一一个犯错误的人+1
–所罗门
17年6月6日在18:52
#7 楼
如果代码在客观上违反了书面的，明确的标准，那么我认为您应该继续努力直到解决每个问题。当然，对于开发人员来说，前几次提交可能会有些烦人，但他们最好还是比后来者更早地了解准则。此外，如果您允许在这里和那里多次违反标准，他们将树立一个不好的先例-参见破窗理论。此外，如果已经将其一致地应用于代码库，则记住遵循标准会容易得多。因此，真的，每个人都赢了，包括有问题的初级开发人员。
只要写下编码标准，我认为士气不是什么大问题。只有当它进入更加主观的“好吧，我会做不同的事情”的领域时，才应该担心，因为开发人员的方法可能同样有效。
#8 楼
考虑采用代码审查工作流，开发人员在其中将其建议的提交发布到诸如Github Pull Requests或Phabricator Diffusion之类的工具上，并在将其更改降落到共享master分支之前获得同级签收。通过这种方式，而不是追溯批评或要求某人重做已完成的工作，只有在经过同行评审后才可以完成工作。与同行的来回交流与编译器的来回交流一样，是软件工程过程的一部分。
您可以将您的关注点发布为特定行上的注释，并进行线程化关于它们的讨论。他可以对您的代码执行相同的操作。讨论主要集中在拟议的特定代码更改上，而不是某个人的总体表现或能力上。
我的公司即使是精明的高级工程师也很感激代码审查发现拼写错误或迫使他们使事情变得更清楚。对于新员工来说，需要更多轮回是完全正常的。随着时间的流逝，您开始反思地解决您知道会在发布差异之前引起评论的问题。第一次尝试接受更高比例的差异是您知道自己正在改进的方式。
#9 楼
我并没有不断地向初学者介绍一些细微的细节，这可能会让人感到沮丧，但是我也担心过分的“软”会阻止他学习如何做一些东西。
这些既是真实的可能性，也是有效的担忧。询问开发人员对此感觉如何。
评论
实际上，他告诉我他感到自己很蠢。我试图保持批评的积极态度，我告诉他我对他的工作感到满意，我也向他解释说，我刚开始时就有这种怀疑，但我必须假设一些给予他的反馈意见为了改善他的工作，这是错误的。
–所罗门
17年6月6日在21:29
解释说，如果您不期望他的代码能使他成为一个更好的程序员，那么您不会浪费时间仔细批评他的代码。谨慎区分“您需要解决此问题才能使代码可接受”和“这是您下次可以做的更好的事情”。提供大量有见地和准确的批评是您可以给初级程序员的最大礼物。不这样做会使他们成为更糟糕的程序员。批评应该开始逐渐减少。每个错误只需犯一次，也许两次就可以了，只有那么多错误。
– David Schwartz
17年7月7日在5:08
#10 楼
假设您有一些请求请求或代码审查工作流，并且看来确实如此，那么我建议您注意“非关键”或“优先”的事情。如果看到类似的PR陈述您所描述的内容，一些小风格问题或需要非关键性的重构，请发表评论，但也可以随时批准。这样说，“将来，也许应该避免使用像这样的方法名称，而推荐使用诸如descriptiveMethodName之类的名称”，这样可以记录您的意见，而不必强迫他们进行更改或阻止其发展。
现在他们知道您的喜好了，如果他们正在尝试改进，希望将来会注意到这种情况。如果他们同意您的意见并认为它足够关键，那么这也给他们敞开了大门，让他们在那个时候实际改变它。
#11 楼
我正在和一个正在从编码工厂进行远程工作的初级开发人员打交道。
不幸的是，这不是理想的情况：一个负责一个新手的高级程序员程序员，具有地域分离。有点紧张也就不足为奇了，但是这种差距可以缓解。
我很好奇，“编码工厂”是什么意思？对我来说，该术语表示一种令人不安的态度，这可能会加剧您提到的一些管理问题。
…违反SRP，上帝对象，方法或方法的无意义名称变量我指出了他必须解决的问题，并试图解释为什么它是错误的。处理。作为经理和高级开发人员，这对于您提供指导和教导良好的软件开发习惯来说是失败的。如果您首先一起绘制轮廓，则可以防止一开始就编写不好的代码。就效率和士气而言，这比在代码生成后批评和重写代码更为可取。听起来您目前正在期望他为您提供产品。您需要的是更紧密的协作，以便您可以在开发的每个步骤中提供指导。在开始编码之前，先讨论一下设计和接口。在进行编码时，请执行更频繁的检查点以尽早发现问题。如果可能的话，请尝试通过屏幕共享和音频通道进行配对编程。
这一切都需要您付出更多的努力，但是考虑到当前存在的问题，这可能是值得的。
#12 楼
处理“太多批评”的另一个想法是不时自己做一个任务，让初级开发人员为您编写代码。这至少具有两个优点：他们可以看到您期望如何做。
如果存在多个好的解决方案或变量名，我会接受不同的建议但是（几乎？）同样好的方法。当我因某人的评论而修改我的代码时，我试图向人们表明他们受到尊重，而批评总是只涉及代码-无论作者是谁。
评论
我很乐意知道我的帖子出了什么问题。赞成票是可以理解的不同意的迹象，但是要删除投票吗？
– BartoszKP
17年7月7日在18:54
#13 楼
如果违反编码标准，请告诉他/她在哪里，以便他/她知道。如果您必须继续向他/她显示相同的错误，那么您可能会遇到一个不遵守规则或拒绝的人。不要用业余时间来纠正错误。此人应该纠正自己的错误，以免再次犯错。总是告诉他们他们做对了什么，以及下次如何改进。我们总是可以在某些方面变得更好。反馈对于改善任何方面都至关重要。
评论
您花了多少时间来确保他知道您的期望是什么？如何停止镀金并满足于发布工作进展的可能重复
@gnat我认为情况不一样，我的问题不是我们超出了估计或超出了代码范围。事实上，我们提前完成了计划。我的问题是如何在教导这个人与不因不断批评而使他疲倦之间保持平衡，对于一个初中生来说，如果您告诉他重做一些对他有用的东西，可能会令人沮丧。
我对此进行了编辑，以使其在主题上更有意义。我认为这也与链接的重复问题不同。
我尝试过的一些方法对此有所帮助：配对编程-深入了解他的工作方式和思维方式，并可能在您遍历代码时将其置于您的思维过程中。找到他擅长的任务-有时，与大量功能工作相比，向他抛出许多小错误会得到更好的结果。技术设计-在不接触代码的情况下让他在设计软件方面拥有第一手的技巧。这使他可以思考结构和流程，而不是放下头脑，编写代码。最后，祝你好运。有时需要的持久性要比预期的强，但如果他变得有生产力，那是值得的。