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?


当前回答

我很喜欢代码,在我的生活中从来没有上过任何与信息学相关的课程,我一开始很糟糕,开始从例子中学习,但自从我读了“四人帮”这本书以来,我一直记得并一直在我的脑海中:

“每个人都能写出机器能理解的代码,但不是所有人都能写出人类能理解的代码。”

考虑到这一点,在代码中有很多事情要做;)

其他回答

使用一些wiki软件在你的网络上创建一个wiki。

在你的网站上开始一个叫做“最佳实践”或“编码标准”的类别。

把每个人都指向它。允许反馈。

当您发布软件时,让负责将代码放入构建中的人员向开发人员推送,让他们指向上面的Wiki页面。

我曾在我的组织中这样做过,人们花了几个月的时间才真正熟悉使用Wiki,但现在它是一个不可或缺的资源。

耐心再怎么强调都不为过。我见过这种完全事与愿违的事情,主要是因为有人希望现在就发生变化。相当多的环境需要进化的好处,而不是革命。今天强行改变,可能会给所有人带来一个非常不愉快的环境。

接受是关键。你的方法需要考虑到你所处的环境。

听起来你所处的环境有很多“个性”。所以…我不建议使用一套编码标准。你会发现你想把这个“有趣”的项目变成一个高度结构化的工作项目(哦,太好了,接下来是什么……功能文件?)相反,正如其他人所说,你必须在一定程度上处理它。

Stay patient and work toward educating others in your direction. Start with the edges (points where your code interacts with others) and when interacting with their code try to take it as an opportunity to discuss the interface they've created and ask them if it would be okay with them if it was changed (by you or them). And fully explain why you want the change ("it will help deal with changing subsystem attributes better" or whatever). Don't nit-pick and try to change everything you see as being wrong. Once you interact with others on the edge, they should start to see how it would benefit them at the core of their code (and if you get enough momentum, go deeper and truly start to discuss modern techniques and the benefits of coding standards). If they still don't see it... maybe you'll need to deal with that within yourself (especially on a "fun" project).

耐心。进化,而不是革命。

祝你好运。

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

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

开始进行代码评审或结对编程。

如果团队不愿意这么做,那就尝试每周设计回顾。每周开一个小时的会,讨论一段代码。如果人们看起来很有戒心,那就选择那些没有人在情感上依恋的旧代码,至少在一开始是这样。

正如@ jesere所说,关注代码,而不是编码员。

当你看到一些你认为应该不同的东西,但别人不这么看的时候,那就开始问一些导致缺陷的问题,而不是指出它们。例如:

Globals:你认为我们还会想要更多这样的东西吗?你认为我们会想要控制它的使用权吗?

可变状态:你认为我们想要从另一个线程操纵它吗?

我还发现关注自己的局限性很有帮助,这可以帮助人们放松。例如:

长功能:我的大脑不够大,不能一次容纳所有这些。我们怎样才能做出更小的我能处理的东西呢?

坏名声:在阅读清晰的代码时,我很容易感到困惑;当名字被误导时,我就没有希望了。

最终,你的目标不是教会你的团队如何更好地编码。而是在你的团队中建立一种学习的文化。每个人都向他人寻求帮助,成为更好的程序员。

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

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

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

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

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