将F＃引入大型代码库和工程团队的现实陷阱[关闭]

我是一家软件公司的CTO，该公司拥有大量现有代码库（全部为C＃）和相当大的工程团队。我可以看到，使用F＃编写代码的某些部分将变得更加容易，从而导致更快的开发时间，更少的错误，更容易的并行实现等，基本上可以为我的团队带来整体生产率的提高。但是，我还可以看到引入F＃的一些生产率陷阱，即：

1）每个人都必须学习F＃，这并不像从Java转换为C＃那样简单。尚未学习F＃的团队成员将无法处理代码库的F＃部分。

2）截止目前（2010年12月），没有可雇用的F＃程序员。在各种软件工程师的简历数据库中搜索“ F＃”，少于1％的简历包含关键字。

3）目前（2010年12月）的社区支持较少。您可以在C＃中搜索几乎所有问题，并找到已经处理过的人，而F＃却不是。第三方工具支持（NUnit，Resharper等）也很粗略。

我意识到这有点Catch-22，也就是说，如果像我这样的人不使用F＃，那么社区和工具将永远无法实现，等等。但是，我有一家公司可以经营，但我可以领先但不流血的边缘。

我没有考虑其他陷阱吗？还是有人愿意反驳我提到的陷阱？我认为这是一个重要的讨论，很想在这个公共论坛上听到您的反对意见，这可能对提高行业采用F＃起到很大作用。

搜索简历以查找其他功能语言，例如Scheme，Lisp或Haskell。很多人在学校学习这些内容，然后将它们放在简历中。我敢肯定他们中的许多人都不会介意学习F＃。即使我放学后从未使用过Scheme，我的履历中也有Scheme，涉及F＃的工作也可能引起我的注意。

我没有考虑其他陷阱吗？

实际上，我看到人们犯的主要错误是试图强迫使用F＃来解决问题，因为这是该工作的错误工具。

还是有人愿意反驳我提到的陷阱？

在某种程度上，它们显然都是有效的关注点，但是我想问到什么程度。

例如，您说每个人都必须学习F＃才能使用F＃代码。尽管是正确的，但实际上这并不是什么大问题。学习F＃并不比学习WPF，Silverlight或TPL重要。我现在正在教大约30个开发人员如何在伦敦的客户中使用F＃，大约有十几名开发人员在短短几周后就全职使用F＃代码，他们刚刚交付了他们的第一个产品（按时交付，预算内！ ）仅用了几个月就几乎完全用F＃编写了。实际上，他们在Silverlight方面比F＃遇到更多技术困难，并且他们发现Silverlight的技术支持比F＃差得多。

您指的是相对较少的可用F＃程序员，但是同样，考虑到拾取F＃的难易程度，我认为这不是重要的问题。我怀疑您是否需要雇用很多（如果有）。我的客户有两个F＃专家，可为100多位程序员提供服务，我们的工作是播种和监督F＃的使用。

您的第三个也是最后一个关注点是社区支持的减少，针对C＃解决方案的Google搜索与F＃和第三方工具的支持。再次，我在实践中没有发现这些问题。我通过电子邮件向fsbugs发送了有关F＃中的计量单位的评论，并在24小时内收到了研究人员的答复，该研究人员发明了它，并详细解释了我的解释为什么错误以及它为什么起作用。我从安德斯·海斯伯格（Anders Hejlsberg）那里得不到；-)。我一直在Google寻求解决方案，并发现它们都是用C＃，VB甚至IronPython编写的，但是在使用F＃行业的三年中，只能回忆起一个将解决方案转换为F＃并不容易的实例。实际上，我最近将数据序列化程序C＃示例从MSDN转换为F＃，它的长度缩短了5倍。最后，我们提到了NUnit等工具中的F＃支持 已经使用F＃中的NUnit了一段时间了。这些是.NET工具，而不是C＃工具。

案例研究：我现在的客户不仅使用NUnit进行单元测试，而且他们在NUnit之上的F＃中构建了TickSpec，作为SpecFlow for BDD的技术上更好的替代品。作者向我展示了TickSpec只是SpecFlow的很小一部分，并提供了更多功能。此外，一些没有F＃经验（而且我相信也没有函数式编程经验）的开发人员已经选择了它，并开始在无关的项目中使用它而没有问题，这恰恰是因为F＃+ TickSpec使解决他们的问题变得更加容易。问题。

FWIW，我为我的客户免费提供了F＃.NET Journal的站点订阅，许多学习F＃的开发人员都对此表示失望。

HTH！

正如您在第一点认识到的那样，不了解F＃的程序员无法在代码库的F＃部分工作。但是，您无需使用F＃重写整个代码库即可获得使用它的好处-只需重写您将看到最大收益的部分。F＃与C＃很好地互操作的事实应该使雕刻某些零件并从中创建F＃组件相对容易。

