「1、2年後、.NET Coreはエンタープライズソリューション市場でJavaに取って代わります」-Googleジョンスキートインタビュー

確かに、ジョンスキートが誰であるかを知っています： Stack Overflowで第1 位、C＃in Depthの著者、最高の.NETブックの1つ、Google開発者、14x MVP。 この規模の開発者はそれほど多くありません。それらをすべてリストするには2つの注文で十分です。 5月19〜20日に、ジョンはサンクトペテルブルクに到着し、 DotNext 2017 Piterで演奏します。



私はジョンと話をして、彼に.NET、.NET Coreの運命、C＃7の革新、そして2017年の平均的な開発者の一般的な開発レベルについて多くのことをインタビューしました。







具体的には、次の問題について説明しました。

• .NET開発の一般的な方向性とMicrosoftエラー。
• 近い将来、.NET Coreに期待すること。
• 古い.NET Frameworkがある場合、.NET Coreに移行する必要があります。
• クロスプラットフォームの分野における.NETの問題と勝利。
• エンタープライズソリューション市場におけるJavaと.NET。
• C＃7でタプルとパターンマッチングが優れている理由と、別の方法で行うべきこと。
• 小さくても素晴らしい機能C＃7;
• 開発者コミュニティの劣化（および劣化かどうか）;
• バグを診断し、SOに関する適切な質問をするための適切なアプローチ。
• 新しい言語とプラットフォームの学習ガイド。
• 基本タイプの問題：数字、テキスト、日付と時刻。

インタビューは非常に大規模であることが判明しましたが、1分ごとに費やす価値があるように思えます。

プラットフォームとしての.NETの開発について

「あいさつ、ジョン、簡単な質問から始めましょう。」 最近、.NET CoreとASP.NET Coreは非常に迅速に開発され、絶えず変化しています。 開発者として、プラットフォームは適切なコースを取っていると思いますか？



-この質問は2つの異なる側面に関係していると思います。 1つ目はプラットフォームの開発の方向であり、2つ目はこの方向を検索するプロセスです。Microsoftは.NETに関連するすべての点ではるかにオープンになっています。 今ではほとんどすべてがオープンソースになっており、それは素晴らしいことです。 一方、これには多くの変更が必要です。たとえば、意思決定プロセスなどです。 project.jsonプロジェクトやKVMなどの中間ステップを観察します。 「古い」マイクロソフトの時代には、ソフトウェアを開発する従来の企業の方法では、これは起こりませんでした。おそらく、現在の形式の.NETツールをすぐに見ていたでしょう。 はい、コミュニティには完全な混乱があり、個人的にはあまり理解していませんでしたが、時間が経つにつれて状況は明らかになりました。 今週、.NET標準ライブラリとは何か、そして状況は改善しつつあるということについて、スタックオーバーフローに関する質問をしました。



しかし、私の意見では、コミュニティとして、私たちは、起こっていることを計画し、見、影響を与えるという形でのオープンプラットフォームの利点には、1つの欠点が伴うことを理解する必要があります：これらの変更がロールバックすると、時間を失うことになります。 どうやら、これはほとんどの場合に適しており、オープンであることは有益ですが、.NETコミュニティにとっては、これは一種の文化的ショックです。



これをすべて念頭に置いて、いくつかの言い方に注意するしかありません...簡単に理解できるコミュニケーションの不発：何かの根本的に新しいバージョンを作成するときに間違いを犯しやすいです。 もちろん、リリース日を選択したり、準備状況を決定したりするバージョン番号付けにはまだエラーがありました。 一般に、すべてが私たちが望むほどスムーズに進みませんでしたが、それは怖くはありません。結局、誰も完璧ではなく、私たちはコミュニティとしてそれを受け入れなければなりません。 見れば見るほど、より多くの欠陥に気づきます。 これは、プラットフォームの開発プロセスに適用されます。



動きの方向について話せば、NET、ここで私は非常に、非常に楽観的です。 プラットフォームとしての.NETの積極的な開発、モバイルプラットフォームへの拡張、Xamarinがストーリー全体にどのように適合するかを見るのは素晴らしいことです。 これらはすべて複雑ですが、刺激的であり、言語やツールでも大きな進歩がありました。 私の意見では、全体的な状況は素晴らしいです。 私にとって、GCPをC＃開発者にとって素晴らしい環境にしようとして、GoogleでGoogle Cloud Platformに取り組んでいる間、これはまだ起こっています。そしてもちろん、.NET Coreはこの重要な部分です。



