フレームワークを開発する必要がない方法と、特に世界中の何百万人もの開発者があなたに依存している場合、ソフトウェアのライフサイクルが空の言葉ではない理由に関する投稿。 以下は、.NET Coreプラットフォームと密接に関連するフレームワークであるASP.NET Coreを開発するアプローチに対する批判です。

バージョン履歴.NET Core（インターネットのオープンスペースからのジョーク）：

*アルファ

*ベータ

* RC1

* 2RC 2Furious

* RC：東京ドリフト

* RC4：ビッグRC

* 7

* RC8

背景

vNextは、ASP.NETの新世代のコード名です。これは、フレームワークがシリアル番号を取得し、ASP.NET 5（後にASP.NET Core）として知られるようになるまでかなり長い間使用されていました。 その前に、ASP.NET開発が体系的に進められ、主に下位互換性の問題がなければ、新しいバージョンは真の革命になりました。 本質的に、これは新しいフレームワークです。 完全な書き換えの目標の1つは、モジュール性を実現することでした。これにより、とりわけWindowsプラットフォームから.NETを切り離すことができました。 これはその後、LinuxおよびOS Xのサポートに関する一連の有名な発表の機会となりました。

新しいフレームワークは非常に快適であることが判明しました。巨大なSystem.Webは忘却のonに沈み、MVCとWeb APIパーツは1つに統合されました。 さらに、ランタイムとライブラリは小さな部分に分割されました（以前のフルバージョンの.NET Frameworkの500 MBと比較して、すべての依存関係を持つWebアプリケーションの典型的なインストールは50メガバイト未満になりました）。 Linuxサポートは一般的に別の問題です。 クラウドホスティングプロバイダーのサーバーで2回クリックするだけでアプリケーションを起動するDockerの公式イメージは、この.NETプログラマーが夢見ていたものでした。

しかし、すべてがスムーズだったわけではありません。 新しいプラットフォームは、ASP.NETレベルだけでなく、.NET Framework自体も変更されていることが判明しました。 実際、CoreCLRと「古い」.NETバージョン4.xの2つの独立した領域が登場しました。 これらのフレームワーク間での移植は、多くの図書館にとって重要な作業であることが判明しました。その著者は、当然ながら不満を表明し始めました。 しかし、全体として、Microsoftは簡単に降りました-人々は少し騒ぎ、落ち着きました。 想像力の訓練として、Javaのメインバージョンに加えて、互換性のないSuperDuperJavaが出現した場合に流れる血流が想像できます。 .NETの場合、多くの不満もありましたが、開発者は変更に抵抗するよりも新しい機会に喜んでいる傾向がありました。

それが何であれ、事実は.NETが現在Python 2.xおよび3.xで起こったことと同様の状況にあるということです。 さらに、WinRT、Mono、Unity、およびXamarinがありますが、絶対的な互換性も同じです...

リリース候補

あなたが普通の人で、アルファケンタウリシステムの惑星のいずれかから地球に到着していない場合、おそらく、ユニットの後に番号2と3があり、アルファバージョンがベータになり、リリース候補が最終リリースになります。 。

最も流行に敏感なオフィスは、最初のアルファバージョンから新しいASP.NETに書き込みます。 私は個人的に、このフレームワークを使用する2つのチームで働くことができました。 リリーススケジュールに遅れることなく、新しいバージョンがリリースされたときにアプリケーションを更新する場合、それと共存できます。 もちろん、アプリケーションの更新に関する作業は最も興味深いものではありませんが、新しいバージョンの利点は、企業が余裕がある場合には価値があります。

通常の世界では、プロジェクトがリリース候補段階に近づくと、コミュニティは安定性を期待します。 「つまらない」とマイクロソフトは考えていたようです。 最も興味深いのはまだ来ないことが判明しました。 突然、バージョンにRCプレフィックスが追加されたときに、新しいフレームワークの歴史における最大の変更が発生しました。 差し迫った火災の最初の兆候は、project.json、またはむしろ古き良きMSBuildとの置き換えでした。 正直に言うと、この変更自体は災害ではありません。 ただし、project.jsonは「新しい」.NETのフラッグシップでした。 多数の会議のプレゼンテーションを見る-PRマシンはGoの世界の流行に敏感な人たちを魅了しました。 さらに、恐ろしいタイミング-将来のフレームワーク全体のビルドシステムに変更がある場合、どのようにリリース候補を呼び出すことができますか？

もっともっと。 ASP.NET Community Standupは、毎週の開発者が新しいASP.NETとその開発プロセスについて語るYouTubeチャンネルです。 以前は1週間に1回安定していたスタンドアップが、突然1か月間話せなくなりました。 最新の出版物は「日付がありますか？」と呼ばれ、非常に象徴的です。 フレームワークの開発者は、それ以前は、Twitterのアクティブユーザーは慎重になり始め、議論には関与しません。 Twitterの残りの部分はinりに満ちています。 誰もが途方に暮れています。 このプロジェクトを行った人たちは、今では自分が何が起こっているのか知らないようです。 コミュニティの推測から、「大人の男」がやって来て、「十分に遊んだ子供」に屈して、すべてをコントロールしました。

たくさんの馬、人、WebAssemblyが混在

.NETの世界でどのような不一致が起こっているかは、ネットワーク上に浮上したMicrosoft内の将来のプラットフォームに関する議論のスクリーンショットによって判断できます。 ASP.NETには限界がありますが、開発者はWebAssemblyでのコンパイルサポートなどの奇妙なトピックについて議論しています。 最も可能性が高いのは、現在の形式の.NET Coreは、非互換性があるため、Microsoftの一部の部門（Xamarinなど）にとって不便です。 マイクロソフトの一部は、もう一方が行ったことに完全に満足しているわけではありません。 スワン、ガン、パイクのように、それぞれが自分自身に依存しています。 その結果、その場で踏みつけられ、奇妙な沈黙が生まれます。

次は？ 公式のSlackチャンネルでの議論に基づいて、.NETの将来についていくつかの仮定を立てることができます：MscorlibとAppDomainsは元の形で戻ってくる可能性が高く、フレームワーク全体のモジュール性、そして一般的には初期のベンチャーの必要性が疑われます。 代わりに、ASP.NETからUnityおよびXamarinまでのすべてのプラットフォームで利用可能で互換性のあるAPIのサブセットです。 これらは非常に大きな変更です。 新しい用語-絶対的な不確実性。

おわりに

開発チームによる素晴らしい仕事にもかかわらず、経営者の目から見て全体像が欠如しているため、多くの開発者が現在の形でリリースされることのないプラットフォームに賭けています。 プラットフォームを2つのブランチに分割することが正しい決定であったかどうかについては、長い間議論することができますが、このトピックについてもっと早く考えなければなりませんでした。 RCステージでの180度の旋回は、あなたが考えることができる最悪のものです。 リリース候補は、十分に達成できる特定の義務を暗示する確立された用語です。