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?


当前回答

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

其他回答

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

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

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

我穿上长袍,打开一罐苏格拉底方法。

苏格拉底方法以古希腊哲学家苏格拉底的名字命名,是一种哲学探究的形式,提问者探究他人立场的含义,以激发理性思考和阐明思想。这种辩证方法经常涉及到一种对立的讨论,在这种讨论中,一种观点的辩护与另一种观点相对抗;一个参与者可能会导致另一个人在某种程度上自相矛盾,加强询问者自己的观点。

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

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

提出问题,让他们意识到他们所做的是错误的。例如,问这样的问题:

你为什么决定让它成为一个全局变量? 你为什么给它起这个名字? 这很有趣。我通常这样做,因为[插入你更好的原因] 这样行吗?我通常[插入你会如何让他们看起来很傻]

我认为最理想的方法是巧妙地问他们为什么要这样编码。你可能会发现他们相信其他方法也有好处。除非我知道他们的编码风格是由于错误信息,否则我永远不会在没有充分理由的情况下判断我的方法更好。最好的办法就是问他们为什么选择那样做;一定要让自己听起来对他们的推理感兴趣,因为这才是你需要攻击的,而不是他们的能力。

编码标准肯定会有所帮助,但如果它是每个软件项目的答案,那么我们都只能在天堂的私人岛屿上啜饮鸡尾酒了。在现实中,我们都容易遇到问题,软件项目的成功率仍然很低。我认为问题主要是源于个人能力,而不是传统的问题,这就是为什么当问题浮出水面时,我建议大家一起解决问题。

最重要的是,不要马上认为你的方法更好。在现实中,可能是这样,但我们在处理另一个人的意见,对他们来说只有一个解决方案。永远不要说你的方式是更好的方式,除非你想让他们认为你是一个自鸣得意的失败者。

我真的很喜欢EnderMB的回答,但我想补充一点:

培养一种鼓励讨论代码质量的环境,而不是将其视为敏感或禁忌。例如,我曾在一个开源项目(一个Python库)中工作,团队经常讨论新代码和错误修复。不仅可以说“嘿,我认为这样做更好”,而且这实际上是被鼓励的,也是我们用于维护高质量代码的过程的一部分。

我知道不是每个环境都有利于这种过程,但它确实对我们很有效。每一次代码提交并不一定是一次委员会会议,但它应该是完全可以接受的,您可以讨论有问题的或非最优的代码并寻求改进。毕竟,更好的代码对团队中的每个人都有好处,团队合作的一个主要概念是一起工作,而不是松散的个人团体。