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?


当前回答

首先,我会注意不要太快下结论。有些代码很容易被认为是坏的,尽管可能有很好的理由(例如:使用带有奇怪约定的遗留代码)。但让我们暂时假设他们真的很糟糕。

你可以建议建立一个基于团队输入的编码标准。但是你真的需要考虑他们的意见,而不仅仅是强加你对好的代码应该是什么样子的看法。

另一种选择是把技术书籍带进办公室(《代码完成》、《有效的c++》、《实用的程序员》……),并主动把它借给别人(“嘿,我用完了,有人想借吗?”)

其他回答

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

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

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

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

在Gerry Weinberg的书《计算机编程心理学》中有一些非常好的建议——他的“无我编程”的整个概念都是关于如何帮助人们接受对他们代码的批评,而不是对他们自己的批评。

这完全取决于你写作的文化。在一个自由软件项目中,你告诉他们他们写的代码不好,并给出积极的建议、改进方法和反馈。你也可以给他们的代码发送一个补丁。

一封友好的电子邮件也不会有什么坏处。

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

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

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

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

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