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?


当前回答

人们编写糟糕的代码只是无知的一种症状(这与愚蠢不同)。这里有一些对付这种人的技巧。

Peoples own experience leaves a stronger impression than something you will say. Some people are not passionate about the code they produce and will not listen to anything you say Paired Programming can help share ideas but switch who's driving or they'll just be checking email on their phone Don't drown them with too much, I've found even Continuous Integration needed to be explained a few times to some older devs Get them excited again and they will want to learn. It could be something as simple as programming robots for a day TRUST YOUR TEAM, coding standards and tools that check them at build time are often never read or annoying. Remove Code Ownership, on some projects you will see code silos or ant hills where people say thats my code and you can't change it, this is very bad and you can use paired programming to remove this.

其他回答

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

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

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

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

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

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

我总是说‘这就是我要做的’。我不会试图教训他们,告诉他们他们的代码是垃圾,而只是给他们一个不同的观点,希望能向他们展示一些明显更整洁的东西。

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

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