(我使用"工作流程"这个词 - 不是在异步工作流程的意义上 - 而是在"git工作流程"意义上,也就是说,如何将其用作开发的一部分)
玩了一段时间的F#,我开始开发我的第一个F#应用程序.我来自c#/ vb.观看了各种演示/演讲 - 无论是对还是错 - 我开始使用fsi作为主要的开发"引擎"并在该领域内开展工作.如果我遇到了需要调试的问题,我倾向于将有问题的功能分解成更小的位并检查那些工作以尝试调试问题.
但是,为了在fsi中保持代码量可管理,一旦我对我所做的事情感到满意,我就把它转移到.fs并将#fs重新加载到fsi中.随着应用程序变得越来越大,这可能会开始变得有点笨拙,因为当我需要重构时,我最终不得不从fs文件中恢复内容更改它运行的东西以使某些东西再次运行,然后再将代码推回去进入.fs文件.此外,这种风格并不是真正的测试第一种方法,因此我没有获得构建一组测试的好处.(我也可以错过设置断点/步进代码的能力,在某些情况下,例如递归,可以更快地诊断错误而不是破坏函数的某些部分 - 虽然这可能在VS11中可用而且我没有设置正确)..所以我认为我可能没有以最佳方式做事,或者没有以正确的方式思考问题.
我想知道其他人是否可以提供他们开发应用程序的方式.你主要使用fsi还是从tdd开始？应该将tdd方法作为主要的开发工具,并且FSI更有选择性地用于帮助实施更复杂的算法,数据探索等等
我已经看过这个问题,显然它有助于指出F#的各种tdd框架,但我仍然有兴趣找出经验丰富的F#开发人员的工作流程.
很多thx
小号
pad*_*pad 12
我认为你走在正确的轨道上.
开发过程是品味的问题.无论如何,我会分享我的方法.
fs文件开始.每个文件代表一个模块,它由一组彼此密切相关的功能组成.从一开始就没有必要精确; 你经常在模块之间移动东西.fsx一旦模块的骨架准备就绪,创建一些文件以便快速测试.fsx脚本提供正确的结果时,将它们移动到测试用例.反复这样做.Program.fs在主项目中包含一个并编译为可执行文件,以便在需要时进行调试.通常,F#REPL是主要的开发引擎.它为我提供即时反馈并允许增量更改,这在原型设计中非常有用.在F#中,TDD不太重要,因为错误率远低于其他语言.我不会测试所有内容,只关注主要功能并确保高测试覆盖率.使用testdriven.net加载项或Visual Studio 2012 Premium和Ultimate可以为您提供有关测试覆盖率的有用统计信息.
使用F#REPL和TDD,我几乎不必使用调试.每当出现错误行为时,我都会停下来思考.由于您的代码没有副作用,您可以轻松地对其进行推理.在很多时候,推理和一些打印命令可以给我正确的答案.
您可以在F#REPL使用TDD与引文结束和FsCheck.前者通过报价提供测试,这非常令人印象深刻.后者使用随机测试方法,这在处理代码的角落情况时很有吸引力.当你的程序必须满足某些属性时,我发现它非常有用.但是,学习正确使用这些框架可能需要一些时间.