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#风格和注释指南,因为这将使你更符合社区的标准实践。

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

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

这里的许多答案都与代码格式有关,但现在并不是特别相关,因为大多数ide将按照您选择的样式重新格式化代码。真正重要的是代码是如何工作的,海报是正确的查看全局变量,复制和粘贴代码,以及我的烦恼,命名约定。糟糕的代码是存在的,这与格式没有多大关系。

好的方面是,大多数情况下都有很好的原因,这些原因通常是可量化和可解释的。所以,用一种非对抗性的方式解释原因。在许多情况下,您甚至可以为作者提供问题变得明显的场景。

介绍代码标准的思想。关于代码标准最重要的事情是它提出了代码库的一致性(理想情况下,所有的代码都应该看起来像由一个人一次编写的),这将导致更容易理解和可维护的代码。

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

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

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

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