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?


当前回答

介绍代码标准的思想。关于代码标准最重要的事情是它提出了代码库的一致性(理想情况下,所有的代码都应该看起来像由一个人一次编写的),这将导致更容易理解和可维护的代码。

其他回答

你必须解释为什么你的方法更好。

解释为什么函数比剪切和粘贴更好。

解释为什么数组比$foo1, $foo2, $foo3更好。

解释为什么全局变量是危险的,而局部变量会让事情变得更容易。

简单地提出一个编码标准,然后说“这样做”是没有价值的,因为它没有向程序员解释为什么这是一件好事。

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

重要的是激励和指导人们,即使有人明显犯了错误,也要表现出尊重。但是,不仅要有指导的方法,而且要有说明错误就是错误的方法。糟糕的代码应该做得更好。这不是可选的。从主管的角度来看,员工应该知道哪些代码是可以的,哪些是不可以的。它仍然应该以尊重和激励那些负责任的人来改善。

糟糕的命名习惯:总是不可原谅的。

是的,不要总是认为你的方式更好……这可能很困难,但必须保持客观性。

I've had an experience with a coder that had such horrible naming of functions, the code was worse than unreadable. The functions lied about what they did, the code was nonsensical. And they were protective/resistant to having someone else change their code. when confronted very politely, they admitted it was poorly named, but wanted to retain their ownership of the code and would go back and fix it up "at a later date." This is in the past now, but how do you deal with a situation where they error is ACKNOWLEDGED, but then protected? This went on for a long time and I had no idea how to break through that barrier.

Global variables: I myself am not THAT fond of global variables, but I know a few otherwise excellent programmers that like them A LOT. So much so that I've come to believe they are not actually all that bad in many situations, as they allow for clarity, ease of debugging. (please don't flame/downvote me :) ) It comes down to, I've seen a lot of very good, effective, bug free code that used global variables (not put in by me!) and great deal of buggy, impossible to read/maintain/fix code that meticulously used proper patterns. Maybe there IS a place (though shrinking perhaps) for global variables? I'm considering rethinking my position based on evidence.

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

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

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