如果您的工程师在传统的3层应用程序上工作，那么您可能不会坚持认为他们都需要对SQL，HTML，Javascript，CSS等有深刻的了解。相反，您自然会需要一些专家来工作在应用程序的不同部分上。因此，我认为为您的应用程序的一部分添加新的语言不会有太大的障碍。此外，您可以使用编码标准和其他实践来确保即使没有深厚F＃背景的工程师也可以阅读您的F＃代码。

在您使用的语言中添加F＃的陷阱包括引入任何新技术的陷阱。不管有什么好处，如果您的某些团队不希望或没有足够的灵活性来学习，他们将无法从事F＃项目。但是，如果您让团队中的恐龙阻止您采用新技术，那么您的公司注定要失败。

我个人经历过的唯一陷阱是：

1. 调试时遇到困难。在为基于语句的语言设计的调试器中遵循基于表达式的程序的执行流程可能会很棘手。

2. 令人沮丧的智能感知。自动完成功能会在您需要时完全停止工作。Microsoft必须努力使后台解析器更具容错能力。

3. 缩进敏感的语法使得难以复制粘贴或重新格式化代码。

4. 缺乏重构。

5. 现有的一些方便的VS扩展（用于F＃）（代码折叠，深度着色）有些慢，使键入体验有些令人沮丧。

我认为，这些问题都不是阻碍因素，我暂时可以接受。工具比语言更容易改进和修复。

您担心聘用能够用F＃编写新程序的程序员会很困难，但我认为这没有道理。如果您要编写编码指南，您会建议还是禁止C＃中的以下任何功能：yield return对对象，lambda，即将到来的LINQ async？

如果您认为这些功能有助于编写更好的代码，则没有理由避免使用F＃。该语言以一种流畅且经过深思熟虑的方式支持这些功能，而C＃由于其原有性而无法真正做到。

如果您的团队足够聪明，能够理解我提到的功能背后的概念，那么他们拥有成为F＃优秀程序员所需的全部知识。对于将来的新员工来说，情况也是如此：您会雇用没有能力或不愿意使用C＃1.0之后引入的功能的人吗？

我已经考虑过这种确切情况。

这是我为团队计划的：

• 将C＃与F＃混合使用，这可以通过对大多数代码库使用C＃来完成。需要大量数据处理的地方，请用F＃编写关联的函数，然后将其放入dll中，或对其进行引用。这里的例子

• 以上述方式缓慢地重构现有代码库。

• 并非所有代码都必须具有功能。

• 让您的团队在周末学习Haskell，LISP 的基础知识。

• 通过尝试解决Euler Project难题（让我在学习F＃时对我有很大帮助）来使他们学习F＃。同样，这应该在周末结束时完成，或者在工作时间进行，如果您想留出一天进行“培训”。

1）学习一种功能语言将提高某人作为程序员的整体能力，但这仅适用于那些想学习和提高的人。并非每个程序员都希望变得更好，也不是每个人都希望改变工作环境（了解您的团队）。

2）我不能与此争论。您将需要为任何一种新语言的6个月学习曲线付费，但是已经知道.net库可以消除学习新库所需的额外时间。

3）社区支持虽然比C＃小，但确实有很多高技能的活跃F＃开发人员发布在网络上。不要忘记，大多数语言支持都是库支持，并且对.NET有很大的支持。

这里的一千磅大猩猩是风险管理。“我可以是尖端，但不能流血。” 我认为F＃并非没有优势。它已随VS​​2010一起发布，并得到Microsoft的直接支持。流血的边缘是“ beta”，是Microsoft的免责声明，它说不承担任何责任。

实际上，非常缺乏IntelliSense支持，以至于C＃中可用的复杂程度较低的自动完成功能使类型推断的生产率提高无法实现。

对于初学者（通常对于像我这样的中级用户），由错误的类型推断引起的错误消息也需要花费更长的时间才能解决，这仅仅是因为与使用C＃这样的语言相比，您不太愿意提供类型注释。

F＃中还缺少令人惊讶的OOP。例如，不支持嵌套类型/类。移植代码时必须小心，因为遗憾的是，在C＃中可以执行某些操作，而在F＃中则无法执行。

最后但并非最不重要的一点是，F＃社区的规模和质量都令人失望。Web上的许多F＃信息要么用于旧版本，要么根本不是很好-要么太惯用，性能差或完全错误。然后有人为新闻通讯收取巨额资金，而这些新闻通讯基本上只是现有的信息摘要。

我自己将C＃用于工作项目，将F＃用于我自己的东西。不幸的是，尽管我很喜欢F＃，但很难预测事情何时/如何崩溃。

主要问题始终是可维护性。

我很想用Scheme编写代码，但是下一个维护者可能想要追捕我并折磨我。

我要说的是，您要做的第一件事就是询问您的团队成员对引入F＃的感觉。如果他们喜欢这个主意，那么一切都会比不喜欢的要顺利得多。