(这不是调查TDD优点的问题.还有其他地方可以进行此类讨论.提前致谢.)
我一直在遇到太多开发人员,他们都是技术新手,他们也报告了对测试驱动开发和NUnit的不满.
我听到负面评论,如:
" 我不喜欢NUnit. 我在一年前尝试过它,但是我忘记了如何使用它.让我们只使用这个Windows Form应用程序,我刚刚将其作为测试工具编写而成.测试代码无论如何都是一次性代码,什么是差异？无论如何,过去我的方式运作良好."
" 我对TDD保留.在我们最后的项目(这是与TDD我的第一个也是唯一的项目经验,顺便说一下),我们甚至不知道设计是什么了."
"更多的代码评论很糟糕？你疯了吗？如果你不介意,我真的有一些工作要做." (从旧学校的更多评论是更好的评论,你永远不会有太多的评论.)
当一个新手抱怨TDD在他们有史以来第一个使用TDD的项目中"不起作用"时,它真的是TDD失败了,还是开发者自己的技能还不足以取得好成绩？
我怎么能在没有他们讨厌我的情况下沟通呢？
问题的关键在于,可以通过外交方式向开发人员传达什么,以鼓励他们用新的开发技术对他们自己新生和不足的能力进行更诚实的评估,而不会危及我们重要的工作关系？
通常情况下,许多开发人员显然还没有完全掌握TDD的许多重要元素,以便在他们的第一个项目上完成它.
例如,我与之交谈的开发社区中的抱怨通常是:
从来没有尝试过查看或记住代码气味列表.
从来没有尝试过研究重构目录,也没有在实际项目或玩具项目中进行过任何学习.对于那些人来说,可能需要学习更多的OOP,以便能够很好地进行重构.重构远远不仅仅是"重命名方法"和"重命名变量",它们在Visual Studio 2005重构菜单中显示为项目.
从来没有尝试过研究或参与使用紧急设计(通过重构)实现的实际项目,而不是提前使用设计完成整个项目,而不是仅在编写代码后编写单元测试的整个项目,并且知道差异和任何一个之间的权衡和适用性.
他们似乎都已经使用NUnit的,一次,所以无论他们用它做,这是TDD,天哪,他们似乎认为.NUnit或单元测试的存在,并不意味着TDD,但他们甚至不知道甚至不知道.
这些都是聪明人.开发人员是聪明人,因为这是进入整个职业的障碍.你不能在职业中待太久.当然,他们可以理解它,如果他们自己应用一段时间来研究这些材料.
当人们的经验和知识总和显然太弱而无法对方法论或其结果进行评估时,人们如何能够诚实地告诉自己一种方法论是薄弱的？
然而他们确实......我相信这是自我保护行为.或者是懒惰.如果你甚至不能从Fowler重构书的目录中命名三个重构,或者如果你不能说出几个代码气味,你就是重构的新手,也可能是整个TDD方法,你所谓的1或者2个项目经验显然是不够的.
我可以对人们说什么或者我可以引导人们注意哪些材料,让他们做更多关于TDD成功所依赖的技能的知识,例如:
单元测试,
重构,
设计模式,
OO设计和分析？
每个主题都有完整的书籍,有些非常好.也许有一些更易于学习的技巧？我可以通过榜样教导人们,但我给自己的时间是有限的,而且,我在所有这些技术中也不是黑带.
而且,他们在一起.没有彼此,他们的工作效果不佳.单元测试和重构像花生酱和果冻一样.如果你不能进行grep单元测试,那么你的重构肯定不会有很好的结果!(问我为什么如果你还不知道,我很乐意向新人解释.)
无论我做什么或说什么,它都不会适得其反:
我不能疏远我的同事们的TDD概念 ; 而且,我不能疏远我的同事. 我将不得不每周与他们一起工作多年.
特别难以让其他长期高级开发人员感到不安,他们已经确立了自己在编程的其他方面非常精通.他们理所当然地为自己过去的成就感到自豪,但他们的自负或他们在编程中掌握所有事物的自我概念,几乎无法克服,不会伤害他们的感情.一些高级开发人员尚未准备好面对他们不了解一些他们应该向别人学习的新技术.在编程时,高级开发人员可以更加习惯和舒适地成为会议室中的专家,有时他们要求被视为这样,即使在涉及TDD及相关技术和技术时完全不切实际.
我很高兴地报告说,在编写结构化自动化单元测试时,我已经取得了相当不错的成功,通过使用配对编程,一对一.我认为,结对编程为受训者提供了一些真实生活的例子和经验,以及对更有经验和知识渊博的从业者的直接指导.
但结对编程还不够.他们需要学习更多的重构,代码气味,OOP概念和OOD&A概念,而且我不能在一个项目中教授所有这些,甚至不是很接近.
将你的想法强加给别人并让他们被接受是完全不可能的.您可以使用自己的方法,也许其他人希望在他们看到好结果时学习.你只是期待像TDD,结对编程等这些东西神奇地获益吗？
你也没有指出你的角色.(或者至少我没有找到它)
您可以尝试不同的方法:
提供关于TDDor nunit的午餐时间研讨会.显示您看到的好处.为开发人员/公司提供真实的例子和真正的好处.如果没有这些,你将无法接受观众.
至少你有人写自己的测试工具 - 这是一件好事.我会赞美这一点,并要求看到更多.
询问开发人员他们对问题的看法,他们想要什么样的测试或公司如何改进.你必须停止强加你的想法,让它来自他们.
编辑 - 来自经验
多年前我有类似的经历.我读过许多关于过程和开发软件的正确方法的书籍(tm),然后告诉大家我看到了正确的做事方式......没有人想听到它.我意识到我冒着被边缘化的风险并没有真正得到任何有用的成就.所以我只是闭嘴并在我刚刚领导的小组中实施了一些好的做法.大约4个月后,人们开始问我们如何获得我们提供的结果.
而不是寻找别人来找我们.(这不是我的计划,但回想起来它是有道理的.人们想要结果,而不是热空气)
将你的问题提炼成一行:
And how can I communicate that without them hating me for saying it?
作为一个如此优秀的开发者,你赢得他们的尊重,然后他们会听.这里真的没有任何捷径.我的建议是成为一名更好的开发者和更好的传道者.如果你从你想要教的人那里学习,那么他们可能会开始向你学习.
并且在充分尊重的情况下,您对TDD的态度也是相当虔诚的.这也无济于事.将此与TDD所涉及的重大文化变革相结合,您成功传福音的机会开始急剧缩小.
我认为TDD最大的问题是人们会专注于这些测试.
这些测试在某种程度上并不重要.通过所有测试只能证明您已通过所有测试.此外,您可以通过所有测试,完全覆盖,并且仍然有一个无人无法使用的糟糕,无法使用的应用程序.
通过100%的测试和制作优秀的产品之间的差距是这个行业的一点称为工艺.
此外,TDD只是指定设计的另一种方式.这是TDD的重要一点,让设计在某种程度上被锁定.
也许TDD不是一个问题,但您是否考虑过它是否真的适合您所处的环境,以及您正在进行的项目类型？您还没有提到您目前遇到的问题(甚至您目前使用的方法和实践)以及采用TDD的原因可以解决这些问题.你确定你所看到的阻力不是因为抵制变化,而是因为你试图解决一个不存在的问题吗？
TDD并不适用于所有环境.这肯定是赫克是不恰当的,我的工作,因为我们的工作速度过快,与通常写大致启动和规范细化/改/贯穿每一次迭代重写,所以我们不会有任何规定的行为,以测试对大多数的时间.此外,我们已经开发了一些实践,这意味着代码在许多情况下根本不需要测试,因为该方法是静态类型检查确保必须工作的单线程.
你的帖子中有很多评论标记你可能是相对缺乏经验的人,并且已经锁定了一种方法,你认为这种方法可以解决所有问题,如果他们要保留,你的同事必须学习跟你一起 不幸的是,在软件开发方面没有灵丹妙药,如果他们是具有丰富经验的高级开发人员,并且他们不相信TDD是合适的,那么也许,只是也许,值得倾听他们.
您还应该意识到TDD不是重构的先决条件,就像那些喜欢"红绿色重构"咒语的人希望的那样.如果您正在重构一个小区域并且知道它会影响什么,并且可以轻松地手动测试,那么您可以在重构期间和之后手动测试该区域.
京公网安备 11010802040832号 | 京ICP备19059560号-6 