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