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?
当前回答
坦白地说,我相信当某人的代码更容易修改、调试、导航、理解、配置、测试和发布时,他的代码就会更好。
也就是说,我认为不可能告诉某人他/她的代码不好,而不先让他/她解释它是做什么的,或者任何人应该如何增强它(比如,创建新功能或调试它)。
只有到那时,他们的大脑才会崩溃,任何人都能看到:
全局变量值的变化几乎总是不可追踪的 庞大的函数很难阅读和理解 模式使您的代码更容易增强(只要您遵守它们的规则) (等)
也许一段结对编程就能达到目的。 至于执行编码标准——这是有帮助的,但它们离真正定义什么是好代码还很远。
其他回答
如果你有一个松散的编码标准,能够指出这一点,或者表明你不能遵循代码,因为它不是正确的格式可能是值得的。
如果您没有编码格式,现在将是一个好时机。类似于这个问题的答案可能会有帮助:https://stackoverflow.com/questions/4121/team-coding-styles
代码标准的想法是一个很好的想法。
但考虑一下不要说什么,尤其是因为这是为了好玩,而且大概是和你的朋友。这只是代码……
在Gerry Weinberg的书《计算机编程心理学》中有一些非常好的建议——他的“无我编程”的整个概念都是关于如何帮助人们接受对他们代码的批评,而不是对他们自己的批评。
我总是说‘这就是我要做的’。我不会试图教训他们,告诉他们他们的代码是垃圾,而只是给他们一个不同的观点,希望能向他们展示一些明显更整洁的东西。
开始进行代码评审或结对编程。
如果团队不愿意这么做,那就尝试每周设计回顾。每周开一个小时的会,讨论一段代码。如果人们看起来很有戒心,那就选择那些没有人在情感上依恋的旧代码,至少在一开始是这样。
正如@ jesere所说,关注代码,而不是编码员。
当你看到一些你认为应该不同的东西,但别人不这么看的时候,那就开始问一些导致缺陷的问题,而不是指出它们。例如:
Globals:你认为我们还会想要更多这样的东西吗?你认为我们会想要控制它的使用权吗?
可变状态:你认为我们想要从另一个线程操纵它吗?
我还发现关注自己的局限性很有帮助,这可以帮助人们放松。例如:
长功能:我的大脑不够大,不能一次容纳所有这些。我们怎样才能做出更小的我能处理的东西呢?
坏名声:在阅读清晰的代码时,我很容易感到困惑;当名字被误导时,我就没有希望了。
最终,你的目标不是教会你的团队如何更好地编码。而是在你的团队中建立一种学习的文化。每个人都向他人寻求帮助,成为更好的程序员。
推荐文章
- 检查字符串是否包含字符串列表中的元素
- codestyle;把javadoc放在注释之前还是之后?
- .toArray(new MyClass[0]) or .toArray(new MyClass[myList.size()])?
- 你如何告诉别人他们写的代码不好?
- main()中的Return语句vs exit()
- 对于一个布尔字段,它的getter/setter的命名约定是什么?
- 为什么CSS选择器/ HTML属性首选破折号?
- 在c++中使用"super
- 在PHP中使用getter和setter而不是函数或简单的公共字段有什么优点?
- foo到底是什么意思?
- 什么时候使用“this”关键字?
- 对Python ' import x '和' from x import y '语句排序的正确方法是什么?
- 在Python中创建空列表
- 将c++定义放在头文件中是一个好习惯吗?
- 使用“for”循环遍历c++ Vector