私たちはセルゲイと話しました：
- 最新のReSharerリリース
- サブスクリプションとライセンスの新しいスキームについて。
- マイクロソフトとの難しい関係について。
- ランタイムおよび言語開発について。
- ロズリンの出口が状況をどのように変えたか。
- 製品を改善するためにユーザーのフィードバックに協力する。
- 他の.NETスタック製品の開発計画。
- 業界内コミュニケーションと経験の交換の重要性。
- C ++用の製品の開発について。
- ReSharper C ++について少し。これはMicrosoft開発者でさえも夢中になるはずです。
- ユーザーが変化をどのように感じるか。
- ReSharperがさらに発展する方法。
ビデオはこちら
カットの下-インタビューのテキスト版。
新しいReSharerおよびUpdate Rateリリースについて
-セルゲイ、あなたは最近大きなリリースを2つも持っていました。
-はい。
-新しいReSharperの新機能について少し教えてください。 だから、非常に短い。 そして、実際には、なぜリリースが2つしかなかったのですか？
-昨年、3つのメジャーリリースを作成しました。これらはReSharper 9.1、9.2、10.0です。 そして今年は、4か月ごとにリリースを行い、すべてのリリースで機能を隠さずに、できるだけ早くすべてをリリースするという、私たち自身のペースを取りました。 これは、Visual Studioの進化に適しています。常に新しいイベントが発生します。 この観点から、リリース10.0はリリース9.2と機能の数に大きな違いはありませんでした。 唯一のことは、このリリースに厳しい制限があったことです。すべての製品のリリースとともに、すべてのIDEのライセンスシステムを変更したため、リリース日はこのリリースのかなり前に修正されました。 実際、リリース日が固定されているため、2つがリリースされました。
-つまり、それはバグ修正でしたか？
-はい、10.0の2週間後にリリースされたバグ修正リリース。
-多くのバグを修正しましたか？
-たくさん、約100。 基本的に、もちろん、ユーザーはユニットテストとUWPアプリケーションの低解像度について不満を言いました。
-さて、ユーザーは落ち着きましたか？ 大丈夫ですか？
-はい、はい。 実際、彼らがTwitterで書いたものを見るのではなく、更新レート（新しいバージョンに切り替えた人の割合）で見ると、ReSharper 9の2倍です。つまり、最初の3週間でReSharper 10は、1年前よりもさらに多くの人々を倍増させました。
-そして、あなたは多くの人が古いバージョンを使用していると思いますか？
「私はそうは思わない。」 つまり、次のバージョンがリリースされるまでに、最後から2番目のバージョンが約30％使用され、70％の人々がすでに新しいバージョンを使用しています。 そして、次の最新バージョンに移行する準備ができています。
—つまり、現在、ReSharper 8を使用している人は30％いますか？
-はい。
-なるほど。 どういうわけか彼らと通信しようとしましたか、なぜ彼らは行きたくないのか理解していますか？
-これはそのような開発者の活動の正規分布だと思います。 そして、これはいくつかの内部的な製品の理由とはほとんど関係ありません。
サブスクリプションとライセンスのcなスキームについて
-古いライセンス-期限内でしたか、それともバージョン上でしたか？ そのライセンスを持っていれば、無料でアップグレードできますか？
-約2、3年前のどこかで、サブスクリプションの販売を開始しました。これにより、年間を通じて任意のバージョンに更新できました。 あなたが購入し、あなたは私たちがそれらをどのように呼ぶかに関係なく、年間を通してリリースするすべてのバージョンを持っています。 したがって、バージョン管理を廃止しました。これにより、メジャーバージョンで十分なアップグレードレートが得られないことを恐れることなく、より頻繁なリリースを発行できるようになりました。 商用ユーザーの場合、更新のサブスクリプションなしの永久ライセンスがまだありました。 現在、そのようなライセンスはすでになくなっています。 もちろん、新しいサブスクリプションスキームについてコメントできます。
-はい、教えてください。 すべてが再び変わったので、これについて多くのことを書いて話しました。 最後に何が起こったかを簡単に要約できます。 これは私たちの視聴者にとっておかしくないことだと思います。
-IDEは、市場とともに、テクノロジーとともに、ユーザーとともに開発される製品です。 1つの大きな雪崩で発生します。 もちろん、企業として、すべてのユーザーが製品の最新バージョンを使用できるようにしたいと考えており、ライセンスがこのパスを制限するものであってはなりません。
したがって、これを理解したとき、サブスクリプションを導入しました。 サブスクリプションは誰にとっても良いものですが、サブスクリプションは自分で購入しなければならないものです。 つまり、永久ライセンスとそのサブスクリプションを自分で購入します。 私たちはすぐにこれに来ませんでした。 実際に、1年分のサブスクリプション料金と永久ライセンス料金を分割します。
サブスクリプションスキームの最初のバージョンはこれでした。1年間ライセンスを購入すると、1年後にすべてが取得されます。 そしてもちろん、私たちはこれについて多くの否定的なフィードバックに会いました。 これは、マーケティング担当者、CEOにとって大きなメリットだと思います。このフィードバックの中で、この状況でユーザーが何を興奮させているのかを正確に理解できたからです。 また、ユーザーは、製品を引き続き使用できるという保証がないことを懸念しています。
たとえば、米国議会などによって予算が承認されているかどうかを明示的に記載した会社がありました。 そして、もし彼がバージョンを更新するための予算を承認しなければ、私たちは来年のために製品なしで放置されるでしょう。 これは、永久ライセンスが残されるべきであるということを理解するのに役立った最も明らかな物語です。
今、あなたは私たちから1年間のサブスクリプションを購入しています。 今年中に、更新する内容を決定できます。 このサブスクリプションを更新して、1年後に更新して使用し、支払います。 したがって、バージョンを購入するときは、次のバージョンに更新する可能性なしに、ある時点でそれを購入します。 しかし、今年中にリリースされるバージョンのアップデートを延期して購入することができます。
-購入しない場合はどうなりますか？
-1年以内に購入したバージョンを使用する必要があります。
—つまり、購入時に最新であったバージョンへのロールバックはありますか？
-はい。 これをロールバックと見なすことも、1年の間に「新しいものが欲しい」と判断したという事実と見なすこともできます。 この場合、サブスクリプションを更新するときに1年で支払います。
-聞いてください、このスキームはどういうわけか簡単ではありません。 誰かからそれを取りましたか、それとも自分で考え出しましたか？ 市場にいる他の誰かがこの原則で働いていますか？
-アドビ。 しかし、もちろん話はもっと簡単です。 私たちはユーザーの声をよく聞きます。そのため、私たちの決定が時々難しくなることがあります。
-さて、まあ、かなりユニークな話があります。
「さらに多くの例を挙げることができます。」 2日前、Microsoftは同じスキームに切り替えました。
-面白い。
「まったく同じ。」 そして、このテーマについては、インターネット上に単一の大きな投稿はありませんでした。
-どうしたの？ なぜあなたの場合には議論があったのですか？
-私たちは、より多くのコミュニティと協力する会社です。 また、オプションで商用ユーザーおよびオプションでパーソナライザーにサブスクリプションを導入した場合でも、多くのフィードバックを受け取りました。
-それで、あなたの製品管理はフィードバックに基づいていると言えますか？
-はい、大部分。
マイクロソフトとの困難な関係について
-そして、マイクロソフトとの一般的な関係は何ですか？ 私自身はJavaの世界の人であり、すでに10年前の長い間、プラットフォームは多かれ少なかれオープンになっています。 JetBrainsのメンバーと話をしたところ、原則として、Javaプラットフォーム自体の内部で何が起こっているのかをよく知っており、いつでも複雑なコードを確認したり、どこかにパッチを当てたりすることができます。
-ベンダーと通信する必要はありません。
-まさに。 そして、あなたの.NETの世界では、これはどのように起こりますか？
「私たちの作業方法、リリースの計画方法は、過去数年で大きく変わりました。」 そして、マイクロソフトがエコシステムに対する姿勢を変え、パートナーと協力し、会社の開放性のレベルに変わったという事実のために変化しました。 3年前、状況は次のとおりでした。パートナーのみに発行されたVisual Studioのプライベートビルドがありました。マイクロソフトと緊密に連絡を取ったアフィリエイトプログラムがありました。 優先度の高いバグをVisual Studioに提出する権利がありました。
つまり、MicrosoftはVisual Studioの拡張機能の厳選されたメーカー、約100〜200社を意図的にサポートしており、そのためにあらゆる種類のプライベートプログラムがありました。 現在、ほとんどのフィードバック、ほとんどの変更とビルドは、オープンソースを介して完全に合法的に入手でき、私たちが連絡するほとんどのチームはオープンソースで開発されています。 現在、Visual Studioは、フィードバックを提供したり、何かを変えたり、何か新しいことを学ぶためにMicrosoftをノックする必要のあるクローズド製品になりつつあります。
「自分で多くのことを始めたことがわかりましたか？」
-Visual Studio Industry Partner（VSIP）プログラムは、私たちにとってある種の大きなメリットではなくなったと言えます。 チームとチャットできるイベントに行きますが、これはほとんどVSIPプログラムからのリクエストです。
「なぜ彼らはアプローチを大きく変えたのですか、あなたはどう思いますか？」
-彼らは開発者を失い始めました。 Microsoftは長い間、すべてのシナリオのすべてのニーズをカバーする開発者ツールを導入したベンダーでした。 モバイルプラットフォームの出現により、すべてが変わりました。 Microsoftのツールキットでは、Microsoftのお客様がAndroid用、iOS用のプログラムを作成するのに十分ではありませんでした。 これが、このシフトを引き起こした最初の理由です。
おそらく、オープン性に影響を与えた2番目の要因は、おそらくAzureです。 .NETだけでなく、Java、Python、PHP、Ruby-すべての開発者をクラウドにできるだけ多くの開発者をドラッグするには、それらにツールを導入する必要があります。 明確なポリシーがあります-開発者向けのツールMicrosoftは現在シェアウェアを提供しています。 無料ではない場合（Visual Studioなど）がありますが、無料ではない場合（Visual Studio Enterpriseなど）もあります。 6,000ドルは1年前に価値があったので14,000ドルではありませんが。
-1年前、ルーブルは異なっていました。 しかし、1年前に新しいCEOがマイクロソフトに到着したことが状況に影響したとしましょう。
-彼は多くの影響を与えたと思います。この意味で彼は継続し、開発者向けのツールをよりオープンにしました。 そして、マイクロソフトはクラウドプロバイダーであり、この地位を強化するという事実に向かって進みます。 マイクロソフトのツールに基づいたエコシステム、すべてのプラットフォームの開発のエコシステムを開発する。
-クロスプラットフォームに関連する非常に興味深い話がまだありました。 Linuxの下にあるMonoがあります。Microsoftのこの場所には、どういうわけか競合するものがあります。 これについて何か知っていますか？
-Monoの場合、これは私が話していたMicrosoftテクノロジースタックの穴とまったく同じであるということです。 物事がそうであるように、クライアントはVisual Studioの3千のライセンスを持ってマイクロソフトに来て、次のように言います。「iOS用のプログラムを書く必要があります。 私はあなたの楽器に10年間座っていますが、どうすればいいのでしょうか？」彼はマイクロソフトのコンサルタントになり、答えを出す必要があります。 したがって、Microsoftには、iOSの開発を提供するというビジネスタスクがあります。
したがって、オプションは何ですか？ 完全に機能するXamarin、Apache Cordova、さまざまなデバイス用のネイティブC ++コンパイルがあります。 このシナリオをカバーするために開発する3つのツールを次に示します。 つまり、クロスプラットフォーム開発は、外部パートナーの助けを借りて穴を塞ぐようなものです。
通常マイクロソフトでは、外部パートナーを使用して最初に穴を塞いでから製品をリリースし、この場所をとるようにしています。 しかし、今ではそのような傾向は見られず、Microsoftはクロスプラットフォーム開発をそれ自体に引き込もうとしているのを見ていません。 彼らが協力の段階にある間。 Monoで書かれたライブラリは、自分自身に引き寄せられます。 コアCLR、仮想マシン、フレームワークの一部の要素...
「これは相互のプロセスですか？」
-はい、これは非常に相互的なプロセスです。 もちろん、ある時点で統一されることを願っています。
—現在、Linuxでの.NET仮想マシンの独自の実装があります。 かなり生でしょ？
-彼女は通常の製品になるチャンスがあります。
-しかし、Microsoftはそれを既製品のエコシステムと呼んでおり、まるで完成品であるかのように、それを利用して使用しています。 どうやら、これは完全に真実ではありませんか？
-ユーザーをその上にドラッグするには、このように配置する必要があります。 Core .NETに基づいた従来のASP.NETからASP.NETへのユーザーの流れは見られません。 まだ準備ができていません。 これは起こると思いますが、今はそうではありません。 現在、コードのドラッグアンドドロップには問題があります。
実際には、DNX、.NET Coreの下でコードをドラッグする方法に重大な問題があります。 それらは、クラシックASP、フル.NETフレームワーク、およびCore CLRの両方で動作するように、ライブラリを対象とすることができるリリースバージョンのフレームワークの欠如と関連しています。 このため、Microsoftには多くのバージョンの.NETがあります。ブラウザーにはSilverlightがあり、Windows Phoneがあり、デスクトップアプリケーションがあり、「完全な」.NET Frameworkがあります。
現在、別のスタックがあります-コアCLR。 そして、原則として、別個の実装として、他のすべての人と違いはありません。 Microsoftには、さまざまなスタックのコードを記述するソリューションがあります。 これらのプラットフォームの組み合わせのバージョンごとに、そのうちの3つまたは2つで動作するコードを生成できるハッキングの一種。
このような組み合わせの数は、おおまかに言って指数関数的に増加しているため、これはあまり有効なシナリオではありません。 現在、マイクロソフトはこの出展者を排除し、ターゲットにできるプラットフォームを作成するために積極的に取り組んでいます。 そのため、この共通プラットフォームをターゲットとするコードはどこでも機能します。 その後、NuGetパッケージの更新バージョンがあり、どこでも使用でき、同じライブラリを使用してすべてのパッケージをコンパイルできます。
「彼らはそれをしますが、明らかにそれほど速くありません。」 え？
-多くの設計ソリューションが目の前で変化しています。 現在のバージョンは、最終的なものではなく、Microsoftはすでに別のバージョンに取り組んでいます。
ランタイムおよび言語開発について
-.NETはレガシーテクノロジーであり、リビングテクノロジーであると思いますか。 ここで私の質問を説明します。 特定の瞬間、おそらく2008年の1年前まで、言語の非常に強力な開発がありました。 ランタイムについては言えません。十分な専門知識がありません。 ランタイムはそれほど高度ではないようです。 しかし、その当時の言語は非常に発達しました。 C Javaは正反対であり、言語は非常に長い間鈍いものであり、Runtimeは激しいペースで開発されてきました。 私の意見では、最近C＃でもグローバルに何も起きていないのは興味深いことです。 変更は以前より目立ちました。 どう思いますか？
-そうです。 ランタイムはJVMにはるかに遅れていると思います。 .NET仮想マシンのガベージコレクターは非常に貧弱で、JITコンパイラーは非常に脆弱です。 その結果、コードの実行が遅くなり、不要な割り当てを回避し、自動的にインライン化されない機能に対処するために、gagにgagを挿入する必要があります。 コードは自動的に適切に最適化されません。 Javaにはこのような問題はありません。
-そして、言語は？
-C＃6のリリース前に、言語があまり開発されなかった期間がありました。新しいRoslynコンパイラへの移行に関連しており、数年遅れました。 感覚によると、2年。
-つまり、言語は3番目または4番目のバージョンを中心に開発されていませんか？
-5番目。 5番目のバージョンがリリースされた後、新しいコンパイラの作成を開始しました。 彼らはそれを長い間苦労して書いた。 基本的に、彼らはすべてのアーキテクチャの改善を前提として、ネイティブコンパイラと同じパフォーマンスを達成しようとしました。
その結果、設定された目標はコンパイルモードで達成されました。 つまり、C＃6とC＃5を使用すると、速度の違いは目立ちません。 残りのビルド手順と比較して、コンパイルに時間がかかりませんでした。
しかし、IDEでのサポートに関しては、大規模な障害があります。 Visual Studio 2015でのC＃6サポートに関しては、これは完全な失敗です。 ReSharperなしで2015リリースのReSharper Visual Studioプロジェクトを編集することはできません。 それはすべての記憶を食いつぶし、ハングし、それだけです。 そのような状況。
-はい、とても面白いです。 特に最初の段階では、最初のビルドを見たときに、おそらく嵐のような感情がありました。 どうやってこれと一緒に暮らしましたか？
-髪の毛が逆立ちしました。
-はい。 ある時点で明らかにすべての主要な問題を修正し、どういうわけかこれで少なくともはっきりと生きることができたのは明らかですか？
-目を閉じて、おおまかに言ってVisual Studio 2015をサポートします。 私たちは自分では使いません。 私たちは彼女にゆっくりと移動することを計画していますが、アップデートで改善されました。 ReSharperをカットして、その一部を実行できるようにします。 このすべての使用を開始できるように、より小さなソリューションを作成します。
-IntelliJ IDEAは、ツールとしてそれを認識するという観点から、Core 2 Duoプロセッサの導入直後に2007年に大きな進歩を遂げました。 非常に強力な（Pentium Dと比較して）パフォーマンスの急上昇がありました。 したがって、IntelliJ IDEAは「IDEA slow」の位置から「ああ、IDEAは素晴らしいツールです」に移動しました。 仕事ができるようになりました！」IDEAは、鉄が急激に良くなったという理由だけで、より早く働き始めました。 それで十分でした。 それ以来、人々は特にIDEAのパフォーマンスについて文句を言っていません。 .NETスタックではIDEのパフォーマンスが依然として頭痛の種であることを正しく理解できますか？
-残念ながら、はい。 私たちはかなり難しい状況にあります。 Visual Studioの動作に起因するパフォーマンスバグの約半分と、私たちに起因する後半があります。 非常に多くの場合、一方を他方と区別することはできません。 ReSharperではタイピングが遅いかもしれません。これは、現在バックグラウンドでRoslynがファイルを分析し、1秒あたり数百メガバイトを割り当てるため、なぜGCが停止するのですか？
「コード内にいるかのように」いる場合、MicrosoftはIntelliSenseでの入力がバックグラウンドコードアナライザーとどのように相互作用するかを考慮した特別な最適化を行いました。 したがって、オートコンプリートおよびタイプアシストアクティビティを起動するとき、Roslynバックグラウンドスレッドの動作に影響はありません。
「彼らは意図的にそうしましたか？」
「彼らは問題を解決していたと思います。」 もちろん、彼らは私たちのことを考えませんでした。 これは自然なことです。
ロズリンによる状況の変化について
-そして、ロズリン出口はどのように状況を変えましたか？ これはあなたにとって頭痛ですか？
-簡単になりました。 実際、Roslynが言語サービスとして使用されているさまざまなタイプのプロジェクトをよりよく理解し始めたということです。 そこからコンパイルに行くコンパイルモデル、ファイル、および参照を引き出します。 Visual Studioの以前のバージョンでは、Roslynが存在しなかったため、ビルドの呼び出しに関連する時間がかかり、Visual Studioから参照を直接取得していました。 バグで困難でした。 これは、はるかに直接的なプロセスです。 Roslynを使用してモジュールを作成し、それらがコンパイラとどのように対話するかを示します。
-そして、Visual Studioはどのようにコンパイラと対話しますか？ スタジオはコンパイラー自体を使用して独自のコードモデルを構築していますか？
-Visual Studio-はい。 処理中にRoslynをダウンロードします。
-そして、古いケースでは？
-古いケースでは、ネイティブC ++コードでのみ同じでした。 彼が何をしていたのか、どこでしか推測できませんでした。 しかし、彼はガベージコレクターに影響を与えませんでした。プロファイラーで彼を見たことはありません。 彼はそこにいたかもしれないが、彼は非常に速かった。
-これは、Roslynがまだ未加工の技術であるという事実によるものですか？ それとも、それが何らかの形で根本的に誤って設計されているという事実によるものですか？
「はい、もちろん。」 とても生。 Roslynで最も単純な名前変更機能のために使用されるデータデザイナーの最適化の観点から、またはソリューション全体でエラーを検出する場合、これらは愚かな働きをする直接的なアルゴリズムです。 しかし、もちろん、最終的にパフォーマンスに影響します。
-つまり、原則として、Microsoft開発者がRoslynを加速する可能性はありますか？
-もちろんチャンスがあります。 しかし、Microsoftには問題があり、そのような必要性は適切なレベルで実現されない可能性があります。 そして、時間は割り当てられず、お金もかかりません。
-なるほど。 そして、現在起こっているオープンソースとは何ですか、「見ることができる」または「コピーすることができる」という点でのみオープンソースですか？
-私は非常に少ない収縮を見ました。 さて、基本的にはCore CLRです。これは表示されているすべてのソースコードであり、コンパイルしたり、表示したり、読んだりできます。 誰もがそれらをまとめて受け入れたとは聞いていません。
-それは、原則として、あなたが来て彼らを助けるチャンス、パフォーマンスに関するすべての問題を修正するチャンス、そして明らかにそう多くはありませんか？
-これらのパフォーマンスの問題は、多くの場合、Roslynを使用したスタジオコンパイルの領域にあります。 もちろん、私たちが来て、Roslynで何かを変えるチャンスがあります。 私たちは何がどのように起こっているかを見て分析します。 アーキテクチャについて、アーキテクチャの問題についてのアイデアを持っています。
ReSharperがさらに発展する方法
「それで、ロズリンは彼自身のモデル、彼自身のツリーを構築していますよね？」 これは、明らかに、コンクリート構文ツリーのようなものです。
-はい。 非常に具体的、スペース付き、コメント付き...特定の構文、エディタで記述されているため。 IDEが使用するのは、ASTではなく、非常に具体的な構文ツリーです。
-あなたはコードモデルを構築しています。 このツリーはありますか？
-はい。
-そして、ロズリンは彼自身を持っています。 どうやら、スタジオはそれを使用しています-これは論理的です。 実際、これとどのように住んでいますか？ これでどのように生き続けますか？
-現在、いくつかの指示があります。 1つ目は、Visual Studioを使用しないことです。 2つ目はVisual Studioを使用することですが、ReSharperを別のプロセスとして実行します。 ReSharperのすべてのコードモデル、すべての構文ツリー、インデックス、キャッシュ、およびセマンティックモデルに関連するすべてが別のプロセスに格納されるというビジョン、設計、ソリューションがあります。
-ReSharperが32ビットVisual Studioのメモリ制限に強く依存していると彼が言ったとき、Kirill Skryganと私はこれについて議論しました。 ReSharperをアウトプロセスで実行することは明らかであると彼に言いました。それに対して、彼はそうだと答えましたが、それはメモリトラフィックに満ちていました。
-実際には、設計ソリューションはこのメモリトラフィックを最小限に抑えることです。 これは次のように機能します。スタジオをUIアプリケーションとして認識することができます。 つまり、 MVVMを実行します。 ReSharperバックエンドは、スタジオであるViewのようなViewModelであると考えることができます。 それらの間のトラフィックを考慮すると、これはUIの変更を表示するのに十分なデータのトラフィックになります。 UIレベルで大量のデータ転送を見つけることはありません。 常に2つの文字、2つのハイライトを使用する必要があります...
すべてはスタジオ側、UI側にあります。 UIを表示するために送信する必要があるデータはほとんどありません。 何千ものオブジェクトを送信します-それは瞬時です。 チッピング中にドキュメントに変更を転送します-即座に。 この考えに基づいて、UIを表示するのに十分なデータのみが同期されるようにコードを構築できます。
-Visual Studioはどれくらいうまく設計されていますか？
-これは専らコードの問題です。つまり、スタジオとの統合は一切変更されません。
「すべてを非常に美しく説明しました。」 しかし、実際には機能しますか？ Visual Studioでは、UIを使用してすべての作業をどこかで行うことができますか？
-これは、UI要素を作成する際の問題です。 例を挙げましょう。 ここでは、たとえば、「bulbs」と表示されます。 これを表示するために、PSI、構文ツリー、ドキュメント、プロジェクトモデル全体が使用されるようになりました。 持っているものを残して、これらの構文ツリー全体を送信する場合、もちろんこれはうまくいきません。 しかし、一般に、「電球」を描くには、アイコン、テキストが必要です。
Alt + Enterを押すと、テキストとアイコンの形でアイテムを渡し、「何らかの電球を適用する」を押すと、アウトプロセスで動作するコマンドをバックエンドに送信しました。 構文ツリーとドキュメントのすべてのデータ変更-それらはすべてアウトプロセスで発生しました。 これで、フロントエンドで、結果として、新しいカーソル位置を返し、エディターで開かれたドキュメントを変更する必要があります。 それだけです。
-タスクは、ReSharperとユーザーがUIで見るものとの間のデータ交換プロトコル、および最小トラフィックを開発することです。
-プロトコルに従って開発を行っています。 プロトコルは非常に興味深く、反応的です。 両側で機能する同じデータ構造を同期します。 これは大きな変更です。ReSharperのソースコード全体を変更する必要があります。
この変更は、ViewModelを書き換えて、セマティックコードモデルへの参照が含まれないようにする必要があることです。 これは大きな変更であるため、徐々に変更する必要があります。 私たちはゆっくりと製品をこのように機能させ始めます。 そして、UIがセマンティックモデルに依存しないという事実にアーキテクチャを導きます。 そして、これも依存関係の逆です。
ユーザーがどのように変化を感じるかについて
-ユーザーにとってどの程度透明になりますか？
-最終的には、同じユーザーエクスペリエンスである必要があります。
-ユーザーは、このストーリー全体でバックエンドが異なると感じてはいけませんか？
— . - . それだけです。
— - , , . , , ?
— . ReSharper , , - — 10%.
— c Visual Studio, , IDE?
— Visual Studio, , , . , , Microsoft. Microsoft. — .
, Visual Studio Microsoft. , , Universal Windows Platform, , , , , … .
ReSharper C++, Microsoft
— Microsoft, , ReSharper?
— . , - , , .
— , Microsoft , ReSharper . , — .
— ReSharper C++ — .
— , , .
— ReSharper ++ 3-4 . . , C++ . , ReSharper C++ — 2/3 ReSharper, ReSharper C++ ReSharper Ultimate.
— , C++ Windows, Visual Studio?
— , Visual Studio ++ .
— Managed ++ ?
— Managed ++ — Microsoft, Managed -Managed .
— ,- - ++, -
— , . header, ++, Managed ++ — . , interop, COM, Implicit PInvoke. Managed C++ — .
, Visual Studio Managed C++, ++ — , , .. — , , C++ .
— , C++ Windows Visual Studio — ?
— . Windows. , Linux, Visual Studio — . .
++
— , ++, CLion — /C++. AppCode Objective-C. ReSharper IDE? - ? IDE?
— . -, C++, - — Microsoft. CLion AppCode . c . -, CLion ReSharper. ReSharper C++ — ReSharper C++ CLion.
, ++ AppCode . Objective C, - , header-, Objective C ++. - define' ++, , , . - ++ , Objective C. ++ AppCode.
CLion AppCode , ?
— , , .
— ?
— . ReSharper ++ , , ++ AppCode. ReSharper ++ , .
— «» ? , , ?
-はい。 , IDE.
— Microsoft C++?
— .
— , .
— # , . , , , , . - , — , , c.
— , — ?
— Use Case. , , , , , , - -, . つまり - .
— ReSharper JetBrains?
— : ReSharper 2007 3 4-. ReSharper , Eclipse. , , : - , IDE Java – .
— , -?
— , .
— JetBrains , Eclipse?
— , .
— ReSharper? , , , C#: , DevExpress CodeRush, Roslyn . , ?
— , DevExpress - , . CodeRush — -: 2000- , ReSharper .
— , . ? ?
— Roslyn , Roslyn. , , . ReSharper Roslyn , Roslyn. , . - , . Visual Studio , , , , . , , . , , , , , , « var». .
— Roslyn. .
— , .
— ?
-いいえ。
— . . Roslyn .
— . , completion' .
— , .
— . Microsoft'. , , . , , , .
. , . . . – Visual Studio.
.NET-
— ReSharper, , .NET- . ?
— , dotTrace. dotTrace , ReSharper ++. - . ReSharper' , UI, , , Application- .. dotTrace , : dotTrace ReSharper.
— , , «», ?
— , , . . . , , . , .NET , , , Solution, . , , , .
dotTrace : ReSharper Extension'a Visual Studio, , Visual Studio, , , package – Visual Studio . , Visual Studio, . ReSharper — , Extension, Visual Studio. Extension . , . , Runtime side-by-side.
, . , , , ReSharper, Command Line Inspect Code Tool ( -), dotPeek, dotTrace, dotCover, dotMemory, — , . , , .
- DotNext , Application-, , . , . . . : « dotCover ReSharper?» ReSharper C++ , ReSharper, ReSharper , .
— ?
— , — dotTrace .
— -.
— - , , . , , . , ReSharper, dotTrace, , . . , , – , … , .
— Performance. ReSharper' , , . , .NETe, , workload, , - . - . ? ?
— . – Profile Visual Studio. , , , ReSharper , , , - . , . , , . … .
, ? Find Usage, , , , - . , . Find Usage 10 , . , , . - , , Code Completion, - , Foreground .
, - - , , , , ReSharper, , – typing, , — , - .
— ?
— . . , , . typing 10- , — .
— , , .
— , . Code Completion', - , -, , , output. .
— , , ? — , , – ?
— , . : , - , , , . , . , , .
— ?
— . , ReSharper, - ReSharper', Visual Studio Visual Studio. -, .
— Microsoft , ReSharper?
— Microsoft , . Microsoft - , . , Microsoft, . , , , Microsoft . .
« » Youtube- , — , .