🍥 🕴🏿 🔝 1つのレガシープロジェクトにPSR標準を実装した経験 👩🏼‍🎓 👆🏻 🗞️

みなさんこんにちは！

この記事では、1つのレガシープロジェクトで「モダントレンド」プラットフォームに移行した私の経験についてお話したいと思います。

それはすべて約1年前に始まり、彼らは私を「古い」（私にとっては新しい）部門に投げ入れました。

それ以前は、Symfony / Laravelで働いていました。自作のフレームワークを使用したプロジェクトに切り替えたため、WTFの量はわずかに増えましたが、やがてそれほど悪くはなくなりました。

まず、プロジェクトは機能しました。次に、設計パターンの使用が追跡されました。依存関係コンテナ、ActiveRecord、およびQueryBuilderがありました。

さらに、コンテナ、ロガー、キューの操作、およびサービスレイヤーの開始に対する追加の抽象化レベルがありました（ビジネスロジックはHTTPレイヤーに依存せず、一部の場所ではロジックがコントローラーから取り出されていました）。

次に、我慢するのが難しかったものについて説明します。

1.ロガーlog4php

ロガー自体はうまく機能しました。しかし、デメリットはありました。

インターフェイスの欠如
タスクの構成の複雑さはやや標準的です（たとえば、エラーレベルログをElastickSearchに送信する）。
オープンソースの世界のコンポーネントの大部分は、 Psr \ Log \ LoggerInterfaceインターフェースに依存しています。プロジェクトでは、まだ両方のロガーを保持する必要がありました。

2-6。コントローラーの形式は次のとおりです。

<?php class AwesomeController { public function actionUpdateCar($carId) { $this->checkUserIsAuthenticated(); if ($carId <= 0) { die('  '); } $car = Car::findById($carId); $name = @$_POST['name']; container::getCarService()->updateNameCar($car, $name); echo json_decode([ 'message' =>' ' ]); } }

アプリケーションコードの実行中に死ぬ
コントローラーを終了する前にエコーします。
ユーザー認証は各コントローラーで個別に接続されました
従来の$ _POSTおよび@
コントローラにサービスを実装する可能性はありませんでした。

7.グローバルアプリケーションエラーロギングの欠如

ログで見つかる最大値は、メッセージテキストです。エラーについてのより詳細な情報は、開発スタンドで繰り返した後に取得できます。戦闘環境でさらにログを記録するには、目的のコントローラーメソッドにtry / catchブロックを配置する必要がありました。

8.依存関係コンテナーの構成

依存関係コンテナは、時代2.4のSymfonyコンテナに似ていました。各サービスには、登録とその組み立て方法の説明が必要でした。自動配線が最大限に使用されるlaravelコンテナーの経験があるため、日常的なアクションを取り除きたいと思いました。また、自動配線の欠如により、プログラマーが個別のビジネスタスク用に個別のサービスを作成する（新しいクラスを作成する）欲求が減りました。この場合、間違いを犯してさらに時間を失う可能性が常にあります。

9.ルーティング

Yii1に基づいたルーティングは論理的でシンプルでした。

www.carexchange.ru/awesome_controller/update_carのようなアドレスは、AwesomeControllerコントローラーとactionUpdateCarメソッドの実行を意味していました。

しかし、残念ながら、サイトのネストされたサブディレクトリがあり、フォームのURLを作成する必要がありました

www.carexchange.ru/awesome_controller_for_car_insite_settings_approve/update_car

それは気にしませんが、制限は奇妙です

10. URLをハードコードする

ルーティングは単純だったので、URLを自動的に生成する方法はありませんでした（なぜ複雑なのか）。これにより、phpとjsの両方でハードコードされた数千のリンクが作成されました。もちろん、URLを変更することはめったにありませんが、時々起こることがあります。そして、プロジェクトでそれらを探すのは難しいです。

何かを変える時が来ました！

別のプログラマーの出現により、リファクタリングの可能性について疑問が提起され始め、それを「より人道的な」ものにしたいという要望がありました。「より人道的な」-現代の開発者にとってより身近なものを読んでください。既存のコードの読み取りと保守は困難でした。

経営陣とのいくつかの議論の後、緑色の旗が得られ、概念実証に関する作業が開始されました。

当初から、現代の基準に従うことが決定されました。これらはPSRの推奨事項であり、他のフレームワークの標準的な動作に従います。最新のフレームワークで作業する新しい開発者は、コントローラーの場所、サービスの組み立て方法、ビジネスロジックの作成場所を理解している必要があります。

音声によるクレームを詳しく見ると、アプリケーションレベルのコード（コントローラー）とインフラストラクチャレイヤー（コンテナー）に問題があることがわかります。

ビジネスロジックは個別に記述されており、HTTPレベルに依存しませんでした。そのままにしておきます。 Active RecordとQueryBuilderも動作しませんし、同じ教義/ dbalとあまり変わらないため、触れません。

フレームワークの選択

実際、ここでの選択は大きくありませんでした。 HTTP経由のレイヤーのためにすべてのlaravelまたはsymfonyをドラッグしても意味がありません。また、必要なコンポーネントはいつでも作曲家を介して接続できます。

真剣な選択は、2つのマイクロフレームワーク、スリムとZendの間でした。

これらのフレームワークは両方とも、PSR-7およびPSR-11を完全にサポートしています。

なぜルーメンじゃないの？もちろん、主な理由は、ルーメンが「マイクロ」と呼ばれることはほとんどなく、このすべての利点と結びついているからです。既存のプロジェクトにLumenを組み込むことは困難です。依存関係コンテナを簡単に交換することはできません（照明契約への準拠が必要です）。 PSR-7コントラクトはフレームワークをサポートしますが、それでもsymfony / http-foundationに依存しています。

