我是一名有很多经验的合同程序员.我习惯于被客户雇用进入我自己的某种形式的软件项目,通常是从零开始.这意味着几乎每次都是干净的石板.我可以引入我开发的库来快速启动,但它们总是可选的.(并且取决于在合同中获得正确的IP条款)很多时候我可以指定甚至设计硬件平台......所以我们在这里谈论严肃的自由.
我可以看到用于构建某些代码的自动化测试的用途:具有更多简单功能的库,具有大量引用的核心功能等.基本上,随着一段代码的价值在大量使用中上升,我可以看到它自动测试该代码将变得越来越有价值,以便我知道我不会破坏它.
然而,在我的情况下,我发现很难合理化任何东西.我会采用它们证明有用的东西,但我不会盲目跟随任何事情.
我发现我在"维护"中所做的很多事情实际上都是小的设计变化.在这种情况下,测试不会为我节省任何东西,现在他们也必须改变.高度迭代,存根优先的设计方法对我来说非常有效.通过更广泛的测试,我无法看到实际上节省了很多时间.
业余爱好项目更难以证明......他们通常都是从周末到月份的任何事情.边缘案例错误很少发生,它只是玩弄东西.
读书问题,比如这一个,最表决的反应似乎是说,在海报的经验/意见TDD实际上是浪费时间,如果你有少于5人(即使假设能力一定水平与TDD /经验).但是,这似乎涵盖了初始开发时间,而不是维护.目前尚不清楚TDD如何在项目的整个生命周期中叠加.
我认为TDD可以成为提高整个行业产品质量的有价值目标的一个很好的步骤.尽管如此,理想主义本身不再能够激励我.
我不认为TDD将是大团队是一个很好的做法,或含有至少一个不可靠的程序员任何规模的团队.那不是我的问题.
为什么一个拥有良好记录的唯一开发人员会采用TDD？
我很想知道在TDD上完成的任何指标(正式与否)......专注于独立开发人员或非常小的团队.
如果做不到这一点,你个人经历的轶事也会很好.:)
如果没有经验,请避免说出意见.让我们不要把它作为一场意识形态战争.此外,跳过更大的就业选择论点. 这只是一个效率问题.
Bil*_*ard 19
我不会盲目跟随任何事情.
这是正确的态度.我一直使用TDD,但我并不像某些人那样严格遵守.
支持TDD的最佳论点(在我看来)是当你最终进入项目的重构和维护阶段时,你可以运行一组测试.如果这是您使用TDD的唯一原因,那么您可以随时编写测试,而不是盲目地遵循该方法.
我使用TDD的另一个原因是编写测试让我开始考虑我的API.在写这篇文章之前,我不得不考虑如何使用类.让我进入这个高水平的项目对我来说很有用.还有其他方法可以做到这一点,如果你发现其他方法(有很多)可以做同样的事情,那么我会说继续做对你有用的方法.
Kil*_*fer 14
我觉得单独飞行时更有用.由于周围没有任何人可以反复提出想法并且没有人来执行同行评审,因此您需要确保您的代码是可靠的.TDD/BDD将为您提供这种保证.但TDD有点反对.其他人可能完全不同意我所说的话.
编辑:我可以补充说,如果做得对,你可以在编写测试的同时为你的软件生成规范.这是BDD的一个很好的副作用.你可以让自己看起来像超级开发人员,如果你正在制定可靠的代码和规范,所有这些都是你自己的.
Gis*_*shu 11
好了,轮流......我甚至可以自己做TDD(对于非尖峰/实验/原型代码),因为
如果我再想的话,我会更新......这是我在最后2分钟的反思中提出的.