我在同一家公司从一个团队搬到另一个团队.在旧团队(硬核c ++)中,我们进行了大量的单元测试.在我的新团队(也是c ++)中,他们进行功能测试.在审查期间,由于单元测试,他们拒绝我的代码.大多数团队都有兴趣学习新的东西,但不是那个VIP的人,并且有遗留的开发者方法.他必须在提交前接受代码.他抵制这种变化.建议吗？
//更新:我将在这个主题中告知我的任务发生了什么,但请理解它是一家大公司,需要时间.只是为了澄清,我做的测试很好,它总是在其他团队中工作.我不是新手.我不时需要制动依赖关系导致代码明显废话.在C++中,你有时必须这样做.这可能仅仅因为测试而引入了prod代码的变化.我认为进行单元测试证明了这种简单的改变.拥有它比拥有它更好.
// update2:感谢你提供了很多好的建议,显然这里没有灵丹妙药:(大部分球队都相信,但是2位高级(15y +)开发者仍然反对.我会简短地谈谈我的其他队员将会支持我所以我希望那些家伙会同意:)放松一下我开始学习红宝石:)
Joh*_*lla 43
您刚刚遇到了最困难的软件问题:人.虽然我在没有更多背景的情况下对你的老板进行二次猜测犹豫不决(例如,这真的是完整的测试图片吗？),完全拒绝你的代码仅仅是因为你包括单元测试是最好的问题.
最明智的路线是与这个人进行一对一聊天,以便你了解他的位置.你形容你的老板对改变有抵抗力,但通常人们不是那么黑白分明.比如,也许他认为你提交的风险给予该项目的新状态,不理解你的单元测试,您可以写更多的代码,因为你可以在它更高的信心代码量.所以我会给他怀疑的好处,并且首先要有心连心.
以下是您在谈话中要问的一些问题:
您对单元测试有何看法？它们如何适合我们的整体测试策略？
您提交的单元测试有什么问题？他们是否缺乏或缺乏某种方式？您是否对单元测试本身没有问题,但是我希望我的代码组织方式不同？
为什么我们的所有代码都应该在功能级别进行测试？
所有单元测试对我们的项目都不好或不合适吗？
当这些条件在更高的接口级别复制更复杂时,您计划如何发现与方法的特定输入相关的问题？
如果您对签入的单元测试有特定的异议,是否有任何异议在本地使用单元测试,以便我至少可以验证自己的代码？
如果你觉得你现在理解他的立场并且你想要编写软件的方式是站不住脚的,你就会有一个不同的问题要问自己:尽管有专业的可疑实践,你是否也喜欢留在团队中的工作,或者是时候开始寻找其他地方吗？
相反,如果你觉得你现在明白为什么规则在那里,你认为根据项目的整体背景是明智的,那么huzzah!你通过专业的处理来避免潜在的危机,你可以留在你的新团队中,然后你可以回到有趣的部分:软件开发.
编辑:我真的不能同意这个问题中的一些帖子,告诉OP让自己适应团队.当团队购买实践时,实践的标准化才是好的.不是告诉OP来吮吸它和下降线,我们应该鼓励他了解为什么规则很到位,这样他就可以评估是否使得其自身的优点感.
经理也有一些解释,他可以帮助OP看他的方式.当然,并非所有人都会一直与经理们达成一致.我领导的项目或团队,并提出我的那不能取悦所有人决定的份额,但我总是试图让他们与大家第一个输入,这样我就可以在最好的方式做出决定.在我看来,通过管理命令强制执行一套"标准"而不考虑对团队的影响而忽略其他建议会使你成为一个糟糕的经理,而不是一个好的经理.
Jea*_*ean 10
将单元测试存储在并行版本控件中,并仅将代码提交到中央系统.他将在没有单元测试的情况下检查您的代码,您仍然可以从中受益...
另外,我建议使用分布式版本控制之一,你可以玩一个新的,有趣的玩具,当你的其他同事想要尝试时,他可以轻松地拥抱和扩展你的测试套件.
编辑 要澄清以下注释:
我建议他为他的单元测试设置一个本地源代码库.代码本身仍将与托管存储库同步(通过正常的提交过程,只是不提交测试和代码).
他还可以保留他认为在他的硬盘上有用的单元测试并且它不会改变任何东西,就像我所知道的任何开发人员为了各种目的而有一些"工具"文件一样.
他的想法是,通过单元测试,他可以希望他的错误率低于其他人.在与他的技术主管争论这种事情时,它可以提供帮助.只要他按时完成指定的工作,我就不明白为什么他不能按照自己认为合适的方式工作.
Jam*_*ate 10
开发团队中最重要的事情是坚持标准,即使您不同意标准.如果每个人都做自己的事情,那么制定标准毫无意义.
你可以保持单元测试,以满足自己的个人满意度/自信心.也许有一天你可以证明你的方法已经阻止了以某种方式重新修复或使团队受益的错误,然后可能更容易得到你的观点.
有一天,你将成为制定标准的人,然后有些人会不同意你.然后你可以告诉他们这个故事.
免责声明:我会在适当的时候使用单元测试,也会鼓励任何为我工作的人.
对不起,你必须让自己适应团队.你不得不经常谈论单元测试,你不可能在一天内说服他们.
我的主要不知道什么空中接力,他仍然在C#编程,现在说服他使用的构造函数,也许在几个月,他会做的,而不是静态方法私有字段/方法.
适应自己.
单元测试有成本,而不仅仅是好处.来自http://www.joelonsoftware.com/items/2009/09/23.html:
Zawinski没有进行过多次单元测试.他们"原则上听起来很棒.鉴于悠闲的发展步伐,这肯定是要走的路.但是当你看到时,'我们必须在六周内从零完成,'好吧,除非我剪掉一些东西,否则我不能这样做.而我要删除的是那些并非绝对关键的东西.单元测试并不重要.如果没有单元测试,客户就不会抱怨."
来自:http://www.codinghorror.com/blog/2005/04/good-test-bad-test.html
我目前使用单元测试的主要问题是当我改变设计时,我会得到一堆失败的测试.这意味着我要么减少测试次数,要么减少大的设计变更.这两件事都是坏事.
我是一个懒惰的混蛋,他不会在任何接近单元测试的地方写字,但是当我的家伙们努力写下它们时,我并不会愚蠢地拒绝单元测试.你可以尝试在愚蠢的管理范围内工作,但除非有希望这个人很快就会从现场消失,我建议你找另一个团队.
| 归档时间： |
|
| 查看次数： |
1957 次 |
| 最近记录： |