Magento（当時はまだ「統一」）で初めて、約6年前に出会いました。 それ以来、私は彼女と一緒に密度を上げたり下げたりしてきました。 当初、この投稿は「Quo vadis、Magento？」と呼ばれたかったのですが、 判明したように、コミュニティはこの人気のある質問を何度も尋ねました。Magentoがebayで購入され、販売され、いつでも「2」今日まで、この質問は関連性が残っています（私はそのような名前を使いたいとさえ思っていたので）。 したがって、ポストは呼び出されたとおりに呼び出されます。

カットの下で、私はこのプラットフォームの見通しについて、自分自身の（つまり主観的な）ビジョンを作成しようとしました-不満と落胆に満ちています。 詳細な計算はありません。 詳細な考えはありません。 証拠なし。 そして最も重要なこと-

はい、主なものは希望なしです。

ルロア

私の練習では、Magentoはおそらく私が遭遇した中で最も複雑なWebアプリケーションです（もう一度、計算の主観性に焦点を当てます！）。 ジョナサン・エドワーズの同僚は、かつて「プログラミングは、コードの克服できない複雑さと要件の裏切りに対する必死の負けの戦いです」（ プログラミングは、克服できないコードの複雑さと要件の裏切りに対する絶望的に失われた戦いです ）。 そのため、この絶望的な闘争におけるMagentoは、私が見た他のすべてのWebアプリケーションよりもさらに進んでいます。

Magentoの基礎はもともと、適応性と拡張性の原則に基づいていました：EAV、モジュール、書き換え、イベント-これらは、多くのユーザー、そして最も重要なのは開発者をMagentoに引き付け、eコマースの主要な位置を占めることを可能にするメカニズムです。 Magentoの主な「機能」は、「すぐに使える」豊富な機能だけでなく、「自分用に」ストアをカスタマイズできる印象的な数のサードパーティモジュール（有料および無料）でもあります。

Magentoは多くの開発者の魅力の中心になっています-誰もが必要とする小さいが無料のモジュールを作成することで良い広告を得るか、基本機能ではカバーされない（またはEnterpriseバージョンでのみカバーされる）特定の顧客のニーズに合わせて商用モジュールを作ることで良いお金を得る） Magento Connectには、Magento 1用に少なくとも966ページのモジュールがあり、1ページあたり10ユニット-ほぼ10,000の拡張機能があります。

一方、Magentoはユーザーにとっても魅力の中心となっています。ユーザーはすぐに実行可能なストアを受け取るだけでなく、既製のモジュールを使用して魅力的なテーマを選択し、機能を拡張することもできます。 または、「自分の」モジュールの作成を注文します。 または「あなたの」トピック。 拡張性はMagentoのキャッチーなマーケティングギミックの1つです。 もちろん、実際には、機能の追加/変更は完全に簡単な作業ではありませんでしたが、そのような機会は最初にプラットフォームの作成中にプラットフォームに追加され、競合他社に対して評価する際にうまく利用されました。 その結果、2015年の推定によると、Magentoの店舗数は25万台近くに達しました。

この双方向の魅力は、Magentoプラットフォームに基づくeコマースの分野でのさまざまなソリューションが作成、テスト、順応、または廃棄されるようなエコシステムを作成しました。 最初のバージョンでは完全なテストは行われませんでしたが、インストールの数によってその不在が補われました-一般的に使用される機能を使用し、エキゾチックな構成を構築しない場合、ストアの作業でエラーが発生する可能性はかなり低くなりました。 一定数の既存の大規模店舗も、少なくとも中小企業の観点からは、優れたプラットフォーム機能を示しています。

一般的に、最近では、Magentoはeコマース市場で議論の余地のないリーダーでした。

... est mort

それでは、Magentoの将来を悲観的に個人的に見ているのはなぜですか？ 恐らく彼らがタイタニックのエンジンルームの将来について悲観的に見たのと同じ理由で。 おそらくすべての情報が流れたエドワード・ジョン・スミス船長でさえ、当時のマーケティングサービスの類似物がタイタニック号の沈めないことを確信していた乗客は言うまでもなく、状況の悲劇を最初は理解していなかったでしょう。 しかし、機械室では、破裂したリベット、鋼板間の隙間が見られ、そこに氷の海水が破裂し、泡立ち、泡立ち、ポンプの動作が失敗しました。 機械室では、タイタニック号が水面にどれだけ長く耐えられるかを正確には知りませんでしたが、アメリカに届かないことは確かに知っていました。

