挨拶
こんにちは。
今回は最近自分が意識している「コーディング指針」について、備忘録も兼ねてまとめてみようと思いました。
それではよろしくお願いします。
はじめに
コードを書くとき、ただ「動けばいい」ではすぐに破綻してしまいます。
保守しやすく、読みやすいコードを書くためには いくつかの原則 を意識しておくことが大切です。
最初にまとめると、大事なのは以下３つです。
- 「動けばいい」以上に大切な原則がある
- DRY / SRP / KISS / YAGNI の4つを意識するだけでコードはぐっと読みやすくなる
- 守れなかったときはリファクタリングで改善（既存処理を壊さないように注意）
ここでは上記項目に沿って、代表的な4つの原則を持ってきました。
まず簡単にコーディングにおいての基本原則を理解しましょう。
DRY（Don’t Repeat Yourself）
意味: 重複を避ける。
理由: 同じ処理が複数箇所にあると修正漏れや不整合が起きやすい。
例: バリデーションをコントローラーごとに書くのではなく、FormRequestにまとめる。
SRP（Single Responsibility Principle / 単一責任の原則）
意味: クラス・メソッドは「たった1つの責任」だけ持つべき。
理由: 責務が混ざるとテストが難しくなるし、変更に弱い。
例: コントローラーにDBアクセス・業務ロジック・レスポンス整形を全部書かない。
KISS（Keep It Simple, Stupid）
意味: 複雑にしない、シンプルを保つ。
理由: 複雑なコードはバグの温床になる。
例: ネストの深いif文を早期リターンに変える。
YAGNI（You Aren’t Gonna Need It）
意味: 「いつか必要になるかも」で余計な実装をしない。
理由: 実際に必要になるのはごく一部で、不要なコードは保守コストを増やすだけ。
例: 未来の要件を想定して抽象クラスやインターフェースを先に作らない。
その他よく出てくる考え方
- リスコフの置換原則（LSP）やオープン・クローズド原則（OCP）などのSOLID原則。
- まずはDRY・SRP・KISS・YAGNIを意識するだけで初心者のリファクタリングはぐっと進めやすい。
調べてわかりましたが、こんなにも原則というものが存在していたとは...
簡単にまとめるとこんな感じですね。
| 原則 | 意味 | ポイント |
|---|---|---|
| DRY | 繰り返しを避ける | 処理はまとめて一箇所に |
| SRP | 単一責任 | クラス/関数は1つの責務 |
| KISS | シンプルに | 複雑さを避ける |
| YAGNI | 必要になるまで実装しない | 過剰設計を防ぐ |
おまけ：簡単な取得処理の実装例（Laravel）
NG例（コントローラーに全部書く）
コントローラーに一連の処理を書くと結構ゴチャつきますね。
あくまで例なので処理自体は短いですが...
public function show($id)
{
$employee = DB::table('employees')->where('id', $id)->first();
if (!$employee) return response()->json(['error' => 'not found'], 404);
$department = DB::table('departments')->find($employee->department_id);
return response()->json([
'id' => $employee->id,
'name' => $employee->name,
'department' => $department?->name,
]);
}
改善例（サービスクラスに切り出す）
究極シンプルに取得処理をサービスに、あくまでコントローラーはそのサービスを使って取得するだけ。
これだけでもそれぞれが何をしているかは、さっきより細分化されてわかりやすいですね。
// Service
class EmployeeService {
public function getWithDepartment($id) {
return Employee::with('department')->find($id);
}
}
// Controller
public function show($id, EmployeeService $service)
{
$employee = $service->getWithDepartment($id);
if (!$employee) return response()->json(['error' => 'not found'], 404);
return new EmployeeResource($employee);
}
まとめ
二度目ですが、大事なのは以下３つです。
- 「動けばいい」以上に大切な原則がある
- DRY / SRP / KISS / YAGNI の4つを意識するだけでコードはぐっと読みやすくなる
- 守れなかったときはリファクタリングで改善（既存処理を壊さないように注意）
終わりに
きっかけは、実際に開発現場に入ってから基礎知識や応用知識がつき、初めて自分の過去コードを見返したときに絶望したことです。
「なんでも動けばいいってもんじゃない」と痛感しましたね...
当初はとにかく動くものを作って、クライアントに納品で手一杯でしたが、ここ最近の過程を経て品質を意識する余裕ができてきたので、今後は意識せずとも基本原則を守っていきたいです。
以上。