.NETツール Sergey Shkredov（JetBrains）、Pavel Avsenin、Alexander Zakharov（DevExpress）へのインタビュー

一部の開発者は一目でプログラムします。 他の人は盲目で、耳/触覚によるプログラムです。 一部の同志にとっては、マーカーとボードで十分です。 それでも、ほとんどの.NET開発者は、コーディングとデバッグにVisual Studio、プロファイラー、デコンパイラ、VCS用のプラグイン、ブラウザツール、R＃\ CodeRush、データベースコントロール用ツール、バグトラッカー、ビルドシステム、コーヒーマシンを使用します。

リストされた開発ツールのいくつかの開発者と話をすることができました。

カットシーンの下で-退屈で完全に面白くない広告、Roslynのビット、Riderのビット、CodeRushの最小値、C＃7.0の機能の簡単な説明、.NETの展望の簡単な概要、かつて言及されたPVS-Studio。

JetBrainsの代表者は、 Sergey serjic Shkredov でした 。ReSharperの多くの機能の著者であり、システムプログラミングの支持者であり、JetBrainsの。

-こんにちは、セルゲイ。 IDEから始めましょう。 現在、.NETの世界は熱狂しています：.NETの新しいバージョン、スタジオの新しいバージョンがリリースされ、Riderは最初のユーザーを見つけました。 状況が少し落ち着くのはいつですか？

-こんにちは。 うまくいけば止まらない。 私たちは、急速に変化する世界に住んでいます。 そして、私の意見では、現在.NETにはもっと多くの順序があります。 MSは、モバイル開発部門、クラウド部門、WinPhone部門、デスクトップ部門など、すべてのMS開発スタックに対応するプラットフォームとして開発しています。すべてがプラットフォームの開発に関心を持っています。 現在、開発は合理化されているように感じられます。個々のチームの影響は減少しており、.NETは全体として開発されています。

-各プラットフォームには独自の制限があり、すべてに共通の.NETフレームワークは削減されますか？

「ちょうど反対。」 .NET Standardと統合するために、各プラットフォームは独自のAPIを開発し、それらを拡張します。 ライブモノに驚いただけで、.Net Coreに取って代わると思いました。 一方、Monoは.NET Standardとともに進化しており、希望を抱かせています。

-ハブ上のさまざまなIDEの議論から判断すると、IDEの主な特徴は、作業速度、消費される最小メモリ/ CPU、プロジェクトの読み込み速度、および一連の機能です。 もっと重要なことはありますか？

-もちろん。 パフォーマンスが重要です。 IDEはUIをブロックするのではなく、すばやくロードし、プロジェクトをロードする必要があります。 3頭のクジラ、3つの性能基準。

しかし同時に、各IDEは特定の技術スタックをサポートしています。 つまり、通常は同じ技術スタックで、典型的なビジネス上の問題を解決する開発者がいます。 したがって、IDEの主なタスクは、このスタックでの作業を容易にすることです。 たとえば、Riderでは現在、クロスプラットフォームモバイル開発とASP.NETに重点を置いています。

-最も人気のある目的地を選択しましたか？

-含む。 人気に加えて、これらのスタックはMSにそれほど成長していません。 多くのオープンソースユーティリティ、ツール。 SharePointまたはOffice開発者を連れて行く場合-VSなしでは、何もすることはほとんど不可能です。 ところで、Unityについて言及するのを忘れていました。 聴衆はかなり多いが、彼女のニーズは、私たちがWebやモバイル開発で見ているものとは異なる。 コードはそれほど多くなく、IDEの利点はわずかに目立ちます。

-ゲームエンジンを使用しますか？

-いいえ、スクリプトのみ。 大まかに言うと、Unityはグラフィックエンジンとスクリプトの2つの部分で構成されています。 Unity Studioのグ​​ラフィックで動作し、スクリプトはMonoDevelopまたはVSで記述されています。 スクリプトの操作を支援します。

-以前は、R＃は.NET framework 3.5に限定されていました。 この制限は現在有効ですか？