最近、Google Cloud Next 2017カンファレンスで、マネージャーと私は、App Engineフレキシブル環境とコンテナーの両方でGCP上で実行されるASP.NET Coreアプリケーションの可能性について議論しました。 そして、これはほんの数年前にばかげていると考えられるものの一つです。 私たちの側で作業を行う必要がありました（Googleには、VSから両方の環境に直接展開できるVisual Studioの拡張機能があります）が、これはMicrosoftが.NET Coreで行ったことなしでは意味がありません。 正直なところ、誰にとっても勝利の状況があるように思えます。



-現在、MS Azureの直接の競争相手であるGoogle Cloud Platformに参加していることを正しく理解できますか？



-それだけです、GCPはMS AzureおよびAmazon AWSと競合します。 一般に、プラットフォームの「ガッツ」の開発には直接関与していません。 Cloud Spanner、BigQuery、Datastore、またはさまざまな機械学習APIなど、同僚が作成する素晴らしいものはすべて素晴らしいですが、C＃開発者がそれを使用できない場合は機能しません。 そこで、私はブリッジを作成しています。プロセス全体を簡素化するために、自動生成されたクラスライブラリといくつかの新しい種類のコードジェネレータがあります。 そして、そこに小さな手書きコードを接着剤またはラッパーとして追加して、すべてを可能な限りシームレスでエレガントにします。



多くの場合、自動生成されたコードを見ると、あまり良くないので、それが生成されていることを理解できます。 私の仕事の一部は、コード生成を可能な限り自然に見せることです。 いくつかのリソースのリストを取得する必要があり、最後にリモートプロシージャへの呼び出しに対して20の答えを取得する必要があると想像してください。それらを反復するだけで、このような状況がシームレスに解決され、そのようなコードを書くことを確認します-小さい最後の仕上げ。全体的な写真は完全に異なって見えます。



-つまり、あなたの仕事は、実際には、自動生成されたコードをチューリングテストに合格させることですか？ :)



「母、それは素晴らしいことだ！」 私たちはこれに近いとは思いませんが、彼は別のテストに合格します。コードジェネレーターを使用すると、気まぐれに従属していると感じるか、彼があなたのために働いていると感じます。 私たちのケースでは、開発者がプロ​​セスを制御していると確信しています。



-.NETプラットフォームに戻る：.NET開発者が近い将来に予想する最も野心的な変更は何ですか？ これから何年も先を行くのは難しいですが、おそらく今後数か月間の期待を共有してください。



「すべてはあなたがどこにいるかに依存します。」 プロジェクトがproject.jsonの時代に停滞している場合、または「すべてについて気にしなかったので、私はまだVS2013を使用しています」、つまり最新リリースに追いつくものです。 VS2017が登場し、.NET Core SDKが登場し、すべてがリリースされ、ベータ版ではなくなりました。これが何を意味するのかを理解することを皆さんにお願いします。 はい、時間がかかりますが、ドキュメントは引き続き積極的に改善されています。 しかし、これは現在の状況に追いつくためにたどらなければならない道についてです。



そして未来について言えば、私たちを待っている次のグローバルなものは.NET Standard 2.0です。 既に.NET Standard 1.0、1.2、1.3などがありました。 -これは、ポータブルクラスライブラリに関するクロスプラットフォーム開発を促進する最初の試みではありません。 しかし、.NET Standard 2.0は、.NETデスクトップで使用していたよりもはるかに多くのプラットフォームにまたがる勇敢な新しい世界です。 .NET 4.5専用に作成されたクラスライブラリを使用できるようにする非常にスマートなツールがあります。作成者はもうサポートしていませんが、.NET Standard 2.0で実行しても害はありません。 さらに、ツールキットはますます低レベルになっていると思います。 主なことは、WPFとWinFormsを使用していないことを確認することです。すべてが正常に動作し、そのようなライブラリは.NET Standard 2.0のコンテキストで使用できます。



まさにこのような開発方法が約束されており、現在の.NET Core SDKは単に良いだけでなく、本当に良いものであり、以前と比較して大きな前進です。 そして、マイクロソフトはそこで止まらないと思います。 したがって、ユーザーアプリケーションを作成しない場合（明らかにUIは重要であり、多くはプラットフォームに依存します）、. NETが.NETであり、クロスプラットフォームを最大限に活用しているという事実に頼ることができます。 Xamarin for AndroidおよびiOSからの展開のコンテキストでこれが意味することはまだ明確ではありませんが、どのように機能するかを見るのは非常に興味深いでしょう。



