F＃を大規模なコードベースとエンジニアリングチームに導入する際の現実的な落とし穴[非公開]

私は、大規模な既存のコードベース（すべてC＃）と大規模なエンジニアリングチームを持つソフトウェア会社のCTOです。コードの特定の部分を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があり、F＃を含む仕事もおそらく注目を集めます。

私が検討していない他の落とし穴はありますか？

実際には、人々が犯す主な間違いは、F＃が仕事にとって不適切なツールである問題に対してF＃の使用を強制しようとすることです。

または、私が言及した落とし穴に反論したい人はいますか？

それらはすべて明らかにある程度有効な懸念事項ですが、私はどの程度疑問視します。

たとえば、F＃コードで作業するには誰もがF＃を学ぶ必要があると言います。本当ですが、これは実際には大したことではありません。F＃の学習は、WPF、Silverlight、またはTPLの学習ほど重要ではありません。現在、ロンドンのクライアントでF＃を使用する方法を約30人の開発者に教えており、数十人がフルタイムでF＃コードの作業を行っており、最初の製品（予定どおり、予算内で！ ）数か月後にほぼ完全にF＃で記述されています。実際、Silverlightの技術的な問題はF＃よりも多く、Silverlightの技術サポートはF＃よりもはるかに悪いことがわかりました。

使用可能なF＃プログラマーの比較的小さなプールを参照しますが、F＃を簡単に選択できることを考えると、これは大きな懸念事項ではないと思います。もしあれば、多くを雇う必要があるとは思わない。私のクライアントには、100人以上のプログラマーのために2人のF＃がいます。私たちの仕事は、F＃の使用をシードし、監督することです。

最後の懸念事項は、コミュニティサポートの削減、C＃ソリューションのGoogling対F＃およびサードパーティツールのサポートです。繰り返しますが、これらは実際には問題があるとは思いません。F＃の測定単位に関するコメントをfsbugsに電子メールで送信し、24時間以内に、それが発明された研究者から、私の解釈が間違っていた理由とそれが機能する理由の詳細な説明を含む応答を得ました。Anders Hejlsbergからそれを得たことはありません;-)。私は常にソリューションをGoogleで探しており、C＃、VB、さらにはIronPythonで書かれていることを発見しましたが、F＃業界を使用して3年間で、ソリューションをF＃に翻訳するのが簡単ではなかった単一の事例しか思い出せません。実際、最近、データシリアライザーのC＃サンプルをMSDNからF＃に変換したところ、5倍短くなりました。最後に、NUnitなどのツールでのF＃サポートについて言及しましたが、しばらくの間、F＃からNUnitを問題なく使用しています。これらは.NETツールであり、C＃ツールではありません。

ケーススタディ：私の現在のクライアントは、ユニットテストにNUnitを使用しているだけでなく、BDDのSpecFlowに対する技術的に優れた代替手段として、NUnitの上にF＃でTickSpecを構築しています。著者は、TickSpecはSpecFlowのサイズのごく一部であり、より多くの機能を提供することを私に示すことを指摘しました。さらに、F＃+ TickSpecを使用すると問題の解決が容易になるため、F＃の経験がなく（また、関数型プログラミングの経験もない）作業中の開発者の一部がそれを拾い上げ、関係のないプロジェクトで問題なく使用し始めました。問題。

FWIW、私は私のクライアントにF＃.NET Journalの無料サイトサブスクリプションを提供しました。

HTH！

最初の点で認識しているように、F＃を知らないプログラマーは、コードベースのF＃部分で作業することはできません。ただし、コードベース全体をF＃で書き直す必要はありません。それを使用して利点を得るには、最大のメリットが得られる部分を書き直してください。F＃がC＃と非常にうまく相互運用できるという事実は、特定のパーツを切り分けて、それらからF＃アセンブリを作成することを比較的容易にするはずです。

エンジニアが従来の3層アプリケーションで作業している場合、おそらくSQL、HTML、Javascript、CSSなどの深い知識が必要であると主張することはないでしょう。アプリケーションのさまざまな部分に。したがって、アプリケーションの一部に新しい言語を追加することは、ハードルが大きすぎるとは思わない。さらに、コーディング標準やその他のプラクティスを使用して、F＃の深い知識のないエンジニアでもF＃コードが読めるようにすることができます。

使用する言語にF＃を追加する際の落とし穴には、新しいテクノロジを導入する際の落とし穴が含まれます。メリットに関係なく、チームの一部が学習することを望んでいないか、学習するのに十分な柔軟性がない場合、チームはF＃プロジェクトに取り組むことができません。それにもかかわらず、チームの恐竜が新しいテクノロジーの採用を妨げた場合、会社は運命にあります。

私が個人的に経験した唯一の落とし穴は次のとおりです。

1. デバッグ時の問題。ステートメントベースの言語用に設計されたデバッガーで式ベースのプログラムの実行フローを追跡するのは難しい場合があります。

