1

私は仕事中のプロジェクトの合間にかなり長い間F#を調べてきましたが、どのプロジェクトでも実際に使い始める勇気がありませんでした。通常、.net を使用する場合 は C# にフォールバックします。

現在、自動化されたユーザー管理アプリケーション、基本的にデータベースと Active Directory 間の CRUD を計画しています。データ処理がはるかにうまく機能し、GUI の多くはなく、バックグラウンドでのログ インターフェイスのみを使用すると信じているため、F# を使用したいと考えています。

私の質問は、この時点で、F# の予備知識を持っている人が、このようなプロジェクトのためにこの言語をフルスロットルにするようアドバイスしてくれるかどうかです。言語自体を使用する方がよいかどうかを尋ねているのではなく、そのまま使用する方がよいか、またはあちこちにいくつかのスクリプトをプラグインするだけでよいかを尋ねています。または、特に Scala の用語を持っていて、F# で可能なさまざまな方法でいくつかの数学関数のみを記述した人にとって、F# がこのようなプロジェクトに適していない場合。このプロジェクトにも締め切りがあります。

すぐに実際のプロジェクトでその言語を使い始めなければ、決してそうはならないのではないかと心配しています。

4

2 に答える 2

3

実際、私の最初の (プロとしての) F# コード ビットには、Active Directory へのクエリと、その結果の SQL Server データベースへの詰め込みが含まれていました。とてもうまくいったので、がんばってください！

私が覚えているいくつかの楽しい点：

  • 生の LDAP 結果を ... に投影する F# レコード タイプをいくつか作成しました。レコード タイプのパターン マッチングは役に立ちました。
  • ?LDAP の結果のプロパティにあまり厳密でない方法でアクセスするための動的演算子の実装を実装しました。
  • SQL Server の一括コピー ADO.NET 機能を使用して、大量の LDAP をデータベースに効率的に挿入しました。F# を使用すると、未加工の ADO.NET API の醜さの一部を隠した、クリーンで簡単な抽象化を作成できました。
  • これらのバックエンド F# ビットは、C# ベースの APS.NET MVC プロジェクト (主にボタンを押してアクションを実行するため) によって消費されるスタンドアロン プロジェクトに実装しました。C# との相互運用性は非常に優れていました (思い出すと、より C# に適した API を公開する必要がありましたが、シンプルで簡単でした)。
  • F# はチャンピオンのように .NET API と相互運用するため、ldap API に問題はありません。
  • F# は楽しく、欠陥密度を減らします!
于 2013-08-08T14:21:21.813 に答える
1

私自身、F# の深い知識を持っていない人でもコードが非常に保守しやすいように見えるので、ぜひ試してみます。

ただし、私は F# が大好きなので、私の意見は少し偏っているかもしれません。しかし、F# の知識がまったくない私の C# 開発者チームに職場で F# を紹介する機会がありました。

私たちはいくつかのコーディング道場から始めました。簡単な言語の紹介の後、チームは C# でこれまで以上に多くのユニット テストを作成し、コーディング カタを完成させることができました。F# は初めてでしたが。そして、これは現在、過去 4 つのコーディング道場で一貫して行われています。

また、ビルド スクリプトを F# で書き直しました。以前は powershell スクリプトを使用していました。これにより、古いビルド スクリプトの複雑さをはるかに超えることができました。そして、限られた知識しか持っていなくても、チームはコードが非常に保守しやすいと感じていることは事実です。

実際、これは非常に成功した取り組みであり、現在、いくつかの重要なコア コンポーネントを F# で作成することを真剣に考えています。

于 2013-08-08T09:22:46.843 に答える