-いいえ、2010年以前のVSバージョンはサポートしていません。ユーザー数が少なすぎるため、VS 2010には4.0が必要です。 間もなく4.5が必要になります。 .NET 4.6.2が欲しいのですが、すべてのユーザーがインストールするわけではありません...したがって、今後数年間で何も変わりません。

-ツールは、クラウドでますます頻繁に上昇します。 サーバー、監視システム、TFSがVSTSに変わりました...クラウドベースのIDEがありますか？

-これまでのところ、開発者はデスクトップに座ったほうが良いです。少なくとも、クラウドに移行する動機はありません。 ミニIDEがローカルチェックアウトなしの迅速な修正に役立つ場合を除きます。 はい、ビルドファームはクラウドに移行します。 ビルドキューで頻繁に動けなくなる場合は、ビルドエージェントプールに複数のマシンをすばやく追加できると便利です。 この場合も、考慮する必要があります。 計算によると、独自のサーバーをインストールする方が安価です。

-TeamCityをお持ちですか？

-はい、社内インフラストラクチャはすべてTeamCityにあります。 OSSプロジェクトの場合、TeamCityパブリックインストールも使用します。

-Roslynアナライザーに関する質問。 最も単純な作業アナライザーは数時間で作成されますが、通常は最も単純な例にとどまりません。 そして、これは優れた仕様として役立つ既成のソリューションの存在下にあります。 これらのアナライザーの問題は何ですか？

-それらを書くことは簡単ですが、著者の動機は何ですか？ アナライザーはクールなおもちゃです。 R＃SDKを使用する前に、同じ効果を達成できた可能性があります。 おそらく、Roslynアナライザーの唯一の利点は、BuildプロセスおよびIDEとの良好な統合です。 しかし、私たちのように、パブリックAPIには大きな問題があります。 言語は変化しているため、新しい言語構成のためにアナライザも追加する必要があります。

オープンソースは通常、完全に完成したフレームワーク、または完成したツールを作成するためのいくつかの複雑なフレームワークに参加します。 アナライザーを使用した複雑なプロジェクトを思い付くのは困難です。実際、こうしたプロジェクトの価値はアナライザーの数とともに蓄積されます。 ただし、それらの多くは非常に似ています。 その結果、真面目な製品を入手するには、ほぼ同じ100個の機能をカットする必要があります。 系統的に、退屈なコードを1つずつ書くために-この動機はどこから来るのでしょうか？ さらに、初めてアナライザーを正しく記述することは難しく、ライフサイクルはかなり長くなります。 つまり、まれなバグに対する15のリクエストを受け取って、アナライザーを作成してリリースします。 かなり難しいレッスン。

-つまり、純粋に金銭的な意図でそのようなことを行う価値はありますか？ 最も簡単な動機は？

「誰かがそれを取ると期待していた。」 ここでは、PVS-Studioが採用しています。 アナライザーの後ろでアナライザーを見ました。

-そして、アナライザーのパフォーマンスはどうですか？

-彼はたくさん苦しんでいます。 たとえば、インターフェイスを操作するには、1ダースのシナリオをすばやく分析できるインデックスを作成する必要があります。そうしないと、1ダースの再計算が行われます。 これをオープンソースにカットした場合-誰かがそのようなインデックスを作成する必要があり、トップ10の開発者は何らかの方法でインデックスに接続する必要があります。 通信の問題が原因でも、非常に困難です。

-開発者はツールにますます依存しています。 言語自体（およびいくつかのプラットフォーム）を知ることに加えて、VCS、デバッガー、プロファイラー、リフレクター、リファクタリング用のさまざまなツール、テストフレームワーク（または複数）、プロジェクト管理システム、ブラウザーの開発ツール、さらには.NET言語は常に進化しています。 私たちは、ツールとstackoverflowにますます依存しています。 言語やライブラリではなく、ユーティリティやプラグインの知識によってプログラマのクラスが決定される時が来るでしょうか？