2. イライラするインテリセンス。オートコンプリートは、必要なときに機能しなくなります。マイクロソフトは、バックグラウンドパーサーのフォールトトレランスを強化する必要があります。

3. インデントに依存する構文により、コードのコピーアンドペーストまたは再フォーマットが困難になります。

4. リファクタリングの欠如。

5. F＃の既存の便利なVS拡張機能（コードの折りたたみ、深みのある色付け）のいくつかは少し遅いため、タイピングが少しイライラします。

私の意見では、これらの問題はどれも目を引くものではありません。ツールは、言語よりも改善および修正が簡単です。

F＃で書くことができる新しいプログラマーを雇うのは難しいというあなたの恐れは非常に一般的ですが、私の意見では不当です。コーディングガイドラインを作成する場合、C＃の次の機能を禁止または禁止yield returnしますasyncか？

これらの機能がより良いコードの記述に役立つと思われる場合は、F＃を控える理由はありません。この言語は、これらの機能をスムーズかつ熟考された方法でサポートしますが、C＃はそのレガシーのため実際には実行できません。

あなたのチームが、私が言及した機能の背後にある概念を理解するのに十分賢いなら、彼らはF＃の優秀なプログラマーになるために必要なすべてを持っています。将来の新兵についても同じことが言えます。C＃1.0以降に導入された機能を使用できない、または使用したくない人を雇いますか？

私はこの正確な状況を考えました。

これが私のチームの計画です。

• C＃とF＃を混在させます。これは、コードベースの大部分でC＃を使用して実行できます。大量のデータ処理が必要な場合は、関連する関数をF＃で記述し、dll内に配置するか、参照します。ここの例

• 上記の方法で既存のコードベースをゆっくりとリファクタリングします。

• すべてのコードが機能している必要はありません。

• 週末にチームにLISPのHaskell の基本を学んでもらいます。

• オイラープロジェクトのパズルを解こうとすることで、F＃を習得させます（F＃を学んでいたとき、それは多くの助けになりました）。繰り返しになりますが、これは週末の間、または「トレーニング」のために日を取っておきたい場合は勤務時間中に行われるべきです。

1）関数型言語を学習すると、プログラマーとしての全体的な能力が向上しますが、これは学習と改善を望む人にのみ適用されます。すべてのプログラマーが良くなることを望んでいるわけでも、作業環境の変更を望んでいるわけでもありません（チームを知っています）

2）これについて議論することはできません。新しい言語の6か月の学習曲線に料金を支払う必要がありますが、既に.netライブラリを知っていると、新しいライブラリを学習するのに必要な余分な年数がなくなります。

3）コミュニティサポートにはC＃よりも小さいものの、非常にスキルの高いアクティブなF＃開発者がWebに投稿しています。ほとんどの言語サポートはライブラリサポートであり、.NETの優れたサポートがあることを忘れないでください。

ここの千ポンドのゴリラはリスク管理です。「私は最先端を行くことはできますが、最先端を行くことはできません。」私は、F＃は最先端ではないと主張します。VS2010と共にリリースされ、Microsoftによって直接サポートされています。最前線は「ベータ版」であり、Microsoftが何に対しても責任を負わないことについて何かを言っているという免責条項です。

実際問題として、IntelliSenseのサポートは非​​常に不足しています。型推論の生産性の向上は、C＃で利用できるそれほど洗練されていないオートコンプリートによって凌pointされます。

また、誤った型推論によって引き起こされるエラーメッセージは、C＃などの言語よりも型注釈を提供する傾向が少ないため、初心者（および多くの場合、私のような中間ユーザー）の修正に時間がかかります。

OOPはF＃でも驚くほど不足しています。たとえば、ネストされたタイプ/クラスのサポートはありません。コードを移植するときは注意する必要があります。悲しいことに、F＃ではできないことをC＃でできることがいくつかあるからです。

最後になりましたが、F＃コミュニティのサイズと質の両方は、失望の種です。Web上にあるF＃の情報の多くは、古いバージョンのものであるか、単にあまり良くないものです（非正統的、パフォーマンスの低下、または不正確な結果）。それから、ほとんどが既存の情報ダイジェストだけであるニュースレターに莫大なお金を請求する人々がいます。

私自身は作業プロジェクトにC＃を使用し、自分のものにはF＃を使用しています。私はF＃が大好きなのと同じくらい、残念ながら、物事がどのように/いつバラバラになるかを予測するのは少し難しいです。

主な問題は常に保守性です。

私はSchemeでコーディングしたいのですが、次のメンテナーはおそらく私を追い詰めて拷問したいと思うでしょう。

最初にやらなければならないことは、チームメンバーにF＃の導入についてどのように感じているかを尋ねることです。彼らがそのアイデアを好めば、もしそうでなければ、すべてがよりスムーズに進みます。