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?


当前回答

我不是我项目的首席开发人员,因此不能强加编码标准,但我发现糟糕的代码通常会迟早导致问题,当它发生时,我有一个更清晰的想法或解决方案。

通过在当时不插话,采取更自然的方法,我获得了领导更多的信任,他经常向我寻求想法,并让我参与项目的架构设计和部署策略。

其他回答

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

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

我不是我项目的首席开发人员,因此不能强加编码标准,但我发现糟糕的代码通常会迟早导致问题,当它发生时,我有一个更清晰的想法或解决方案。

通过在当时不插话,采取更自然的方法,我获得了领导更多的信任,他经常向我寻求想法,并让我参与项目的架构设计和部署策略。

我建议对这个问题采取积极的态度。与其指责你的同事使用糟糕的风格,不如就风格和评论准则提出一些建议,让你的整个团队都能遵循。

例如,如果你主要是一个。net商店,建议坚持微软的c#风格和注释指南,因为这将使你更符合社区的标准实践。

您还可以指出一些遵循统一代码风格的例子——例如,如果不熟悉代码库的人查看了它,他们就不必破译多种风格。可以这样想:如果你正在读一本书,很容易看出每一章都是由不同的人写的,你会在读了几章后感到困惑吗?

我认为重要的是不要用消极的方式批评你的同事。最好是向人们推销改变的好处,这比说服他们写的是糟糕的代码要容易得多。

通过例子。告诉他们正确的道路。

慢慢来。不要因为他们的每一个小错误就立刻痛斥他们,要从真正重要的事情开始。

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

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