-はい、言語とアルゴリズムの知識は減価しています。 ツールがより便利になり、作業の一部が引き受けられます。 古き良きWinFormsを思い出してください：要素を作成し、EventHandlerを取得し、処理のためのメソッドを記述し、モデルを変更し、回答を取得し、いくつかのコンポーネントを変更し、すべてを検証する必要がありました。 最近ReactでKotlinについて書いたが、UIについてはほとんど考えなかった。 モデルを変更し、再描画するように与え、フレームワーク自体がすべての変更を取得しました。 まったく異なるアプローチ。 近い将来、プログラマーはフレームワーク、ファッショナブルなテクノロジーを知り、移植可能なスケーラブルなコードを書く方法を理解する必要があると思います。 アルゴリズムとデータ構造は過去のものです。

-これは.NETの世界にのみ適用されますか？ システムプログラマーの反対は非常に感情的だと思います。

-もちろん、コンパイラと高負荷のソリューションの開発者は残ります。 しかし、現在ではますます多くの人々がStackOverflowを使用してプログラミングを行っており、それに満足しています。

-開発は簡単になりましたか？

-特定のフレームワークがどのように姿を消したかを理解する必要がなくなりました。 より正確には、フレームワークは非常に高速に表示されるため、学習する時間がないため、作成者を信頼する必要があります。

-セルゲイ、チームツール（ハブ、TeamCity、Upsourse、YouTrack）について教えてください。 セットはVSTSとアトラシアンスタックにどれくらい近いですか？ 今後何を期待しますか？

-必要なコンポーネントをコンパイルしました：YouTrack-バグトラッカー、TeamCity-CIサーバー、およびコードレビュー用のアップソース。 同時に、競合他社と競争することは難しく、当社の製品は散在しています。 ハブ製品では、ユーザー管理を編成しましたが、残りの統合はワゴンです。

「どのように修正しますか？」

-これまでのところ、計画のみ、公的声明はありません。 しかし、私たちは人々がチームで働いていることを理解しており、IDEがチームについてもっと知りたいと思っています。 つまり、あなたはスタジオに行き、サーバーに接続しました-そしてあなたのIDEはあなたのプロジェクト、タスク、バグなどについてすでに知っています。

-ライダー。 一年前、あなたはスタジオを降りるつもりはなかった、1月にあなたのIDEを発表した。 私たちは彼女に何を期待できますか（スピードと利便性以外）？ プラグイン？ あらゆるものとの統合？ Team Toolsスタックとの統合ですか？

-私たちはまだスタジオから降りていません。 R＃とプロファイラーの主な機能はスタジオで動作します（そしてRiderでシェービングします）。 Riderに関しては、すでに重要なユーザーベースを集めています。 スタジオを開かずに何ヶ月もRiderに座っている人がいます（私はその中にいます）。 現在、最新のビルドへのリンクを初期のプライベートEAPユーザーに送信していますが、先日、パブリックEAPを開く予定です。つまり、Riderはサイトから直接すべてのユーザーにダウンロードできます。 これは私たちにとって重要なステップです。ユーザーの数は桁違いに増えました。 現在、ビルド/デバッグがあらゆるプロジェクトで機能し、あらゆるシステムで存続できるように、安定性を達成するために多くの努力を行っています。

コード処理とUIを分離すると、非常に機敏で応答性の高いIDEが得られました。 また、拡張性にも取り組み、プラグインはフロントエンドとバックエンドの両方に書き込むことができます。 現在、プラグインの互換性を判断できるアナライザーを見ています。

-ビルドにはどのビルドシステムが使用されますか？

-Widows上のMsBuildは、MacおよびLinuxでXBuildを使用できます（お勧めしませんが、同時にすべてのユーザーがクロスプラットフォームのMsBuildに切り替えたわけではないことを理解しています）。 ビルドシステムに関しては、MSをどこにも残していません。

-つまり、スタジオからの移行中にビルドエラーは発生しませんか？

-まさに。 概して、移行はありません。同じスタジオ.slnを開いて作業を続けます。

