PHPでプロジェクトを維持する：避けるべき5つの間違い

PHPを管理することに関しては、他の言語と同様、何の価値もない欠点もある。 IT プロジェクト どこ PHP が主要言語である。

以下に、それらのリストと、それらを避けるためのヒントをまとめた。

1.PHP規格の推奨事項に従っていない

PHP は参入障壁が非常に低いため、「簡単な言語」と考えられている。その結果、コーディング・スタンダードや、さまざまな外部ライブラリにおけるグローバル・インターフェースの実装方法に大きな格差が生じている。秩序をもたらすために、一連の標準が導入された。これらは、実装の開発者が、標準によって要求される制約のセットを満たすことができる方法のセットを記述している。簡単な例として イベント・ディスパッチャ:

リスナー - リスナーとは PHP Eventが渡されることを期待する callable。0個以上のListenerが同じEventを渡されるかもしれない。リスナーは、そう選択した場合、他の非同期動作をエンキューしてもよい[MAY]。

この標準規格を使用することで、PSR準拠の命名法を使用するすべての開発者は、PSRと簡単に通信できるだけでなく、PSRを使用するすべての開発者と簡単に通信することができます。 コード 他の開発者と一緒に。
これらの基準を実践するには、例えば、以下のような方法がある。 PHP 正しい方法 グローバルPSRインターフェイスをサポートするガイドラインとライブラリにより、以下のことが可能になります。 PHP開発者 機能要件、アーキテクチャ要件、インフラ要件の変更により迅速に対応できるようにする。

どうすればそれを避けることができますか？

コードベースのメンテナとして、実績のある安定したバージョンの外部ライブラリを使用すること、また、カスタムベースのソリューションを使用せざるを得ない場合は、PHP PSRを使用して実装することを常に忘れないでください。
利用可能なすべての規格のリストは、メインウェブサイトでご覧いただけます。 PHP-FIG.実用的な説明を含む拡張規格は、以下のサイトからさまざまな形式で入手できる。 PHP 正しい方法 ホームページ
PHP-FIG規格に準拠した最良のライブラリは、以下のリストに掲載されています。 PHPリーグ ウェブサイトをご覧ください。

2.composer.jsonの依存バージョンをロックしない

依存関係マネージャを使用するプロジェクトでは 作曲家 を長い間サポートし、維持した後に、「このままではいけない」という状況になることがよくある。 製品 本番環境では、アーキテクチャ全体を再構築することなく、機能的な変更を実装する必要がある。たいていの場合、プロジェクトはプログラマに引き継がれ、そのプログラマのタスクは、ローカルの開発環境を立ち上げ、チケットの作業を開始することである。チケットに基づいて コンポーザー・ロック ファイルを変更すると、開発者はプロジェクトを本番環境の状態に戻すことができます。 composer.json ファイルにライブラリを追加するなどすると、エラーの連鎖が起こり、新しい チーム ソリューションの開発期間だけでなく、組織にとってのメンバーでもある。

どうすればそれを避けることができますか？

アプリケーションが安定したら、コードメンテナはライブラリのバージョンを composer.json ファイルを作成し、将来必要になった場合のバージョンアップ方法を説明した明確な手順を作成する。

また、使用するライブラリのセキュリティ状態をチェックし、セキュリ ティアップデートを提供するプロセスを自動化する仕組みの運用も検討する。
などの無料ツールを使用する。 ディペンダボットそうすることで、依存ライブラリの一貫した管理可能なバージョン管理インフラを維持し、アプリケーションのセキュリティを保証することができる。

3.不十分な要件収集

> ただのCRUDなのに、なぜ悩む？

> まさにそれを実現するライブラリーがある！

の中で PHP ドメインでは、製品のビジネスロジックを実装する際に忘却の渦に陥りやすい。データモデルを管理するための管理パネルを作成する](https://backpackforlaravel.com/)、[Google Analyticsのようなビューを生成する](https://github.com/Kunstmaan/KunstmaanDashboardBundle)、[PHPの非同期問題を解決する](https://laravel.com/docs/9.x/octane)といったプロジェクトは、魔法の杖を触るように（コマンドラインクエリ1つでOK）、長年にわたって何百と存在してきた。
PHPの世界には、99.9%の確率で動作する既製の実装が溢れている。
0.1%は、ビジネス・ロジックと、使用されているライブラリの機能的な制約がぶつかるところだ。
いわゆる "スローイン "と呼ばれるもので、プロジェクトの最後に実行するのが最も難しい。

どうすればそれを避けることができますか？

製品のビジネス領域を正しく理解することなしに、過剰エンジニアリングと過小エンジニアリングの間の黄金分割を見つけるチャンスはない。
スタート 開発チーム 製品フェーズの早い段階でメンバーに加わり、プロダクトオーナーと協力しながら積極的に行動することで、長期的な投資として機能しないソリューションを使用する問題のリスクを最小限に抑えることができる。

4.テストを書かないことによるコスト削減

PHP が完璧でないことは確かだ。静的型付け、ジェネリックスのサポート不足、古臭いメソッドの継続的なサポートといった欠点は、今でもプログラマーの間で冗談の種になっている。しかし、しばらくの間 PHP開発者 など、ますます強力なツールが与えられている。 PHPStan, Xdebug, PHP-CS-フィクサー これにより、一貫性と静的型付けを維持し、多くのバグを回避することができる。しかし、テストにはあまりに注意が払われていない。テストは、正しく実装されれば、次のような形ですぐに投資回収ができる。
- 回帰誤差の低減
- 製品能力に対する認識の向上
- 開発者のコード所有意識の向上

どうすればそれを避けることができますか？

テストのコストを削減しないでください。シンプルな Behat スクリプトを書くのはそれほど難しくありません。すぐに複雑なエンドツーエンドのテストを書いたり、実装の詳細に入り込んで全てのメソッドをユニットテストしたりする必要はありません。
自然なドメイン言語で記述されたシンプルなBehatテストは、最も綿密に書かれたエンドツーエンドのテストよりも価値があることが多い。

5.モダン・アーキテクチャ・パターンを考慮しない

について PHP言語 そして最も強力な2つのフレームワーク ララベル そして シンフォニー は、モダンで機能的、そして何よりも高性能なアーキテクチャを構築するのに完全に適している。様々なメッセージ・キュー・システムをサポートし、さらに高速な PHP performance improvements from version to version allows us to easily create microservices based on microframeworks. For the most part, however, we still rely on monolithic systems. There’s nothing wrong with that, but when considering the development of such systems we need to pay close attention to the domain boundaries and determine the point of interface between new solutions and older parts of the system.

どうすればそれを避けることができますか？

開発にあたって PHP のウェブサイトでは、現在のソリューションをよく観察し、データ通信のためのグローバル・インターフェースを作成し、最新の技術や慣行を使って新しい機能を実装することに価値がある。実際に使用されている最も一般的なソリューションのひとつは ストラングラー・パターン.