「すでに安定しているため、誰でもできるだけ早く.NET Coreの最新バージョンにアップグレードすることをお勧めします。」 そして、古代の.NET 4.0レガシープロジェクトをどうするか？



-この場合、.NET Coreにアップグレードする必要はありません。 古いSDKで.NET Coreを使用し、 project.jsonを使用する場合、できるだけ早く新しいツールキットに移行する価値があります。 急ぐ必要はありませんが、ロードマップに追加する価値があります。



また、.NET 4でのみ動作するレガシーアプリケーションのみを使用している場合...すべては特定のケースに依存します：長期的な将来がある場合は、.NET Coreへの更新に時間をかけることが理にかなっています。 TargetFrameworkが.NET 4.0であり、疑わしいライブラリを使用しない場合、ほとんどの場合、.NET Coreに移植するだけで、展開環境の選択肢が大幅に拡大していることがわかります。



既にWindows Serverで多数のサービスを実行しており、Linuxコンテナーについて多くの良いことを聞いているとしましょう（Winコンテナーがあることは知っていますが、Linuxの場合、選択の幅ははるかに広いです）。 それらを.NET Coreに移植する場合（ASP.NETアプリケーションがあると仮定すると、ASP.NET Coreは少し異なります）、チューニングとプラットフォームの選択幅が改善されます。 継続的インテグレーションに関して言えば、WindowsでサポートされていないTravisを使用できます。「ねえ、これは問題ではありません。通常のCIの一部としてTravisでテストを実行できます。」 これらすべてが人生をより良くします。



もちろん、これはすべての人に当てはまるわけではありません。 大きな変更が期待されておらず、理想的には近い将来に置き換えられる古いアプリケーションがある場合、すべての移植作業は無意味です。 しかし、私たちはプロジェクトが実稼働する時間と、変更の数を過小評価する傾向があると思います。 「何もありません、ここで終わります。古いVSなどに基づいてビルドをビルドします。最終的には、このような変更はありません」 時代遅れの環境での展開に年々費やして、このような20の変更を行う必要があると、ようやく「以前に試してみて、より現代的なものに進むべきだ」という考えにたどり着きます。

クロスプラットフォームの.NETとサーバーのエンタープライズ市場の競争

-なるほど。 クロスプラットフォームの.NETについてはまだ疑問があります。多くのプラットフォームをサポートするのは良い考えだと本当に思いますか？ 巨大なインフラストラクチャがあることは既に述べましたが、.NETはクロスプラットフォームエンタープライズおよびバックエンドカテゴリでJavaと競合できますか？



-絶対に！ これは、.NETにとって良いアイデアではなく、.NETにとって必要なアイデアだと思います。 サードパーティのあまりサポートされていない環境をサポートするWindows専用プラットフォームの形での.NETの運命は、人々が仕事以上に苦しんでいるニッチなプラットフォームであるとは考えられません。 したがって、それは必要な仕事であり、多くの可能性を解き放つだけでなく、.NETが数年で陳腐化することも許しませんでした。 クロスプラットフォーム以外のサーバーソリューションは苦労すると思います。 Linuxのみを使用していた環境や、Windows環境を「劣悪な従兄弟」として扱っていた環境でも同じことがわかります。Windowsは、RubyとPythonのサポートを導入しました。 Gitでも同じです。はい、Bash（Shell）でさえWindowsになりました。 マルチプラットフォームは今や「生活賃金」だと思います。



-なるほど。 私はホリバリアンの質問をせずにはいられません：Javaと比較した.NETについてどう思いますか？ 特にエンタープライズ市場では、私が理解しているように、Azureとエンタープライズインフラストラクチャに関するMicrosoftの取り組みを見ており、これはターゲット企業の1つです。



-.NETは間違いなくJavaと競合でき、正直なところ、私は常にC＃で開発することを好みます。 言語自体がはるかに優れているからです。



それにも関わらず、Javaには一定の利点があります。オープンソースライブラリが（優れているという事実ではありませんが）はるかに多く、問題を解決するためのオプションが多くあります。 Webサービスフレームワークを選択した場合、Javaでは少なくとも30のオプションがあり、.NETではおそらく5です。しかし、いずれにしても、そのうちの1つだけを使用するため、Javaの場合は、および.NETには少なくとも1つの優れたオプションがあり、さまざまなJavaが役立ちますが、同時に混乱を招く可能性があります。 そして、支配的なプレーヤーがいない場合、多様性は良い解決策を見つけるプロセスを複雑にします。 したがって、適切な実装を備えたフレームワークを見つけたいだけの場合、これは.NET側でほとんど利点になります。



