勇敢な新しいRoslyn：独自のコードアナライザーとC＃スクリプトが必要なのは誰ですか？

.NETの世界ではすべてが順調です。プラットフォームは正しい方向に進んでおり、新しいテクノロジーが足を踏み入れて立ち上がっています。 最近、.NET / ASP.NET Coreについて多くの議論があり、実行中と開発中の両方でコードを操作するための広範な文書化された機能を提供するRoslynを誰もが忘れているようです。





これを修正するために、Filip W、Microsoft MVP、Roslynの寄稿者、およびASP.NETの世界で最も人気のあるブロガーの1人にインタビューしました。 Filipが新しいC＃の変更に気付かないこと、カスタムコードアナライザーを記述すること、そしてC＃でのスクリプトが他のスクリプト言語より優れていることを信じているのはなぜですか？





JUG.ruグループ：フィリップ、ウォームアップから始めましょう。 ASP.NET Coreは大きく変化しています。 プラットフォームで作業する開発者として進行中の変更についてどう思いますか？



Filip W：もちろん、先駆者は多くの問題を経験しました。延期、バージョン管理の問題、名前の変更、ツールキットの問題、一貫性のないプロジェクト管理システムなど、.NET Standardコンセプト自体の変更までです。 もっと良くできますか？ 確かにそうですが、振り返ってみると、すべてが常にシンプルで明確に見えます。



一般的に言えば、変化は間違いなく良くなっています。 ほんの数年前、ASP.NETはWindowsとIISでのみ機能していました。 さらに、System.Web.dllに基づいており、各HTTPリクエストに不合理なオーバーヘッドが追加されました（平均29Kb）。 今日、 ベンチマークによると、ASP.NET CoreはLinux上で最高のパフォーマンスを発揮する3つから5つのWebフレームワークの1つです。 この観点から、プラットフォームは間違いなく信じられないほどの変化を遂げています。



JUG.ruグループ： Linuxで.NETアプリケーションを作成しましたか？ そのような決定の安定性はどうですか？ プラットフォームは実稼働の準備ができていますか？



Filip W：はい、私の新しいプロジェクトの多くは、DebianベースのシステムのDockerでスピンしています。 暗号化などのプラットフォーム固有のコードや、あちこちで発生する奇妙なデッドロックでいくつかの問題に遭遇しましたが、一般的にはすべてが私に合っています。 そしてもちろん、 Docker Swarmを使用してプラットフォーム全体を管理することの利点は印象的です。



実際、どのOSにプロジェクトをデプロイするかに関係なく、クロスプラットフォームの.NETコードを自宅で開発しようとしています。 その結果、ほとんどのプロジェクトにはWindows、macOS、Linux用のビルドエージェントがあります。 したがって、Macで何かを開発し、少なくともDockerで、少なくともAzure Web Appで、すべてが正常に機能することを保証してデプロイできます。



JUG.ruグループ： C＃はどうですか？ バージョン7.0では、タプル、パターンマッチング、その他の多くの機能を使用できます。 これらの革新は、開発者としてあなたにとって有用ですか？



Filip W：一般に、C＃6.0の場合と同様に、変更はマイナーであるため、日々の作業で多くの開発者が新しいバージョンへの移行に気付かない可能性があります。 個人的には、現在の形式ではタプルが非常に不十分に実装されているため、タプルは間違いなく便利です。 開発者がデータベースから1つまたは2つのフィールドを逆シリアル化または読み取るために新しいクラスを作成することを余儀なくされたときに、これが現在直面しているヘルパークラスの数を大幅に減らすのに役立つことを願っています。



パターンマッチングの構文が表現に基づいていないことに少し動揺しています。 代わりに、isとswitchに重点が置かれますが、私は革新が一歩ずつ来る合理性を理解しています。 さらに、表現力豊かな要素は簡潔なコードの記述に役立ち、C＃は非常に「冗長」である可能性があるため、このような変更も良い結果をもたらします。

C＃vs Powershell-1：0

JUG.ruグループ：過去に、 C＃での DotNext スクリプトについて説明しました。 レポートは「立ち止まった」と思いますか？ .NET開発者の間で、C＃のそのようなユースケースは需要がありますか？



Filip W：ああ、信じられないほどの視聴者の反応がありました！ スクリプトは、以前は.NETエコシステムではアクセスできなかった多くの興味深いユーザーケースへのアクセスを可能にするため、Roslynの最もクールな側面の1つであるように思えます。 もちろん、Powershellを使用する前に、C＃でスクリプトを記述する機能は、.NET開発者にどれだけ近いかを考慮して、まったく異なります。 商用プロジェクトでのC＃のスクリプトの使用が急激に増加していることがわかります。スクリプトは、Azure Functions、ゲームの拡張機能などを実装しています。 これに言語サービスとC＃のインテリセンス/デバッグサポートを追加します。これは、VS Codeなどの軽量エディターで取得でき、非常に優れた開発プロセスを実現します。 非スクリプト言語であるC＃が非常に強力な環境になったことは面白いのですが、生産性の観点からスクリプト言語のいずれかが議論することはほとんどありません。



モスクワで約2時間、ディスカッションエリアで、セキュリティ、メモリ管理、アプリケーション拡張機能（スクリプトベースのプラグインシステム）、さらに実行可能プロセスを管理するためのリモートREPLまで、C＃スクリプトの複雑さと使用方法について議論しました。 すごかった！

Roslynのカスタムコード検査の開発