-秋にリリースする予定でした。 うまくいきますか？

-悲しいかな。 来年の初めにリリースする予定です。 製品は支払われます、そして、我々はお金を請求することを恥じたくありません。

---

別のメーカーであるDevExpressは、ペアプログラミングの支持者から宣伝されました。

パベル・パブセニン・アヴセニン

Flashブーム時代にソーシャルメディアアプリケーションの開発に脱出した.NET開発者。 4年前、彼は戻り、CodeRushチームで新しい変数の美しい名前を選択するのを手伝っています。 特に春には、さまざまなヘッダーファイルを検討する大ファンです。

アレクサンダー・アレキサンドル・ザハロフ

彼は幼少期にコンピューターとプログラミングに興味を持ちました。 ZX Spectrum、BASIC、Pascal、C、C ++、Javaを通過し、最終的にC＃および.NETに落ち着きました。

現在、DevExpressでCodeRushを開発しています。

-こんにちは。 現在、.NETの世界は熱狂しています。新しいバージョンの.NET、新しいバージョンのスタジオです。 DevExpressでは、ほとんどすべての製品がこれらのコンポーネントの少なくとも1つに関連付けられていますが、MSに追いつくのはどれくらい難しいでしょうか？

-はい、MSは.Net Core、Xamarinを開発しており、Standardをリリースしています。 テクノロジーは発展しています-それは生きていることを意味します。 サポートに関しては、独自のアプローチがあります。テクノロジーの存在は最初から順守されていますが、安定化を経て初めて真剣に取り組んでいます。 見て、試して、ビルドを作成しますが、公開しません。 そのため、.NET Coreを監視し、リリースのリリースまでアクティブなアクションを実行しませんでした。 そのため、RCと比較したすべての変更は影響しませんでした。 「発射されていない」製品のサポートに努力を費やしていないことに加えて、待機中に顧客からのリクエストが蓄積されるのを待ちます。これにより、優先順位を上げることができます。

失敗は私たちに起こりますが。 たとえば、私たちはまだ生まれたSilverlightのサポートに多くのリソースを費やしました。

最近、作業が簡単になりました。多くのものがオープンソースにあり、アーリーアクセスがあります。 変更への対応が容易になったため、それらについてはすぐに学習します。

-競合他社はあなた次第で何かを作成することがあります。 彼らの製品はどの程度役立ちますか？

-スピードを優先することはありません。目標は品質です。 競合他社の決定を検討し、その成功と失敗を考慮しますが、ユーザーの要求とフィードバックに基づいて戦略を構築しようとしています。

-Roslynアナライザーに関する質問。 最も単純な作業アナライザーは5〜10の夕方に作成されますが、通常は最も単純な例にとどまりません。 そして、これは優れた仕様として役立つ既成のソリューションの存在下にあります。 これらのアナライザーの問題は何ですか？

-まず、このようなアナライザーがあります（パッケージあたり100個）。

第二に、APIはスマートですが、不変ツリーのアプローチはほとんどの開発者にとって珍しいです。

第三に、1つのアナライザーは数時間で実際に作成されますが、通常、人々はそのようなものをすべて必要とします。そのためにはチームが望ましい、できればお金のために製品を書く（これによりプロジェクトが大幅にスピードアップします）。

なぜそのようなコマンドがまだOpenSourceに登場していないのですか？

-MS自体がリファクタリングを開発しています。 誰も彼らと競争したいとは思わない。 さらに、動機付けの問題がハングアップします。本当に大規模で複雑なプロジェクトをサポートする必要があり、OpenSourceでのサポートに頼るのは危険です。 結局のところ、機能の欠如のために小さなプロジェクトを必要とする人はいません。サポートによるリスクの可能性があるため、大きなプロジェクトは必要ありません。

-アナライザーを作成するとき-修正プログラムに場所をスローし、コードの周りを2回目に実行します。 再計算の問題をどのように解決しますか？