さらに、慣性があります。 世界中にエンタープライズJavaプログラマーとアプリケーションがたくさんあることを知っています。多くの人が「この動作するJavaアプリケーションを使って.NET用に書き直そう」と言うことはないと思います。 むしろ、次のようになります。「アプリケーションを任意の方法で書き換えることができるため、いくつかのプラットフォームから選択する必要があります。」 新しいアプリケーションを作成する場合、Webアプリケーション、サービス、またはそのようなものは関係ありません。この場合、Javaと.NETは真っ向からやり直すべきだと思います。 企業はその価値が証明されるまであと1、2年は.NET Coreに注意するだろうと思いますが、その後、企業での使用が増加し、C＃の利点が感じられるはずです。



-はい、わかりました、ありがとう。 ここでは開発者向けのJVM言語については触れません。なぜなら、私たちはholivarのためにここにいないからです。しかし、もう1つ質問があります。.NET上のLinuxのアプリケーションまたはサービスの開発で実際の経験がありますか？



-一般に、純粋な形でアプリケーションを開発するわけではありませんが、最近、Google Cloud Next 2017で、マネージャーとともに、ASP.NET Coreに非常に小さなWebアプリケーションを実装し、AppEngineFlexible Environmentのコンテナーに展開しました。 そのような規模で-はい、経験があります。 野田タイムのWebサイトもASP.NET Coreで構築され、現在はWindowsに展開されていますが、Linuxに移植したいと考えています。すぐに動作しない理由はまったくありません。



そして、私の経験では、.NET Core for Linuxは、それだけを使用している限り、非常に優れています。 私が問題を見つけた場所はビルドスクリプトにありました：今朝だけLinuxボックスにVS Codeをインストールしました。NodaTimeを使用すると、netcoreappおよびnetstandardバージョンでは問題ありませんでしたが、.NET 4.5のコードをビルドしようとしました。 1それは言った：「ねえ、私は.NET 4.5.1が何であるかわからない」-それでビルドの参照アセンブリへのリンクをいくつか取りました。 だから、あなたが絶対にクロスプラットフォームであり、.NET Coreのみに焦点を当てている場合、私はすべてがうまくいくと思いますが、いくつかの部分がクロスプラットフォームであり、他の部分が完全な。になります。 MSがそれに取り組んでいると確信しており、参照アセンブリを特定の場所にインストールすることで状況を修正できましたが、LinuxでWindowsコードを実行したくありません。クロスプラットフォームコードが必要です。 そして、私が言ったように、この部分は特に良いです。

C＃7について一言

-C＃について話す。 C＃7バージョンは既にリリースされており、VS 2017で利用可能です。タプルクラス、パターンマッチング、その他の機能があります。 開発者として、このリリースと新しいチップについてどう思いますか？ それらは広く使用されますか？ または、他のガジェットを取得する言語を好むでしょうか？



-私はC＃7に非常に満足しています。今では、 「C＃in Depth」の第4版でそれについて書いています。 現在、タプルについて書いています。タプルは、シンプルに見えますが、隠れた小さなものがたくさんあります。 当初、タプルには警戒していましたが、今では実装での利点がわかります。 私が今確信していないのは、パブリックAPIを作成してタプルを出すかどうかです。 このソリューションは、言語開発者を、カプセル化されていない軽量の戻り値型に制限します。 一方、特定のクラスを返す場合、これは時間の経過とともに改善される可能性があります。



タプルは、怠け者の開発者にとって大きな助けになります。 特定のクラス、または変数をグループ化する軽量な方法としてタプルを使用するライブラリー内でも、すべてがクールでなければなりません。



あなたが言及した別の重要な機能はパターンマッチングです。 そして、C＃7でのパターンマッチングで最も価値のあることは、取得したパターンではなく、パターンの概念の導入です。 私はこれらの概念を意識的に共有しています。 現時点では、「is」演算子およびスイッチケースでパターンを使用できます。 私たちが現在持っている唯一のパターンは、等価性と型の一致です。 したがって、「case x is 5」を設定し、値が5の場合に一致するか、タイプ「x is String」で一致を検索できます。 以前のタイプマッチングは好ましくありませんでしたが、実際には非常に有用であることが判明しました。



友人のビル・ワグナーからの野田タイムでの最初のC＃7 プルリクエストを既に受け入れました。このプルリクエストは、パターンマッチングの利点を具体例と明確に示しています。 しかし実際には、これはF＃とHaskellから学んだ教訓を示しており、さまざまな状況での動作を介して関数を記述することができます。これはif-else-if-else-if-elseと比較して非常に明確な記述パスです。 「このケースはこの結果に対応し、これはこれに対応する」と言うとき、本質的にif-elseと同じことを行いますが、理解するのははるかに簡単です。 これはすべて有望に見えます。C＃7.1のようないくつかの中間リリースでは、値の分解など、より多くのパターンが見られることを期待しています。