JUG.ruグループ：スクリプトに加えて、静的コード分析にも関与しています。 VSとResharperが市場に出回っている場合、誰が独自のアナライザーを開発する必要があるでしょうか？



Filip W：コードレビューに関与し、チーム内のコードの品質を一般的に担当するチームリーダーには、通常、独自のアナライザーが必要です。 ここで理解することが重要です。開発プロセスでは、プロジェクトのコンテキストにのみ関連する独自の問題と粗さのいくつかに直面しています。 ResharperとVSはどちらも幅広いユーザー向けに設計されたユニバーサルツールですが、企業のガイドラインに一致する特定のパターンまたはコードの使用を確保する必要がある場合はどうでしょうか。 たとえば、クラス/変数の命名規則を設定し、内部APIが意図したとおりにのみ使用されていること、コードが標準に従って文書化されていること、HTTPエンドポイントが確立された標準に従って設計されていることを確認します。 時々奇妙なことも起こります-私はどういうわけか、タブと＃領域ディレクティブの使用がコンパイラレベルで禁止されているプロジェクトで働いていました。



ただし、独自のアナライザーの作成を忘れた場合でも、「内部で」どのように機能するかを理解することが重要です。 プログラミングの他の分野と同様に、たとえあなたの手が独自のアナライザーを作成できなくても、それらの根底にある原則とコンパイラーAPIの動作方法を理解して、コードアナライザーの動作を保証することは非常に役立ちます。







JUG.ruグループ：コンパイラについて言えば、Roslyn Compiler APIを使用すると以前のバージョンよりも作業が楽になりましたか？



Filip W：それはトリックの質問ですか？ 実際、古いコンパイラでは、コードをフィードするだけで、出力でDLL / EXEファイルを取得することしかできませんでした。 私にとって、Roslynで最も重要なことは、パイプラインの各ステップが独自の方法で使用できる外部APIを備えた、実際のサービスとしてのコンパイラであることです。 また、Roslynの前に公式のC＃ASTライブラリがなかったことも驚くべきことです（サードパーティのオプションのみが見つかりました）。



JUG.ruグループ：ところで、下位互換性はどうですか？ Roslynの次のリリースで私のレコーダーが壊れる可能性はありますか？



Filip W：そうですね、Roslynチームが後方互換性に多大な注意を払っていることは確かです。 コンパイラコードを詳しく調べると、この驚くべき例を見つけることができます。 たとえば、コンパイラのソースコードを見ると、「DELIBERATE SPEC VIOLATION」という行があります。 これは何ですか 古いCSCコンパイラのコードは、バグやいくつかの誤解により、いくつかの場所でC＃仕様に違反していることがわかりました。 同時に、Roslynチームは何かを壊すような変更を加えるつもりはなかったので、開発者が意図的にC＃仕様に違反し、それを意図的な仕様違反として文書化したいくつかの場所で、新しいコンパイラを得ました:) Link 。



コンパイラとそのAPIの後方互換性は異なるトピックであることを理解していますが、私の例はチームのメンタリティをよく示しています。 私自身が何かをRoslynに密輸しており、コードレビューの最も退屈な側面の1つは、各「パブリック」APIの分析に払われる注意の量であると言えます。 したがって、正直に言うと、下位互換性については心配しません。



JUG.ruグループ：どのようにしてRoslyn APIの研究を始めたのですか？ 最初に解決したい具体的な問題は何ですか？



Filip W：最初は、スクリプトを使ってRoslynコミュニティに参加しました。10年後にC＃でスクリプトを使ってこのストーリー全体を形作るのに役立ったScripticsプロジェクトをやりました。 次に、OmniSharpプロジェクトに入りました。このプロジェクトでは、emacs、vim、AtomなどのエディターにインテリセンスとC＃言語サービスが追加されます。 もちろん、.NETコミュニティにおけるOmniSharpの最大かつ最も認識可能な「消費者」はVisual Studio Codeです。 そこで、コード分析、リファクタリング、およびIDEレベルの他の多くの言語機能のためのツールの開発を開始しました。



JUG.ruグループ：近い将来、静的コード分析で何が起こるのでしょうか？ 待っている価値がある次の1-3-5年は何ですか？



Filip W：多くの「ライブ」診断が表示されると思います。 私の友人の1人であるJosh Vartyは、Visual Studioに（驚き！） Aliveと呼ばれる最もクールなアドオンを構築しました。ランタイムで発生します。 これはすべて静的またはセマンティックコード分析を超えており、すべてがRoslynに基づいて構築されています。



したがって、一般的には、シンボリック計算を通じてヌルへのリンクを見つけるなど、より高度なアナリストに出会うでしょう。 現時点では、コミュニティはまだRoslynが提供する機会を整理しています。 さらに、RoslynアナライザーがOmniSharpやResharperなどのサードパーティツールに緊密に統合されることを期待しています。 Visual Studio Codeには同様のアナライザーが既に存在しますが、それらの作業は理想とはほど遠いものです。



JUG.ruグループ：ありがとう、フィリップ、DotNextでお会いしましょう！

---

フィリップは、ジョンスキート、サーシャゴールドシュテインおよび他のMVPと同じステージで、サンクトペテルブルクで開催される次回の会議で、 「。NETコンパイラプラットフォーム（Roslyn）を使用したコード分析ツールの構築」に関するプレゼンテーションを行います 。 スピーカーとレポートに関する詳細は、 DotNext 2017 Piter Webサイトで入手できます。



PS早期登録は2月末まで有効であり、これまでのところ登録でき、数千人節約できます。