1年半前に戻って、最初のプロジェクトを開始する前に自分自身にアドバイスを与えられることは、おそらく素晴らしいことです。 悲しいかな、これは不可能です。 しかし、他の初心者のSymfony開発者にとって私のアドバイスが役に立つかもしれませんか？
コードスタイルと命名規則に従う
コードスタイルの重要性について私は1000回は話さないが、ほとんどの初心者開発者はそれに準拠していない。
幸いなことに、この問題は簡単に修正できます。 最新のIDEでは、選択したルールに従ってコードを自動的にフォーマットできます。 現在、PHPStormを使用しています。 Symfonyには事前定義された設定、useステートメントの自動追加、その他多くの利点があります。
コーディング標準について話す場合、Fabien PotencierのPHP CS Fixerは言及できません。 PHP CS Fixerは、しばらくすると必要なツールになります。
少し叙情的な余談。 社会学では、壊れたウィンドウの理論があります。これは、一部の人々が一般に受け入れている規則を無視すると、他の人々もこれらの規則や他の規則を無視するようになります。 プロジェクトのコードスタイルエラーを修正します。コードに「壊れたウィンドウ」を残さないでください。
ファットコントローラーを作成しない
太い愚かなupいコントローラー（TTUK）、初心者開発者のコードで発生する2番目に人気のあるエラー。 シックコントローラーについて多くのことが書かれています。 一言で言えば、一般的な場合、コントローラーは再利用可能なソフトウェアモジュールではありません。 したがって、ビジネスロジックをここに保持しないでください。 コントローラのロジックは、DRYの原則に違反しており、コピーアンドペーストを引き起こします。 ビジネスロジックをサービスレイヤー、モデル、どこにでも持ち込みます。 新しいクラス、サービス、メソッドを自由に作成し、TTUKiを行ってください。
コンテナ依存サービスをしないでください
何よりも、そのような機会が存在することを忘れてください。 コンテナに依存するサービスを作成すると、その中で何が起こっているかを制御できなくなります。 また、依存関係から「膨張」するという理由だけで、コンテナ全体をサービスに実装したい場合は、おそらくアーキテクチャに問題があります。 サービス内のコンテナは、単一責任の原則に違反するように促し、正しいデザインの作成には一切寄与しません。 コンテナ対応サービスのテストは困難です。 そして、そのようなクラスに基づいて階層を開始する場合、リファクタリングも困難になります。
反対側からサービスコンテナを見てください。 これは主に依存関係を構成するためのツールであり、サービスをプルできる場所ではありません。 コントローラー以外のクラスでコンテナーを使用しないでください。 さらに良いことに、サービスを行うために自分とコントローラーを訓練します。 コードで何が起こっているかを理解し、制御するのが簡単になります。
できるだけシンプルなコードを書く
まず、不要なインターフェイスの作成を停止します。 特定のクラスに依存しないようにするためだけに、インターフェイスを入力しないでください。 インターフェイスの唯一の具体的な実装は、おそらくプロジェクト内に何年も存在します。 特定のクラスに依存関係を作成することを恐れないでください。 コードを簡単にリファクタリングし、必要に応じてインターフェイスを追加できます。
次に、パブリッククラスAPIをできるだけ単純にします。 つまり、クラスのパブリックメソッドを作成しないでください。このメソッドは今は使用しません。
第三に、パブリッククラスAPIではないメソッドとプロパティをデフォルトでプライベートにします。 メソッドまたはプロパティをオーバーラップすることが必要になった場合、いつでもスコープを変更できます。 しかし、別のプログラマがあなたのコードを読むとき、彼はこの方法が他のどこでも使用されていないことを100パーセント確信します。
第四に、明日使用されるものを今実装しないでください。 練習は、この幽霊のような明日が決して来ないかもしれないことを示します。 はい、プロジェクトの要件がどのように変わるかを正確に言うことはできません。 では、なぜ今プロジェクトを複雑にしているのでしょうか？ なぜ余分な仕事をする必要があるのですか？
5番目に、1つの小さな機能のために、バンドル全体をプロジェクトに含めないでください。 たとえば、コントローラーの1つでJSONを返すためにFOSRestBundleは必要ありません。
コメントを乱用しないでください
明らかなことについてコメントしないでください。 IDEがこれを自動的に行うことができるという理由だけで、メソッドにコメントを追加しないでください。 クラス、メソッド、変数、およびプロパティの名前を正常に選択した場合、コードにコメントをまったく追加しないでください。
ただし、コメントが必要な場合もあります。 ロジックが複雑であるか、明らかでない場合は、コードにコメントすることを忘れないでください。 キーメソッドにのみコメントを追加します。 最も重要な仕事をする人に。 複雑なレギュラーを使用するコメントとテストメソッドで常にカバーします。
Doctrineの仕組みを理解します。
ほとんどの場合、ORMではなくユーザー自身のエラーが原因で、アプリケーションのデータベース処理が遅くなります。 エンティティ間の関係のタイプと方向を正しく決定します。 エンティティの継承を乱用しないでください。 プロファイラーを常に見て、データアクセスレイヤーの動作速度とORMが作成する要求を制御します。 ネストされたトランザクションを避けます。 コントローラーでのみフラッシュを呼び出します。 少なくとも対角線で、Doctrineのドキュメントをもう一度読んでください。
Twigのすべての機能を使用する
Twigは非常に優れたテンプレートエンジンです。 やがて、あなたはこれを理解するでしょう。 必要に応じて拡張するのは非常に簡単です。 しかし、標準パッケージにあるものでさえ、テンプレート内のコードの複製を停止するには十分です。 もう一度ドキュメントを読み直してください。あまりありません。 そして、このツールを最大限に活用してください。
例外を賢く使う
本番環境で発生する可能性のある例外については、常にカスタムタイプを定義してください。 開発中に発生する可能性のある例外について明確なメッセージを作成します。 重要な例外を1か所で処理し、すべてのコントローラーでそれらをキャッチしようとしないでください。 スローされる場所のできるだけ近くで修正できる例外をキャッチします。
設定を大きくしないでください
symfonyは、設定ファイルを必要な方法で整理するためのすべてのツールを提供します。 大きな設定は不便です。 プロジェクトの開発者が構成がどこにあるのかを簡単にナビゲートできるように、それらを小さなものに分割する必要があります。
プロジェクトの依存関係をより頻繁に更新する
可能であれば、安定版のバンドルを使用してください。 そうでない場合は、可能な限り頻繁に依存関係を更新します。 エラーは、表示されたとおりに修正するのが最適です。 大量の更新を収集する場合、すべての非互換性の問題を排除することははるかに困難です。
テストを書く
プロジェクトの初日からBehat受け入れテストを作成します。 そうすると、すべての機能をカバーするのが難しくなります。 テスト環境の作成には時間がかかります。 ただし、初期段階では、この時間は他のタスクに分散されます。 そして将来、これらのテストはしばしばあなたを助けます。
PHPUnitで単体テストを作成します。 少なくとも最も複雑で最も重要な方法については。 コードの前にテストを書くと、より良いデザインを作成できます。 単体テストからの利益は、コードにバグやリグレッションがない場合です。
さて、私が自分に与えたい最も重要なアドバイスは、次のとおりです。 商業プロジェクトで今そのような機会がない場合は、OSSでそのような人を探してください。」
いくつかのリンク：
- symfonyコードスタイル
- 壊れた窓の理論
- 元の記事「MVCのM：モデルが誤解され、評価されない理由」とパドリックブレイディ、およびhabruiser Vedomirによる記事の良い翻訳 。 Wikipediaを信じているなら、この記事で初めてfatコントローラーについて言及されます。
- DIの「適切な」使用に関する良い記事
- Doctrineの「正しい」使用に関するビデオ