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++》、《实用的程序员》……),并主动把它借给别人(“嘿,我用完了,有人想借吗?”)

其他回答

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

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

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

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

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

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

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

没有人喜欢听别人说他们的工作很糟糕,但任何理智的人都会欢迎指导和避免不必要工作的方法。

有一种教学流派甚至说,你不应该指出错误,而应该专注于做对的事情。例如,与其指出难以理解的代码不好,不如指出他们的代码特别容易阅读的地方。在第一种情况下,你会引导其他人像蹩脚程序员一样思考和行动。在后一种情况下,你会像一个熟练的专业人士一样思考。

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

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

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

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

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

您可能想要关注坏代码的影响,而不是您对它的风格是好是坏的主观看法。