9 我一直喜欢JoelOnSoftware上的这篇文章，“当您只是咕Gr咕Get咕Get咕咕咕的时候就做的事情”。当我是新手时，我尤其可以与他人联系（并且仍然觉得我将永远是其中的一员）。 关于＃4，中和bozo。您对在实际工作中实际实施此操作有什么建议？（至少在我们的团队中）这似乎不像简单地将错误记录到某人的错误代码上那样容易。什么对所有人都有效？ team bug — 约翰逊 source 1 枪 其中很多。 — CodesInChaos 2014年
9 永久评估。 而就在结束每一天花30分钟左右查看他们写什么。如果他们做错了什么，请让他们重写。 除非您这样做，否则您将有一天会意识到，应用程序的一部分，尽管看起来能够完成这项工作，却是完全无法维护的，设计不当的，并且在将来甚至明天会引起很多问题。 即使这会使他们的生产力降低，但是如果他们产生了一些好的代码，但是却产生了两倍以上的大小却无法维护的错误，那仍然会更好。 — P切 source 2 好答案。如果我可以补充一下，如果这个人是同事，那么最好由团队负责人来完成。这样，如果由商店的层次结构命令，那么它的“不好做”响应将更加有效。 1 @Surfer，恰恰相反。你成为做这样的事情，球队的领袖，通过提出更好的解决方案，通过爱心团队做什么。反之亦然。（但是，当然，从更高层次的层次获取帮助会有所帮助）。 — P 1 因此，问题就来了，谁有权使他们重写？我想答案是，如果问题传播到整个团队，那么整个团队的道德权威就可以了。 — C约翰逊 在没有针对每个团队成员的健壮代码审查机制的情况下，这样做是适当的。还应确保在被告知进行重新加工之前，不要将凸齿挖出真正深的孔（甚至不值得修复）。 — mattnz'7
5 如果这个人只是不懂任何东西，但是想学习，请提供一些指导和代码审查。确保他们接触良好的代码。 真正可怜的开发人员是那些处境不好并竭力学习新知识的开发人员。您唯一的希望是让他们通过维护自己的混乱或一些更简单的东西而受苦。理想情况下，当权者站起来并说服从或离开。 — 杰夫 source 1 态度真的很重要。我通常会觉得新手比较谦虚，并且愿意接受代码审查和批评。这些人很容易交谈。您可以轻松地与他们谈论他们的弱点。是那些傲慢的退伍军人，当他们因自己的作品而受到批评时，他们将像一百万块玻璃一样破碎。 — C约翰逊