最初は、Zendを真剣に考えました。しかし、「すべてのミドルウェア」イデオロギーでアプリケーションの実装を見て、コンテナー構成がどのように形成されるかを見て2日間を過ごした後、私は経験の浅い開発者に呼び出し可能が工場とどのように異なり、エイリアスを書く時期をどのように説明するのか想像するのが怖かったです。完璧主義者や学者にとって、Zendはそれを好むべきです。アプリケーションは、パイプラインとミドルウェアを介して機能します。しかし、私は入場のより高い閾値を恐れていましたが、動きは簡単で、理想的には見えないようにすることでした。

その後、スリムに切り替えました。プロジェクトでの実装には1日もかかりませんでした。コントローラー（古いものと新しいもの）の選択は、ミドルウェアによって実装されました。スリムで停止しました。 PSR-15ミドルウェアでパイプラインに切り替える遠い計画で。

コンテナの選択

ここで私はリーグ/コンテナに落ち着いたと言って、自分の選択を説明しようとします。

これはPSR-11サポートです。

現在、ほとんどのコンテナはすでにPSR-11をサポートしていますが、1年前にはコンテナ/相互運用インターフェイスをサポートしているのはごく一部のみです。
自動配線。
同じzend-servicemanagerとは対照的に、Syntasisは非常に単純です。
モジュールをさらに分離して記述できるサービスプロバイダー。

照明/コンテナでは、プロバイダはアプリケーションレベルで登録され、リーグ/コンテナでは、プロバイダはコンテナレベルで登録されます。したがって、アプリケーションはコンテナのみに依存し、コンテナはサービスプロバイダーに依存します。
コンテナの委任。この「機能」は、コンテナ交換フェーズにとって決定的なものであることが判明したため、詳細を開示します。

必要に応じて、リーグ/コンテナ内に複数のPSR-11互換コンテナがある場合があります。

考えられるシナリオ：古いコンテナーをsymfony / dependency-injectionに変更することにしました。徐々に移動するには、リーグ/コンテナーを接続し、古いコンテナーとsymfonyコンテナーの両方をデリゲートに配置します。サービスを検索するとき、古いコンテナーが最初にポーリングされ、symfonyコンテナーで検索が行われます。次のステップでは、すべてのサービスの説明をsymfonyコンテナーに転送し、それだけを残すことができます。コードはPSR-11インターフェイスに依存するため、変更は最小限です。

HTTPを介した抽象化の選択

次の3つのオプションのみがあります。

ところで、SlimはHTTP実装を個別のパッケージ（ブランチ4.0で予定）に分離するように動いています。

不要なコードと不要な依存関係のため、Symfonyブリッジを使用したくありませんでした。 Slimは私たちを何も制限しないので、Zendの実装が優先されました。これは、HTTPコード層からのアプリケーションコードの独立性を高めるだけです。

ロギング

ここでは、モノログだけが思い浮かびます。彼らはそれをねじ込んだ。 PHPConsoleHandlerとChromePHPHandlerは開発中に便利です

ルーティング

スリムですぐに使えるFastRouteがあります。それに基づいて、名前付きルートが登場しました。 URL生成は、グローバルヘルパーを介して実装されます（こちらのように）

それで、何が変わったのでしょうか？

コントローラーは次のようになります。

 <?php namespace Controllers; use Psr\Http\Message\ServerRequestInterface; use Psr\Http\Message\ResponseInterface; use Zend\Diactoros\Response\JsonResponse; use Domain\Car\Services\CarService; class AwesomeController { /** * @var CarService */ private $carService; public function __construct(CarService $carService) { $this->carService = $carService; } public function actionUpdateNameCar(ServerRequestInterface $request, $carId): ResponseInterface { if ($carId <= 0) { throw new BadRequestException('  '); } $car = $this->carService->getCar($carId); $name = $request->getParsedBody()['name']; $this->carService->updateNameCar($car, $name); return new JsonResponse([ 'message' => 'updateNameCar ' ]); } }

もちろん、実際のコードでは、 $request->getParsedBody()['name']

やnew JsonResponse

、追加のチェックで別の抽象化レベルに移動します。

おまけとして：環境によっては、コンテナ内のサービスを置き換えて機能テストを実行することができます。

結論として

ご覧のとおり、「非常に簡単」というイデオロギーを持つ多くのプラクティスがLaravelから借用されています。彼は本当にトレンドを設定します。

アプリケーションは、7年間動作していた後、新しいフレームワークを受け取りました。私の知る限り、古い自己記述フレームワークもすぐには現れませんでした。そして、5年後にフレームワークを変更したくないという保証はありません。したがって、コードは選択したフレームワークから可能な限り独立して記述されました。ビジネスロジックは、以前はアプリケーションに依存していませんでしたが、コントローラーはフレームワークに依存しなくなりました。コントローラーはPSR-7互換要求に依存し、PSR-7応答を返します。また、コントローラーはPSR-11互換コンテナーに応じてアプリケーションによって組み立てられます。

Slimはミドルウェアを介して動作し、共通ロジックの追加がより簡単になりました（アプリケーションエラーのログ記録、ユーザー入力エラーの処理）。自動配線コントローラーは非常に機能します。実際、コントローラーはサービスになりました。

ちなみに、ここではスリムで自動配線を有効にする例を見ることができます。

もちろん、アプリケーションは進化を続けており、すでに標準のキャッシュとイベントのインターフェースに切り替えていますが、それらの実装は少し血まみれでした:)。

1つのレガシープロジェクトにPSR標準を実装した経験