-構文で実行する場合、問題はありません。高速です。 セマンティクスが処理される場合、Roslynには独自のキャッシュがあります。 一般に、問題は小さいです。 そして、真空の中で繰り返される計算について話すことは無意味です。 ほとんどの場合、各アナライザーは個別に測定する必要があります。

-DevExpressは、Roslynの寄稿者として言及されました。 プロジェクトはどの程度オープンで、どのように開発されていますか、現在の開発の傾向は何ですか？

-具体的には、CodeRushチームは密輸しませんでした。 アイデアは1つありましたが、既に真剣にカットされていたため、介入しないことにしました。

オープン性に関しては、誰もが素晴らしいものに参加でき、プロジェクトは活発に発展しています。

各スタジオの更新はパフォーマンスのアップグレードであり、APIを開くこともあります。 そのため、3つのプレビューで、賛辞プロバイダーをエクスポートして、メインのIntelliSenseセッションに自動補完を挿入できました。 内部APIがあり、公開されました。 現在、C＃自体はバージョン7までアクティブに動作しています（既に高速になっています）。関数型プログラミングなどの機能が追加されています。 まあ、そしてルーチン：修正、パフォーマンス、研磨API。

-.NET標準2.0を発表しました。 それは同じ標準になりますか、それとも15の既に16の標準に関する画像をダウンロードできますか？

-滝。 .NET Core、Desktop、Xamarin-私たち全員がそこにいます。 それはすべてMSに依存しており、彼らは欲望を持っています、ロードマップはそうです、彼らは仕事を終えます。 一方、以前の試みの経験からわかるように、統合プロセスは複雑で厄介であり、多くのプラットフォームがあります。 ほとんどの場合、いくつかの試行を行う必要があります。

確かに困難があるでしょう。 APIが一般的になり、実装が異なると、ドキュメント化されていない機能が表示され、表示されると、使用され、使用されると、コードは耐えられなくなります。 そして、それは開発者のわだち掘れになりますが、不寛容が現れます。 異なるプラットフォームでのパフォーマンスは異なります。 おそらくいくつかの例外またはNotSupportedPlatform属性が表示されます。

言い換えれば、統一は終了しますが、正確な場合は時間だけがわかります。

-MSはどの標準で停止しますか？ 4.5、4.5、4.5.1？

「彼らは永遠に機能します。」 彼らが何かに取り組むことが有益であるだけでなく、世界が変化しているため、新しい機会が開かれています。 そして、新しい競争相手がいます。

現在、MSはIoTに取り組んでおり、おそらく.NETがコーヒーメーカーに登場するでしょう。 たぶん、ブラウザ用の.NETで撮影されたとTypeScriptヒントがあります。 ネイティブコンパイルの開発が進行中です。 機会-百万。

-メッセンジャーボットのマーケティングの波が始まっています。 管理者/テスター/開発者向けのSkypeアシスタントが待っていますか？

「すでにそのようなことがあります。」 たとえば、ボットはビルドサーバーに接続し、最新のビルドを確認し、赤いビルドがある場合はSlackにメッセージを送信します。 一方、ボットは単なるインターフェイスです。 タスク用のソフトウェアがある場合-ボットにねじ込むことができます。 メッセンジャーでのコマンドの処理に何らかの困難がない限り、インテリジェントなユーティリティが必要になる場合があります。

-DevExpressには強固なツールセットがあり、「方向」が大きく異なります。IDE、グラフィックス、テストフレームワーク、分析ツールへの追加...同時に、それらはまったく異種のように見えます。 そのような多様性を維持するのはどれくらい難しいですか？

-主な方向：異なるプラットフォーム用のコンポーネントの開発。 グラフィックス コンポーネント、WPF、WinForms、JSなどのコントロール 残りは、コンポーネントの概念の一種の開発です。 多様性はありますが、通常はシステムとそれをサポートするチームがあります。 したがって、主な問題はクロスデザイン通信で発生します。

-CodeRushは、一般的なすべてのテストフレームワークをサポートしています。 自分の文章を書きたいという誘惑とどのように戦いますか？

