アノテーションの使用を減らす
個人的には注釈が大好きですが、経験を積むと不快感を感じることがわかりました。 実際、設定全体を注釈に転送することはできません。 次の2つのオプションがあります。
- 構成ファイルの最大値（例：yml）;
- ファイルに少し、アノテーションに少し。
2番目のオプションを選択すると、プロジェクトの成長とともにおが得られます。 また、コードにはロジックよりも多くの注釈があります。 「ルートを見つけやすい」というタイプの言い訳は受け入れられません。 構成ファイルを正しく配布すれば、特定のコントローラーへのルートがどこにあるかを常に把握できます。 route：debugや、アクションの名前とルートの名前を表示するデバッガーなど、コンソールのコマンドについてはすでに説明していません。
悪い例（私は）：
マネージャーとリポジトリーを別々のフォルダーに移動する
現在のプロジェクトで取り決められているように、すぐに悪い例を挙げます。
すべてのマネージャークラスは、マネージャーフォルダーのリポジトリリポジトリクラスに存在する必要があります。 これが行われない場合、マネージャーとリポジトリーを備えた5〜10個のエンティティーの出現により、人生は「もっと楽しく」なります。
テンプレートでは、常にJavaScriptとスタイルでブロックを定義します
すべてがシンプルです。 個別のページでは、必要なjavascriptとスタイルのみをいつでもオーバーライドおよびロードできます。 また、最も基本的なテンプレートでは、これらのブロックを空のままにすることをお勧めします。 そして、メインlayout.html.twigを作成してそれらを埋めるバンドル。
AppBundle / Resourcesに保存されているバンドル構成
プロジェクトが小さい場合でも、最初はapp / configではなくAppBundle / Resources /にバンドル構成を保存することに慣れます。 アプリ内/リンクのみ。 これは主にルーティングとサービスに関するものです。
構成ファイルに記述されているエンティティ
エンティティは、たとえばAppBundle / Resources / config / doctrine / Entity.orm.ymlなどの構成で最もよく説明され、それ自体がエンティティクラスを生成するdoctrine：generate：entitiesコマンドを使用して生成されます。 エンティティ構成がファイル内にある場合、クラス自体はよりきれいに見えます。 また、エラーがないことも確認できます。
テストのために、別個のデータベースを作成します
parameters.testファイルで、フィクスチャをロードするテストベースのパラメーターを指定します。 したがって、同じデータをテストしていることを常に確認できます。 おそらくすべてがそれを行っているだけで、現在のプロジェクトでは、そのような実践の欠如に出くわしました。
もちろん、これらはすべてありふれたものですが、そうしない人もいますし、彼らのために書いた
誰かがコメントで彼らのアドバイスを書いてくれたら嬉しいです。
追加者 ：