Open / Close原則を意識する

クラスやモジュールは拡張に対して柔軟にする。
変更は既存部分は変更が加わらないように設計にする。

変更箇所の依存関係を把握する

修正対象のコードが他の機能から呼ばれていないか確認をする。
例えば既存関数を変更する場合はその関数を利用している別機能がないかを調査。
必要なら影響を受ける箇所も修正・テストする。

一度に大規模な改修を行わずに機能ごとに変更範囲を限定する。

変更が小さいほどレビューやテストが容易になる。
結果として不具合発生時も原因を特定しやすくなる。

チームで既に決まっているコーディング規約やプロジェクト固有のスタイルがあれば新しいコードもそれに揃える。

バグやデグレを防ぐことができる。

1コミットには1つの意味のある変更だけを意識する。
タスクを分けて整理をすることでレビューと調査がしやすくなる。

コントローラやBladeビューにビジネスロジックを書きすぎないようにする。

複雑な処理はモデルのメソッドやサービスクラス（app/Services等）に委譲する。
コントローラは「入力の受け渡しと結果のビューへの引き渡し」に専念させる。

ビューには極力生PHPコードを埋め込まない。
必要なデータはコントローラで用意して渡すようにする。

Laravelが提供する標準機能はなるべくそのまま使う。
独自拡張や上書きは慎重に。
Laravelのコアを直接書き換えたり、本来の使い方から逸脱した利用はしない。

不得意なもの、意識しなければいけないものはカレンダーに書いて朝仕事に取り掛かる前に読んでいる。
癖付けていく！！