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?


当前回答

让有问题的人就他们编写的代表性模块的代码向小组的其他成员准备一份演示文稿,并让问答环节来处理(相信我,它会的,如果这是一个优秀的小组,它甚至不应该变得丑陋)。

其他回答

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

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

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.

根据我的经验,曾经有一段时间,我们想要将一个windows应用程序更改为一个web应用程序并进行优化,因为它更容易更新和维护。但由于我的朋友是windows应用程序的主要贡献者,他不允许更改,然后剩下的就是历史了。

寓意:为了代码优化和更好的维护,在任何编程环境中,重视组织的目标都比重视个人的目标更重要。

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

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

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

让有问题的人就他们编写的代表性模块的代码向小组的其他成员准备一份演示文稿,并让问答环节来处理(相信我,它会的,如果这是一个优秀的小组,它甚至不应该变得丑陋)。

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

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

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