大規模なコードベースとエンジニアリングチームにF＃を導入する際の実際の落とし穴
私は、大規模な既存のコードベース（すべてC＃）とかなりのエンジニアリングチームを持つソフトウェア会社のCTOです。コードの特定の部分がF＃で作成する方がはるかに簡単で、開発時間が短縮され、バグが少なくなり、並列実装が容易になるなど、基本的にチーム全体の生産性が向上することがわかります。ただし、F＃を導入する際のいくつかの生産性の落とし穴も確認できます。
1）誰もがF＃を学ぶ必要があり、たとえば、JavaからC＃に切り替えるほど簡単ではありません。F＃を学んでいないチームメンバーは、コードベースのF＃部分で作業できなくなります。 。
2）現在（2010年12月）の時点で、採用可能なF＃プログラマーのプールは存在しません。さまざまなソフトウェアエンジニアの履歴書データベースで「F＃」を検索します。履歴書に含まれるキーワードの1％未満です。
3）現在（2010年12月）の時点でのコミュニティサポートは利用できません。 C＃のほとんどすべての問題をググって、F＃ではなく、すでにそれに対処している人を見つけることができます。サードパーティツールのサポート（NUnit、Resharperなど）も大雑把です。
私はこれが少しキャッチ22であることを理解します。つまり、私のような人々がF＃を使用しない場合、コミュニティとツールは決して実現しません。エッジを出血させません。
私が考慮していない他の落とし穴はありますか？それとも誰かが私が言及した落とし穴を反駁したいですか？これは重要な議論であり、業界によるF＃の採用を増やすために多くのことを行う可能性があるこの公開フォーラムでの反論をぜひ聞かせてください。
Scheme、LISP、Haskellなどの他の関数型言語の履歴書を検索します。多くの人が学校でこれらを学び、履歴書に持っています。それらの多くはF＃の学習を気にしないでしょう。放課後は一度も使用したことがありませんが、F＃を使用する仕事でもおそらく私の注意を引くでしょう。
私が考慮していない他の落とし穴はありますか？
実際には、人々が犯すと思う主な間違いは、F＃を仕事に不適切なツールである問題に強制的に使用させようとすることです。
それとも誰かが私が言及した落とし穴を反駁したいですか？
それらはすべて明らかにある程度有効な懸念事項ですが、私はどの程度質問します。
たとえば、F＃コードで作業するには、誰もがF＃を学ぶ必要があると言います。これは事実ですが、実際には大したことではありません。 F＃を学ぶことは、WPF、Silverlight、またはTPLを学ぶことと同じくらい重要です。私は30人の開発者にロンドンのクライアントでF＃を使用する方法を教えており、数ダース後に数十人がF＃コードにフルタイムで取り組んでおり、彼らは最初の製品を出荷しました（予定どおりに予算内で！ ）ほんの数か月でほぼ完全にF＃で記述されました。実際、彼らはSilverlightでF＃よりも技術的な問題が多く、Silverlightの技術サポートはF＃よりもはるかに悪いことがわかりました。
利用可能なF＃プログラマーの比較的小さなプールについて言及しますが、ここでも、F＃を取得するのがいかに簡単であるかを考えると、これは重要な問題ではないと思います。もしあれば、多くを雇う必要があるとは思いません。私のクライアントには、100人を超えるプログラマーのためのF＃担当者が2人いて、私たちの仕事は、F＃の使用をシードし、監視することです。
3番目の最後の懸念事項は、コミュニティサポートの不足、C＃ソリューションのグーグル対F＃およびサードパーティツールのサポートです。繰り返しますが、実際に問題があるとは思いません。私はf＃の測定単位に関するコメントをfsbugsにメールで送信し、24時間以内にそれを発明した研究者から、私の解釈がなぜ間違っているのか、なぜそれが正しく機能するのかについての詳細な説明を受け取りました。 Anders Hejlsbergからそれを得たことはありません;-)。私は常にソリューションを探してC＃、VBまたはIronPythonで書かれているが、F＃業界を使用して3年で、ソリューションをF＃に変換した単一のインスタンスのみを思い出すことができるささいなことではありません。実際、最近、データシリアライザーのC＃サンプルをMSDNからF＃に変換し、5分の1に短縮しました。最後に、一部の問題なくF＃からNUnitを使用しているときに、NUnitなどのツールでのF＃サポートについて言及しました。これらは.NETツールであり、C＃ツールではありません。
ケーススタディ：私の現在のクライアントはユニットテストにNUnitを使用しているだけでなく、F＃で TickSpec をNUnitの上に構築していますBDDのSpecFlowの技術的に優れた代替品。著者は、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＃プロジェクトで作業することはできません。それにもかかわらず、チームの恐竜に新しいテクノロジーの採用を妨げさせたら、あなたの会社は運命づけられます。
私が個人的に経験した唯一の落とし穴は：
デバッグ時の問題。ステートメントベースの言語用に設計されたデバッガーで式ベースのプログラムを実行するフローをたどるのは注意が必要です。
イライラするインテリセンス。オートコンプリートは、必要なときに正確に機能しなくなります。マイクロソフトは、バックグラウンドパーサーのフォールトトレランスを強化する必要があります。
インデントの影響を受けやすい構文により、コードのコピーアンドペーストや再フォーマットが困難になります。
リファクタリングの欠如。
F＃の既存の便利なVS拡張機能（コードの折りたたみ、深度の色付け）の一部は少し遅いため、タイピングの経験が少しイライラします。
私の意見では、これらの問題はどれもショーストッパーではなく、私は当面はそれらと共存できます。ツールは言語よりも改善と修正が簡単です。
F＃で書くことができる新しいプログラマーを雇うことは難しいだろうというあなたの恐れはかなり一般的ですが、私の意見では不当です。コーディングのガイドラインを作成する場合、C＃の次の機能のいずれかに対してアドバイスまたは禁止しますか：yield return、オブジェクトへのLINQ、ラムダ、次のasync？
これらの機能がより良いコードの記述に役立つと思われる場合は、F＃を控える理由はありません。言語はこれらの機能をスムーズでよく考えられた方法でサポートしますが、C＃はそのレガシーのため実際には実行できません。
私が言及した機能の背後にある概念を理解するのに十分賢いチームであれば、F＃の優れたプログラマーになるために必要なすべてが揃っています。同じことが将来の新入社員にも当てはまります。C＃1.0以降に導入された機能を使用できない、または使用したくない人を雇いますか？
この正確な状況を検討しました。
これは私が私のチームのために計画しているものです：
C＃とF＃を混合します。これは、コードベースの大部分でC＃を使用することで実行できます。重いデータ処理が必要な場合は、関連する関数をF＃で記述してdll内に置くか、参照します。 ここに例
上記の方法で、既存のコードベースをゆっくりとリファクタリングします。
すべてのコードが機能している必要はありません。
チームに、週末にわたってLISPのHaskell、LISPの基本を学ぶ。
オイラープロジェクト パズルを解いて、F＃を学習してもらいます（これは、F＃を学習していたときに非常に役立ちました）。繰り返しになりますが、これは週末の間、または「トレーニング」の日を確保したい場合は勤務時間中に行う必要があります。
実際問題として、IntelliSenseのサポートは非常に欠けています。つまり、型推論の生産性向上は、C＃で利用できるあまり洗練されていないオートコンプリートよりも優先されます。
誤った型推論によって引き起こされるエラーメッセージは、C＃などの言語よりも型注釈を提供する傾向がないため、初心者（および多くの場合、私などの中間ユーザー）の修正にも時間がかかります。
OOPにもF＃の驚くべき方法が欠けています。たとえば、ネストされたタイプ/クラスはサポートされていません。残念ながら、C＃で実行できることにはF＃では実行できないことがいくつかあるので、コードを移植するときは注意が必要です。
最後に大事なことを言いますが、両方のサイズおよび F＃コミュニティの品質は、ちょっと残念です。 WebにあるF＃情報の多くは、古いバージョンの情報であるか、またはあまりよくない-慣用的ではない、パフォーマンスが低い、またはフラットアウトが正しくないかのいずれかです。次に、大部分が既存の情報ダイジェストだけであるニュースレターに巨額の料金を請求する人々がいます。
私自身、作業プロジェクトにはC＃を、自分のものにはF＃を使用しています。私がF＃を愛しているのと同じように、残念ながら、どのように/いつ状況が崩れるかを予測するのは少し難しいです。
1）関数型言語を学習すると、プログラマーとしての全体的な能力が向上しますが、これは学習して改善したい人にのみ適用されます。すべてのプログラマーが上達したいと思っているわけでも、作業環境の変更を望んでいるわけでもありません（チームを知っています）。
2）私はこれについて議論することができません。新しい言語の6か月の学習曲線にお金を払う必要がありますが、.netライブラリーを知っていると、新しいライブラリーの学習に必要な余分な年数がなくなります。
3）コミュニティサポートはC＃よりも小さいですが、非常に多くの非常に熟練したアクティブなF＃開発者がWebに投稿しています。ほとんどの言語サポートがライブラリサポートであり、.NETのサポートが充実していることを忘れないでください。
ここで千ポンドのゴリラはリスク管理です。 「私は最先端を切ることはできますが、最先端を行くことはできません。」私は、F＃がEdgeを出血させているわけではないと主張します。これはVS2010でリリースされ、Microsoftによって直接サポートされています。 Bleeding Edgeは「ベータ版」であり、Microsoftから免責事項が何にも責任を負わないことについて何かを言っています。
主な問題は、常に保守性です。
Schemeでコーディングしたいのですが、次のメンテナはおそらく私を追い詰めて拷問したいと思うでしょう。
最初に行う必要があるのは、F＃の導入についてチームメンバーにどのように感じているかを尋ねることです。アイデアが気に入った場合は、そうでない場合よりもすべてがスムーズになります。