この状況を想像してください。 DateTimeがあり、それを分解して、パターンマッチングで年が2016年を超えるケースを見つけることができますC＃6で同様のことができますが、マッチング検索では分解を使用しません。 したがって、パターンマッチングは将来さらに多くの機能を提供できます。 これらはC＃7の最大の機能であり、過小評価すべきではありません。



ほとんどのASP.NET Coreユーザーにとってのもう1つの大きな利点は、非同期/待機の平坦性にあります。以前に非同期メソッドがTask、Task、またはvoidのみを返すことができた場合、特定のパターンに一致するものを返すことができます（ただし、これはパターンマッチング！）、このタイプの値を作成していないかどうかを示す属性がある場合は、このファクトリを使用します。 多くの人がこのパターンをコードで使用するとは思わないが、他の人の実装を使用できる。 そして、ValueTask-Taskのより軽いバージョン-はほぼ全員が使用します。これはASP.NET Coreチームがさまざまな方法で最適化した構造であり、非同期のすべての利点を取得したいがロードしない場合の応答時間が短い状況で特に役立ちます不要なTaskオブジェクトを処理するGC。 私の意見では、これは多くの人が「独自の戻り値型を実装する方法」の詳細に入らずに使用する興味深い機能です。



機能のリストだけを見ると、C＃は、主要な革新に加えて、ref-localやref-returnのような小さなものも取得します。これらは理解するのが非常に困難です（少なくとも私にとって）。 GCなどのパフォーマンスの特定の側面に非常に敏感な高性能ゲームのUnity開発者にとって非常に役立つと信じています-他の開発者よりも構造体を使用するという感覚があります。



out変数のようないくつかの素晴らしい改善もあります。変数を出力パラメーターの引数として使用すると同時に変数を宣言できるため、宣言する必要はありません。

int x;
if (int.TryParse("some text", out x))
{
// ...
}

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

if (int.TryParse("some text", out int x))



, . , C#: , - - , , , . out- , .



, . , , : async-, , , , iterator-, , , , , FooImpl, . FooImpl . , , , .

— , .NET, . #1 Stack Overflow — . , ?



— , . : Stack Overflow , . , — , , , . , , , . , , : « , , , , ». , , , , , . C# 7 .



, , , . … : ( ), . : « , , », — , : « , ?». , , . , , . , . , , .



- , NUnit Noda Time, - Linux , Windows. , en-uk, NUnit, , String.EndsWith()



assert.EndsWith()



, NUnit , . , . :

1. ,
2. — , - ?
3. ,
4. ,
5. Noda Time, , NUnit
6. NUnit , NUnit- «, String.EndsWith()
   
   
   
   , , , »
7. 10 , String.EndsWith()
   
   
   
   
8. , Linux , Windows
9. SO, , : Windows UK English Linux
10. US English, Linux.

, , .



, , , — . , . , , , : « . Android Java, SQLite. », — , Java, Android SQLite? . , , ? , , . , « », « » — , - .



— ? , ? ?



— -, , — , , . «# », . , , , , . , , /. , .



, . JavaScript , Node.js - . C#, Java, Ruby, Python , , . - - — . , . — , , 5 , , , .



, , , , . , . : «, , , ». -, : , , iOS-, . , iOS , , .



, , , . , , : « Strings Strings» — , . - , , , . , . . , - . « , , , ». , , — . .

— , . , DotNext «Back to Basics» , : , . - ?



— : , , /. , , , - Unicode . 65536 , , Basic Multilingual Plane. planes, « , , - , BMP», -BMP BMP. - ! 10 BMP, , , -BMP .



: , 10 , ? BMP «e» , , , . emoji: Java .NET, String.Length()



, . , ? : , , . , .



, , . , , - .NET: Noda Time, . , 2.0. , , , . , JavaScript , Date JS , . JavaScript API , .



, , , , : « 5 10 0, 0.5», — , .

— , , . , , — , ?



— , :



1. , Noda Time, - . DateTime.Now() - , , . Noda Time.



2. , , . DocFX, Sandcastle, , . . , , , - Stack Overflow, , , : « , ?» , .



3. . , , , — , . , , … . , . , , , .



, — , , 2,5 . - «Everyday sexism», , . , , , .

---

phillennium DreamWalker . !