「誘惑との戦いは単純です-誘惑はありません。」 BCLの非公開APIと型の振る舞いを置き換える機能を持つ模擬フレームワークを作成するというアイデアがありましたが、そのアイデアはまだありますが、優先順位は異なります。 nUnit、xUnitがあります-それらを突き合わせる必要はありません、彼らは完璧に仕事をします。 さらに、（バックグラウンドで）継続的なテスト実行のリクエストがありましたが、これらはわずかです。

-オフィス開発ツールで一般的なツールは何ですか？

-CodeRush。 そのようなツールの利点を理解していない人もいますが、原則的には使用していません。 VS。 nUnit、xUnit。 Git、Mercurial。 独自のバグトラッカー、スケジューラーとしてのTrello、プロファイラー-PerViewからdotTraceまで。 そのCIソリューションはCruiseControlに基づいています。 一般的に、動物園は広範です。

-開発者はツールにますます依存しています。 言語やライブラリではなく、ユーティリティやプラグインの知識によってプログラマのクラスが決定される時が来るでしょうか？

-ツールは時間を大幅に節約します。 それらを使用する方法を知らずに自分自身をプログラマーと呼ぶことは可能ですか？大きな質問です。

繰り返しますが、おそらくどこか別の場所で、デザイナーがアーキテクチャを設計し、それをモバイルに提供し、プログラムを作成し、次にテストしている他のモバイルにコードを提供するときに、デザイナー、プログラマー、テスターへの分割に時代錯誤が残っています。 開発者はこれらすべてを自分で行い、開発者の要件は適切です。

-インタビューでは、お気に入りのツールについて尋ねますか？ これは重大な質問ですか？

-重要ではありません。 人が何かを知らない場合：多分彼はそれを使用しなかった、理由がなかった。 学習は重要です。 プログラマーのクラスを定義します。

-正直なところ、関数型言語にはまだ出会っていません。 .NETの更新については、ニュースがちらつくことが多く、F＃はほとんど言及されていません。 言語はまだ開発中ですか？

-単純な理由の1つに言及するだけでは不十分です。必要なものはすべてすでに搭載されています。 バージョンF＃3.0以降、マイナーな外観上の改善のみがあります。 最近、MSはプロジェクトモデルレベル（Workspace API）でRoslynとの統合を試みています。 ところで、F＃への関心は高まっています。 会議、ビデオ、投稿が表示されます。 小さいながらも熱心なコミュニティがあります。

もちろん、スケールはC＃（今のところ）とは比較できません。 数量を比較する場合、F＃開発者ごとに10人のC＃開発者がいます。 機能的なパラダイムのせいで、誰もが快適または理解できるわけではありません。 おそらく、時間の経過とともに、F＃がC＃に追いつくか、C＃に注ぐでしょう。 これは金融の言語ではありません。機械学習はあらゆるものに適した言語です。

-CodeRush for F＃は表示されますか？

-現在、チューニングは貧弱です。VisualF＃Power Toolsがあります-それだけです。 残りはポイントツールです。 F＃のCodeRushについて-すべてはユーザーのリクエストに依存します。 それらはありますが、今のところあまり多くありません。 RoslynWorkspaceApiとの統合後、おそらくタスクが簡単になり、私たちは真剣に考えます。

-トレーニングにCodeRushを使用するのはどれほど現実的ですか？ エラーを強調表示し、修正を提案します。

-バインディング-可能。 Nakosyachil-すぐに立ち往生しました。 丁寧。 トレーニングに関しては、いいえ。 グーグルの間違いを見ている6月。 何、なぜ、なぜそうではない、なぜそうではない。 残りは考えずにリファクタリングしています。 さらに、ツールに多く依存している場合、ある時点で開発を停止します。 なぜ、賢いトゥルザがあなたのためにすべてをするのですか？

-CodeRush。 R＃との根本的な違いは何ですか？ 競争するか、2つのニッチを占有しますか？