Magento 2は間違いなく以前のバージョンの開発です。モジュール性が向上し、作曲家との互換性が実現し、「フロント」とサーバー側の両方で最新のソリューションが使用され、コードが公開さ れテストされ 、パフォーマンスが向上しました。 一見、非常に素晴らしい見通しです。

しかし、それにもかかわらず、画像を暗くするものは何ですか？

ボリューム

Magento 2には、合計で1,357,121行のPHPコードと2,449,066行があります（WordPress- 423,759 ; WooCommerce- 131,549 ; osCommerce- 208,928 ; Drupal- 704,269 ）。

行数にひどいものは何もありません（同じSugarCRMには2,149,457行が含まれています）-これは、アプリケーションの「慣性」、物理学の質量の類似物、船舶が急激に進路を変更できない理由の単なる指標です。 問題は何ですか？

データ構造

Magento 2の開発者は、データ構造を大幅に作り直す素晴らしい機会を得ました-2番目のバージョンは最初のバージョンと互換性がないことが公式に発表されました。 また、データ構造が大幅に進歩しました。最初のバージョンのデータベースを実際に2番目のバージョンで使用できないように、テーブルとフィールドの名前が変更/追加/削除されました。

しかし、処理の主な動機は依然として「できるだけ少ない変更」であったことは明らかです。 それ以外の場合、DBのstore_idと「deuce」に移行した管理パネルのStoreの不一致を説明するにはどうすればよいですか（DBのstore_idは管理パネルのStore View属性ですが、DBのgroup_idは管理パネルのStoreの属性であり、これは理解できません、これは必要です覚えていますか？ または、同じストアテーブルまたはストックテーブルのデータ間の依存関係があいまいですか？

またはそのような基本的な（または修辞的な？）質問-なぜ製品属性（catalog_product）のみが拡張用に利用できるエンティティの8種類（顧客、顧客アドレス、カタログカテゴリ、カタログ製品、注文、請求書、クレジットメモ、出荷）だけですか？ admin、authorization、stock、sales_rule、cms、評価、レポート、レビューなどのエンティティが無視されるのはなぜですか？

ちなみに、これは特に最初は非常に混乱します。実際、CommunityバージョンのエンドユーザーがEAVを製品の1つのデータタイプのみに適用できる場合、データ構造にEAVのサポートを作成するのはなぜですか。 はい、これはアプリケーション全体の速度を遅くします（少なくとも開発者モードでは）。これがフラットテーブルの外観の理由です。 もちろん、「デュース」では、クライアントの属性の一部がそれでもcustomer_entityに転送されました（28のフィールド、12の「1」に対して）。

コード

Magento 2はアーキテクチャを大幅に再設計しました-これは明確な進歩です。 DIとリポジトリクラスレイヤーの外観、APIとSwaggerの統合、およびCLIコマンドセットと独自のコマンドの拡張のみを歓迎できます。 しかし... ... Magento 2のベストプラクティスに基づいて、プログラムでストア（管理パネルの観点からストアビュー）を保存してみてください-動作しません 。 これは、\ Magento \ Store \ Model \ Storeのレポクラスが存在するにもかかわらず、 save（）メソッドがなく、\ Magento \ Framework \ Model \ AbstractModelから継承された「one」の標準のsaveメソッドが宣言されているにもかかわらずです@非推奨。

そして、 \ Magento \ Sales \ Api \ OrderStatusHistoryRepositoryInterfaceインターフェースの実装を見つけてください。 di.xmlによれば、「\ Magento \ Sales \ Api \ Data \ OrderStatusHistory \ Repository」である必要があります。 OK、クラス「\ Magento \ Sales \ Api \ Data \ OrderStatusHistory \ Repository」を見つけてみてください。 たぶん、このインターフェイスはどこでも使用されていませんか？ いいえ、 使用されます。 自動生成できますか？ いいえ、ファクトリ、プロキシ、インターセプターが生成され 、リポジトリがあります。

コードをさまよう-非常に再設計されたモジュール（顧客など）がありますが、「1」からラップされたコードがあります。 私は、「デュース」は「統一」に基づいて行われ、「政治的」な決定は、重要な日付までにリリースされる既存のコードを可能な限り使用することを決定したことを理解しています（ebayまたはebayによる販売、投資など）。 または「 開発コストを削減する」。 これは問題ではありません。 これだけであれば、コードの体系的かつ系統的な処理によって状況を修正できます。 問題は、現在「効果的な」/「危機」のマネージャーが技術者ではなく、Magentoを担当していることです（男、犯罪なし-私はあなたの名前を知りません、私は結果によってのみ判断します）。

