作为一个技术团队的领导者，我应该如何处理团队成员的编码错误和错误实践？

Question

我是一个由大约5名开发人员组成的团队的技术团队组长。团队规模在某种程度上是动态的，因为团队成员定期离开其他项目，而其他人则从其他项目中加入团队。

我不时地偶然发现我的团队成员的代码，或者是在对其进行修改时，或者在附近编写一些东西，或者只是回顾他们的代码。有时(我猜，这篇文章经常足以写这篇文章)他们的代码写得很糟糕，要么是小错误(比如将两个日期对象转换成字符串以便进行比较)，要么是更大的错误(编写几乎相同的中到大型函数，只有一行差异，而不是一个可以处理这两种情况的函数)。

提高他们的技能并向他们指出这些错误的最好方法是什么？有时，我会与它们一起浏览这些代码片段，解释为什么它们应该以不同的方式编写。但我不想挑剔，让他们经常过来检查他们的代码。这里的答案是代码评审吗？如果是的话，应如何组织？他们应该包括所有的团队成员还是个人？应该多久举行一次？还有其他建议吗？

有类似的另一个问题，但实际上是不同的，因为除了对代码评审感到好奇之外，我还想知道提高团队成员编码技能的其他可能方法。此外，在我的问题中，截止日期并不起作用，因为我们可以在即将发布的版本之前或之后轻松地检查和/或修复代码。

Answer 1

在这种情况下，你可以做一些事情。首先，尽你所能找到一本规则手册给他们参考。换句话说，当这样的事情出现时，最好说，“看一看风格指南的第6页。”或者，“这里有一个网站的链接，可以解释一些我想让你知道的事情，”然后把这个链接保存在你的图书馆里。作为一名技术带头人，避免技术债务是你工作的一部分，所以这是你对他们的义务。

其次，不要指出他们做错了什么，而是问他们自己的代码问题。例如，当我不需要的时候，我的导师发现我复制数组，所以他问我：“你认为这里的代码到底在做什么？”我们有一种相互尊重的文化，这种文化使问题更有刺激性，而不是挑剔。

如果你从政策上治理，保持你作为看门人的角色，尊重他人，好员工会喜欢它，坏员工会找到另一份工作。记得公开表扬，但私下批评。反馈是一种天赋，如果你问他们，好的编码者会告诉你你做得如何。

Answer 2

下面是我对代码评审的想法。

理论上是个好主意，但你必须小心处理。程序员是有创造力的，自私自利的&可能是非常瘦的皮肤。一个开放的团队代码评审很容易变成罗马竞技场。编码者可以把对方的作品恶意地、毫无成果地挑选出来。即使你一对一地做，它也会变成一种消极的体验。Gavin关于私下批评的建议是很好的建议，而且当有开放的代码评审时很难维护。

Gavin(再次)关于编写样式指南或编码标准文档的建议也是很棒的，但是您必须拥有执行它的权限。我强烈建议在网上找到一个很好的模型，并调整一下，否则在那些把"{“打开的人和把它放在自己的行上的人之间会有血缘关系。我已经(认真地)看到(认真地)内置在签入工作流中的命令行代码格式工具，以强制执行公司风格(好吧，我想)，但也看到同一公司的叛逆编码人员使用相同的工具，用不同的样式参数来格式化签出时的代码”他们的方式“(不好)。

在新的内容上，买一个关于编程的好书的图书馆。“清洁代码”、“清洁编码”和“代码完整”，并试图开始学习和改进的文化。

Answer 3

我不是一个团队领队，所以我没有在实践中使用这个。

但是，在我看来，一场健康的竞赛是可行的。

让您的开发人员解决与工作无关的挑战。所有开发人员都面临同样的挑战。

确保事先解释好的解决方案(短功能、有意义的名称、效率等)。

当每个人都完成了，就投票赞成最好的执行。

每个人都在努力解决同一个问题，这一事实将使人们能够进行更深入的讨论，因为每个人都在考虑解决办法。

与工作无关的事实将减少对失败的焦虑，并使人们对批评更有反应。

使这些内容成为传统，将逐步提高整个团队的编码技能，而无需经过代码评审过程。