I've been working with a small group of people on a coding project for fun. It's an organized and fairly cohesive group. The people I work with all have various skill sets related to programming, but some of them use older or outright wrong methods, such as excessive global variables, poor naming conventions, and other things. While things work, the implementation is poor. What's a good way to politely ask or introduce them to use better methodology, without it coming across as questioning (or insulting) their experience and/or education?


当前回答

我真的很喜欢EnderMB的回答,但我想补充一点:

培养一种鼓励讨论代码质量的环境,而不是将其视为敏感或禁忌。例如,我曾在一个开源项目(一个Python库)中工作,团队经常讨论新代码和错误修复。不仅可以说“嘿,我认为这样做更好”,而且这实际上是被鼓励的,也是我们用于维护高质量代码的过程的一部分。

我知道不是每个环境都有利于这种过程,但它确实对我们很有效。每一次代码提交并不一定是一次委员会会议,但它应该是完全可以接受的,您可以讨论有问题的或非最优的代码并寻求改进。毕竟,更好的代码对团队中的每个人都有好处,团队合作的一个主要概念是一起工作,而不是松散的个人团体。

其他回答

如果你有一个松散的编码标准,能够指出这一点,或者表明你不能遵循代码,因为它不是正确的格式可能是值得的。

如果您没有编码格式,现在将是一个好时机。类似于这个问题的答案可能会有帮助:https://stackoverflow.com/questions/4121/team-coding-styles

在他面前重构他的代码,并显示两个版本之间的差异。他肯定会喜欢的。

我和和我一起工作的人有类似的情况。他们不像我那样接触编码,但他们在编码方面仍然很有用。

而不是我让他们做他们想做的然后回去编辑整篇文章。我通常只是让他们坐下来,告诉他们两种做事的方法。他们的方式和我的方式,从这里我们讨论了每种方法的优缺点,因此对我们应该如何进行编程有了更好的理解和更好的结论。

这是真正令人惊讶的部分。有时他们会提出一些连我都不知道答案的问题,经过研究,我们都对方法论和结构有了更好的概念。

讨论。 告诉他们为什么 甚至不要认为你总是对的。有时甚至他们也会教你一些新东西。

如果我是你,我也会这么做

进行代码审查,并从审查你的代码开始。

这将使人们在整个代码评审过程中感到轻松,因为您是通过评审自己的代码而不是他们的代码来开始这个过程的。从你的代码开始也会给他们提供如何做事的好例子。

在Gerry Weinberg的书《计算机编程心理学》中有一些非常好的建议——他的“无我编程”的整个概念都是关于如何帮助人们接受对他们代码的批评,而不是对他们自己的批评。