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库)中工作,团队经常讨论新代码和错误修复。不仅可以说“嘿,我认为这样做更好”,而且这实际上是被鼓励的,也是我们用于维护高质量代码的过程的一部分。

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

以一种非对抗性的方式提出一个更好的选择。

“嘿,我觉得这个方法也可以。你们怎么看?”[用手势表示屏幕上的代码明显更好]

重要的是激励和指导人们,即使有人明显犯了错误,也要表现出尊重。但是,不仅要有指导的方法,而且要有说明错误就是错误的方法。糟糕的代码应该做得更好。这不是可选的。从主管的角度来看,员工应该知道哪些代码是可以的,哪些是不可以的。它仍然应该以尊重和激励那些负责任的人来改善。

坦白地说,我相信当某人的代码更容易修改、调试、导航、理解、配置、测试和发布时,他的代码就会更好。

也就是说,我认为不可能告诉某人他/她的代码不好,而不先让他/她解释它是做什么的,或者任何人应该如何增强它(比如,创建新功能或调试它)。

只有到那时,他们的大脑才会崩溃,任何人都能看到:

全局变量值的变化几乎总是不可追踪的 庞大的函数很难阅读和理解 模式使您的代码更容易增强(只要您遵守它们的规则) (等)

也许一段结对编程就能达到目的。 至于执行编码标准——这是有帮助的,但它们离真正定义什么是好代码还很远。