我一直在与一小群人一起开展编码项目,以获得乐趣.这是一个有组织,相当有凝聚力的团体.我与之合作的人都拥有与编程相关的各种技能,但其中一些使用较旧的或完全错误的方法,例如过多的全局变量,较差的命名约定等.虽然事情有效,但执行情况很差.礼貌地询问或介绍他们使用更好的方法,而不是质疑(或侮辱)他们的经验和/或教育的方法是什么？
介绍问题,让他们意识到他们所做的事情是错误的.例如,问这些问题:
你为什么决定把它变成一个全局变量？
你为什么给它这个名字？
那很有意思.我通常这样做是因为[插入原因为什么你更好]
这种方式有用吗？我通常[插入你会如何让他们看起来很傻]
我认为理想的解决方法是巧妙地问他们为什么以某种方式编码.您可能会发现他们认为其他方法有益处.除非我知道他们的编码风格的原因是由于错误的信息,我绝不会在没有充分理由的情况下判断我的方式更好.解决这个问题的最好方法就是问问他们为什么选择这种方式; 一定要对他们的推理感兴趣,因为这是你需要攻击的,而不是他们的能力.
编码标准肯定会有所帮助,但如果它是每个软件项目的答案,那么我们都会在天堂的私人岛屿上品尝鸡尾酒.实际上,我们都容易出现问题,软件项目的成功率仍然很低.我认为这个问题主要源于个人能力,而不是常规问题,这就是为什么我建议当一个问题出现问题时,我们会将问题作为一个整体来解决.
最重要的是,不要立即假设你的方式更好.实际上,它可能是,但我们正在处理另一个人的意见,他们只有一个解决方案.永远不要说你的方式是更好的方式,除非你希望他们看到你是一个自鸣得意的失败者.
开始进行代码审查或配对编程.
如果团队不会去那些,请尝试每周设计评论.每个星期,约会一个小时,谈论一些代码.如果人们看起来很咄咄逼人,那就选择一个没有人情感依赖的旧代码,至少在开始时如此.
正如@JesperE:所说,专注于代码,而不是编码器.
当你看到你认为应该有所不同的东西,但其他人看不到同样的方式,那么首先提出导致缺陷的问题,而不是指出它们.例如:
Globals:你认为我们想要不止一个吗？你认为我们会想要控制对此的访问吗？
可变状态:你认为我们想要从另一个线程操纵这个吗？
我也发现关注我的局限是有帮助的,这可以帮助人们放松.例如:
长期功能:我的大脑不够大,不能同时掌握所有这些.我们怎样才能制作出能够处理的小件？
坏名字:在阅读清晰的代码时我很容易混淆; 当名字误导时,对我来说没有希望.
最终,目标不是教你的团队如何更好地编码.这是为了在团队中建立学习文化.每个人都希望其他人帮助他们成为更好的程序员.
介绍代码标准的概念.关于代码标准最重要的是它提出了代码库中一致性的想法(理想情况下,所有代码应该看起来像是由一个人一次编写),这将导致更易理解和可维护的代码.
你必须解释为什么你的方式更好.
解释为什么函数比剪切和粘贴更好.
解释为什么数组比$ foo1,$ foo2,$ foo3更好.
解释为什么全局变量是危险的,并且局部变量将使生活更轻松.
简单地编写一个编码标准并说"做这个"是没有价值的,因为它没有向程序员解释为什么它是一件好事.
首先,我要小心不要太快判断.很容易将一些代码视为糟糕,因为可能有很好的理由(例如:使用遗留代码处理奇怪的约定).但我们现在假设他们真的很糟糕.
您可以根据团队的意见建议建立编码标准.但是你真的需要考虑他们的意见,而不仅仅是强加你对良好代码应该是什么的看法.
另一种选择是将技术书籍带入办公室(Code Complete,Effective C++,Pragmatic Programmer ......)并提供借给别人("嘿,我已经完成了这个,任何人都想借用它？" )
如果可能,请确保他们了解您正在批评他们的代码,而不是他们个人.
以非对抗的方式建议更好的选择.
"嘿,我觉得这种方式也会奏效.你们觉得怎么样？" [在屏幕上显示更好的代码的手势]
进行代码审查,然后查看您的代码.
它将使人们对整个代码审查过程感到放松,因为您通过查看自己的代码而不是他们的代码来开始这个过程.从代码开始也将为他们提供如何做事的好例子.
他们可能会认为你的风格很臭.让团队一起讨论一套一致的编码风格指南.同意某事.这是否适合你的风格不是问题,只要它的一致性是重要的,任何风格.
以身作则.以正确的方式展示它们.
慢慢来.不要因为蝙蝠的每一个小错误而鞭打它们,只要从真正重要的事情开始.
代码标准的想法很好.
但是考虑不要说什么,特别是因为它是为了好玩,大概是与你成为朋友的人.这只是代码......
在Gerry Weinberg的书"计算机程序设计心理学"中有一些非常好的建议 - 他的"无我编程"的全部概念都是关于如何帮助人们接受对他们的代码的批评,而不是批评他们自己.
使用一些wiki软件在您的网络上启动Wiki.
在您的网站上创建一个名为"最佳做法"或"编码标准"的类别.
指向每个人.允许反馈.
当你发布软件时,让那些工作的人将代码放入构建中,推回开发人员,将他们指向上面的Wiki页面.
我已经在我的组织中完成了这项工作,人们花了几个月的时间才真正开始使用Wiki,但现在这是不可或缺的资源.
错误的命名行为:总是不可原谅的.
是的,不要总是假设你的方式更好......这可能很困难,但必须保持客观性.
我有一个编码器的经验,它具有如此糟糕的功能命名,代码比不可读更糟糕.这些功能谎称他们做了什么,代码是荒谬的.他们保护/抵制让别人改变他们的代码.当他们非常礼貌地面对时,他们承认它的名字很糟糕,但是想要保留他们对代码的所有权,并且会在以后"重新修改".现在这已经过去,但是你如何处理他们的错误被确认但是受到保护的情况？这种情况持续了很长时间,我不知道如何突破这一障碍.
全局变量:我自己并不喜欢全局变量,但我知道一些喜欢它们的优秀程序员很多.这么多,以至于我开始相信它们在许多情况下实际上并不是那么糟糕,因为它们允许清晰,易于调试.(请不要火焰/ downvote我:))归结为,我已经看到很多非常好,有效,无bug的代码使用全局变量(不是我的!)和大量的bug,无法读取/维护/修复精心使用正确模式的代码.也许有IS的地方(尽管可能萎缩)为全局变量？我正在考虑根据证据重新考虑我的立场.
京公网安备 11010802040832号 | 京ICP备19059560号-6 