リリース

さて、2.1.4の2週間後、2.1.5が出てきて、その唯一の目的が次の場合、他に何が考えられますか？

このリリースでは、すべてのファイルの著作権日付が更新されます。 機能の変更やセキュリティの改善は含まれていません。 これらの変更を単一のリリースに分離することは、将来の更新と開発者のワークフローを簡素化することを目的としています。

リリース！ 技術的な面でのマイナーな変更の全リリース!!! そして今、店のオーナーに彼らのために働く2.1.4がおそらく最後を除いて2.1.5とまったく同じ機能的な観点からであることを説明するために？

2月中旬のリリース計画 ：

今のところ、2.1.5が著作権、2.1.6のセキュリティ、2.1.7がバグ修正されます。

バグ修正を2つのグループに分割できますか-フロント用とサーバー側用ですか？ そして、リリースごとに何をしますか？ また、リリース2.1.6の翌日に突然セキュリティホールが発見された場合、2.1.8または2.1.9で「修復」しますか？

バグ修正

悲しいことに、私見では、 このプルリクエストはバージョン2.1.5に含まれていませんでした。 エラーコードは次のとおりです。

  public function getStockId() { return $this->getData(self::KEY_WEBSITE_ID); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここに修正されたものがあります：

  public function getStockId() { return $this->getData(self::KEY_STOCK_ID); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼は2016年9月29日に同僚のフェリックスデルバルによって投稿されました。 バージョン2.1.2（2016年10月12日）、バージョン2.1.3（2016年12月14日）、バージョン2.1.4（2017年2月7日）、悪名高いバージョン2.1.5（2017年2月21日）のリリースまで。 リリース計画から判断すると、バグは2.1.7-3〜4か月で修正されます。

しかし、これは明らかな間違いであり、初心者のプログラマでも理解できます。 彼女がこのバグの議論で10人（!!!）の参加者全員に費やした時間はまだ修正されていません！

ああ、嘘です-開発者ブランチで修正されました。 しかし、 リリースでは -と残り続けています。

私は答えを聞くのが怖いからといって、「リリースされたバグではなく、開発者のブランチにはどれだけ多くのそのような修正されたバグがあるのか​​」という質問をしません。

慣性

Magentoには良い歴史があり、印象的なコミュニティがあり、eコマースのパイにはまともな「ピース」がありますが、同時に...プロジェクトのコントロールが失われています。 Magento 2は、変更に対するタイムリーな応答を停止しました。 彼女は大きくなりすぎた。 マイクロソフトのように一度。

おそらく、いくつかの法律が施行されており、それによると、プログラミングだけでなく、一般に複雑なシステムの作成は「必死の敗戦」です。 構造は、未知の複雑な境界線に近づきます。次の各ステップは、前のすべてのステップをまとめて行う価値があり、機能を構築するために、新しいものを作成するのが簡単です-他の原則に従って、より低いレベルの複雑さで同様の機能を実装し、許可する別の構造それ自体が同じ境界に近づくまで、この機能を構築します。 物理学にも同様の境界があります-光の速さ、なぜプログラミングにもありませんか？

そのため、Magento 2の慣性は非常に複雑であるため、開発の管理がますます困難になっています。 上記のデータ構造、コード、バグ修正、リリースで説明されている問題は、「複雑さの上限」に近づいた結果です。

免責事項

ねえ、これは私の主観的な意見です。 私は弁護士ではなく、効果的なマネージャーでもありません。私は開発者であり、技術者です。 私の視点から写真を見ると、このように見えます。

Vive le Roi？

sayingにもあるように、「聖なる場所は空っぽではありません。」 そして、Magentoでない場合、誰ですか？

これらのデータから判断すると、 WooCommerce？ または、まだ撮影されていないOroCommerce- 「ユニティ」の著者から？ あるいは、 Syliusのようなあまり知られていないプレイヤーでしょうか？ それとも、新しい「王様」はまったくPHPに含まれないのでしょうか？ eコマースプラットフォームのエンドユーザーはどこに流れ、誰が新しい結晶化の中心になるのでしょうか？

これらすべての質問に答えることはできません。