-これらは1つのクラスのツールであり、開発者の生産性のツールであり、1つのニッチを占有します。 実際、ほぼ同時に登場しました。 最初のスタジオが登場したとき、MSにはIntelliSenseがありました。 次にCodeRushとR＃が登場しました。

-ほぼ15年の歴史ですか？

-はい。 今、物語は書き直されていますが。 かつて、製品は似ていて、スタジオにしがみつき、速度を落としました。 つまり、以前にスタジオがコードを解析し、CodeRush \ R＃が解析されました。 その後、エディターの側では、コンパイラーへのアクセスが必要でした。MSはCompilerAsServiceを作成しました。外部ユーティリティはコンパイラーにしがみつく機会がありました...要するに、2年前にすべてをRoslynにコピーしました。

-数年前、あなたはロズリンに賭けました（当時はまだ生）。 あなたのベットはプレーしたと思いますか？

-主な目的のパンを手に入れました。二重コード解析（二重計算とメモリ）を回避することができました。 さらに、C＃の新機能を認識できるようになり、処理が簡単になりました。 独自のコード解析アルゴリズムを修正する必要はありません。パーサーとリゾルバーは自動的に取得されます。 ほとんどすべての「ルーチン」は完了しましたが、新しい機能を記述するだけです。 勝利について語るのは難しいです。時間が経てばわかると思います。

CodeRushのバージョンを比較しました（Roslynがある場合とない場合）-RoslynバージョンではRAMが少し増えますが、これは重要ではありません。 つまり、Roslynは本当に多くのメモリを消費しますが、構文ツリーとセマンティックツリーを処理するときにリソースのみを使用する場合、CodeRush自体は何も追加しません。 移行を開始したとき、不変ツリーは多くの疑問を提起しました。 マネージコンパイラは低速であると想定されていました。 しかし、ツリーは複数のスレッドで処理できるため、計算が高速化されることがわかりました。 「生の」Roslynに関しては、そのプロジェクトはすでに数年前に行われていましたが、彼の優秀なスペシャリストチームは次のように書いています。 「ストレンジャー」-多分、しかしそれは修正可能です。 そして、はい、CodeRushの処理を真剣に検討したとき、スタジオはすでにRoslynで本格的に稼働し、非常に安定していました。

-UIとコンパイラーを分離するというアイデアはどうですか（Riderの場合）。

-JBにはIDEを記述するためのプラットフォームがあります。 人気のある、最高の1つ。 適切な専門家がいます。 このような条件はないため、このオプションを真剣に検討しませんでした。 私たちの意見では、.NETとMSは不可分です。 コンパイラのメンテナンスは時間のかかるタスクであり、MSに従うことを決定しました。

---

これらのインタビューを読んで十分ではない場合は、 DotNext 2016 Moscowにアクセスしてください。 会議では、ツールだけでなく、パフォーマンス、マルチスレッドなどについても説明します。

⬝.NET Core：最先端

Hardwareハードウェアを絞ってパフォーマンスジュースを作る

⬝ インテリジェントなチャットボットと認知サービス

⬝ スタックオーバーフロー-パフォーマンスがすべてです！

⬝ 高度なXamarin.Forms

⬝C ++からC＃

arithmetic算術について話し続けます

⬝ASP.NET SignalR：Web開発で本当に重要になっている理由

。.NETの例外的な例外

runtimeランタイムでの.NETコードの変更

⬝ エンドツーエンドJIT

Stackスタックオーバーフロータグのパフォーマンスチューニング

＃C＃スクリプト-これまで考えもしなかった場所でC＃を使用できる理由と方法

⬝ マルチスレッドディープダイブ

Every すべてを集める、またはケーキに会う（C＃Make）

。.NET 開発者向けのWinDbg Superpowers

new新しい.NET Coreおよび.NET Platform Standardの概要

。.NET プラットフォームで見つかった脆弱性と、アプリケーションでそれらを繰り返さない方法

C C＃7の新機能

⬝ETW- いつでもどこでも何でも監視