コーディング原則とは？DRY・KISS・YAGNI・SOLIDを初心者向けに具体例で解説

はじめに

プログラミングを学び始めると、「動くコードは書けるけれど、これで本当に良いのかわからない」と感じることがあります。

たとえば、同じような処理を何度も書いてしまったり、機能を追加するたびにコードが複雑になったり、少し修正しただけで別の場所にバグが出たりすることがあります。

そのような問題を減らすために役立つ考え方が、コーディング原則です。

コーディング原則とは、読みやすく、修正しやすく、保守しやすいコードを書くための基本的な考え方です。代表的なものには、DRY、KISS、YAGNI、SOLIDなどがあります。

この記事では、初心者にもわかりやすいように、コーディング原則の意味やメリット、具体的なコード例、実務での使い方を解説します。

1. コーディング原則とは？初心者にもわかる基本の考え方

1-1. コーディング原則の意味

コーディング原則とは、良いコードを書くための判断基準です。

ここでいう「良いコード」とは、単に動くコードのことではありません。次のような特徴を持つコードです。

読みやすいこと、修正しやすいこと、バグを見つけやすいこと、他の人が理解しやすいこと、将来的に保守しやすいことです。

プログラムは一度書いて終わりではありません。機能追加、仕様変更、バグ修正、リファクタリングなど、あとから何度も手を加えることが多いです。

そのため、コーディングでは「今動くか」だけでなく、「あとから変更しやすいか」も重要になります。

コーディング原則は、そのための道しるべになります。

1-2. なぜコーディング原則を学ぶ必要があるのか

初心者のうちは、まずコードを動かすことが大切です。しかし、ある程度コードが書けるようになると、次のような悩みが出てきます。

同じ処理を何度も書いてしまう、コードが長くなって読みにくい、どこを修正すればよいかわからない、修正したら別の場所が壊れる、チームメンバーにコードの意図が伝わらない。

このような問題は、コーディング原則を意識することで減らせます。

たとえば、DRY原則を知っていれば、同じ処理を何度も書く前に「関数にまとめられないか」と考えられます。KISS原則を知っていれば、複雑な書き方よりもシンプルな書き方を選びやすくなります。

つまり、コーディング原則を学ぶことは、ただ知識を増やすことではなく、コードを書くときの考え方を身につけることです。

1-3. コーディング原則は「正解」ではなく判断基準である

コーディング原則を学ぶときに大切なのは、原則を絶対的なルールだと思い込まないことです。

たとえば、DRY原則は「重複を避ける」という考え方ですが、似ている処理を何でも無理に共通化すればよいわけではありません。無理に共通化すると、かえってコードが読みにくくなる場合があります。

KISS原則も同じです。シンプルなコードは重要ですが、必要な設計まで省いてしまうと、あとから変更しにくくなることがあります。

コーディング原則は、必ず守らなければならない法律のようなものではありません。状況に応じて、より良い判断をするための考え方です。

「この原則を使うと、今のコードは本当に良くなるのか？」と考えることが大切です。

1-4. 初心者が最初に押さえるべき4つの原則

初心者がまず押さえておきたい代表的なコーディング原則は、次の4つです。

DRYは、同じことを繰り返さないという考え方です。重複したコードを減らし、修正漏れを防ぎます。

KISSは、できるだけシンプルに書くという考え方です。複雑な処理や過剰な設計を避け、読みやすいコードを目指します。

YAGNIは、今必要ない機能は作らないという考え方です。将来使うかもしれないという理由だけで、不要な機能を先回りして実装しないようにします。

SOLIDは、オブジェクト指向設計に関する5つの原則です。特にクラス設計や大きなアプリケーション開発で役立ちます。

まずは、KISS、DRY、YAGNIを日々のコーディングで意識し、設計が複雑になってきたらSOLIDを学ぶと理解しやすくなります。

2. コーディング原則を守るメリット

2-1. コードが読みやすくなる

コーディング原則を意識すると、コードの意図が伝わりやすくなります。

たとえば、処理が長くなりすぎた場合は関数に分ける、変数名をわかりやすくする、複雑な条件式を整理する、といった改善ができます。

読みやすいコードは、自分にとっても他人にとっても大きなメリットがあります。

コードを書いた直後は内容を覚えていても、数週間後や数か月後に見返すと、なぜそのように書いたのかわからなくなることがあります。読みやすいコードであれば、時間が経っても理解しやすくなります。

2-2. 修正や機能追加がしやすくなる

コーディング原則を守ったコードは、変更に強くなります。

たとえば、同じ処理が複数の場所に書かれている場合、仕様変更があるとすべての場所を修正しなければなりません。修正漏れがあると、バグの原因になります。

一方、共通処理を関数やクラスにまとめていれば、修正箇所を少なくできます。

また、役割ごとにコードが整理されていれば、新しい機能を追加するときにも、どこに書けばよいか判断しやすくなります。

2-3. バグを見つけやすくなる

複雑で読みにくいコードは、バグの原因を探すのが大変です。

条件分岐が多すぎる、関数が長すぎる、1つのクラスが多くの役割を持ちすぎている、といったコードでは、どこで問題が起きているのか追いにくくなります。

コーディング原則を意識してコードを整理すると、処理の流れがわかりやすくなります。その結果、バグが起きたときにも原因を特定しやすくなります。

特にKISS原則は、バグを減らすうえで重要です。シンプルなコードほど、想定外の動きが起きにくくなります。

2-4. チーム開発で認識を合わせやすくなる

チーム開発では、自分以外の人がコードを読むことが前提になります。

そのため、自分だけが理解できるコードでは不十分です。チーム全体で読みやすく、修正しやすいコードを書く必要があります。

コーディング原則は、チームでコードの良し悪しを話し合うときの共通言語になります。

たとえば、コードレビューで「この処理はDRYにできそうです」「ここはKISSを優先してシンプルに書いたほうがよさそうです」といった会話ができます。

感覚だけで指摘するよりも、原則に基づいて話すことで、認識を合わせやすくなります。

2-5. 将来的な保守コストを下げられる

コードは書く時間よりも、読む時間や修正する時間のほうが長くなることがあります。

最初に雑に書いたコードは、短期的には早く完成するかもしれません。しかし、あとから修正しにくくなり、結果的に大きなコストがかかることがあります。

コーディング原則を意識しておくと、将来的な保守コストを下げられます。

もちろん、最初から完璧な設計を目指す必要はありません。大切なのは、必要以上に複雑にせず、変更しやすい状態を保つことです。

3. DRY原則とは？同じコードを繰り返さない考え方

3-1. DRYの意味

DRYは「Don’t Repeat Yourself」の略です。日本語では「同じことを繰り返すな」という意味で使われます。

DRY原則では、同じ知識や同じ処理を複数の場所に書かないことを重視します。

たとえば、消費税込み価格を計算する処理が複数の場所に書かれていると、税率が変わったときにすべての場所を修正しなければなりません。

このような重複を避け、1か所にまとめることで、修正漏れやバグを防ぎやすくなります。

3-2. DRY原則が重要な理由

DRY原則が重要なのは、重複したコードが保守性を下げるからです。

同じ処理が3か所に書かれている場合、仕様変更があると3か所を修正する必要があります。1か所でも修正を忘れると、動作に違いが出てしまいます。

また、似たようなコードが増えると、どれが正しい処理なのかわかりにくくなります。

DRY原則を意識すると、共通処理を関数やクラスにまとめられるため、コード全体の見通しが良くなります。

3-3. DRY原則を守れていないコード例

次のコードは、税込み価格を計算する処理が重複しています。

JavaScript
const productPrice = 1000;
const productPriceWithTax = productPrice * 1.1;

const servicePrice = 3000;
const servicePriceWithTax = servicePrice * 1.1;

const deliveryPrice = 500;
const deliveryPriceWithTax = deliveryPrice * 1.1;

console.log(productPriceWithTax);
console.log(servicePriceWithTax);
console.log(deliveryPriceWithTax);

このコードでは、税率の 1.1 が複数の場所に書かれています。

もし税率が変わった場合、すべての 1.1 を修正しなければなりません。修正漏れが起きる可能性があります。

3-4. DRY原則を意識した改善例

DRY原則を意識すると、税込み価格を計算する処理を関数にまとめられます。

JavaScript
function addTax(price) {
  return price * 1.1;
}

const productPrice = 1000;
const servicePrice = 3000;
const deliveryPrice = 500;

console.log(addTax(productPrice));
console.log(addTax(servicePrice));
console.log(addTax(deliveryPrice));

このようにすると、税込み計算の処理が1か所にまとまります。

さらに、税率を定数にすると、より修正しやすくなります。

JavaScript
const TAX_RATE = 1.1;

function addTax(price) {
  return price * TAX_RATE;
}

税率が変わった場合も、TAX_RATE を修正するだけで済みます。

3-5. DRY原則をやりすぎると起きる失敗

DRY原則は便利ですが、やりすぎには注意が必要です。

たとえば、たまたま似ているだけの処理を無理に共通化すると、あとから片方だけ仕様が変わったときに修正しにくくなります。

次のようなケースです。

JavaScript
function formatText(text) {
  return text.trim().toLowerCase();
}

この関数を、ユーザー名の整形にも、商品コードの整形にも使っていたとします。

最初は同じ処理でよくても、あとから「ユーザー名は小文字にするが、商品コードは大文字を保持したい」という仕様になるかもしれません。

その場合、無理に共通化していると修正が難しくなります。

DRY原則を使うときは、「本当に同じ意味の処理なのか」を考えることが大切です。見た目が似ているだけで共通化するのではなく、同じ理由で変更される処理をまとめるのがポイントです。

4. KISS原則とは？シンプルなコードを書く考え方

4-1. KISSの意味

KISSは「Keep It Simple, Stupid」の略として知られています。日本語では「シンプルに保とう」という意味で使われます。

コーディングにおけるKISS原則は、必要以上に複雑なコードを書かないという考え方です。

難しい書き方や高度なテクニックを使うことが、必ずしも良いコードにつながるわけではありません。

むしろ、誰が読んでも理解しやすいシンプルなコードのほうが、実務では価値があります。

4-2. 複雑なコードが問題になる理由

複雑なコードは、読む人に負担をかけます。

たとえば、1行に多くの処理が詰め込まれていたり、条件分岐が深くなりすぎていたり、抽象化されすぎて処理の流れが追えなかったりすると、理解に時間がかかります。

コードが複雑になると、次のような問題が起きやすくなります。

修正箇所を間違える、バグに気づきにくくなる、コードレビューに時間がかかる、新しいメンバーが理解しにくい、テストしにくくなる。

KISS原則を意識することで、こうした問題を減らせます。

4-3. KISS原則を守れていないコード例

次のコードは、成人かどうかを判定するだけの処理ですが、少し読みにくくなっています。

JavaScript
function checkUserStatus(user) {
  return user && user.age && user.age >= 20 ? true : false;
}

短く書かれていますが、三項演算子や不要な true : false があり、少し回りくどい印象です。

また、user.age が 0 の場合に意図しない判定になる可能性もあります。

4-4. KISS原則を意識した改善例

KISS原則を意識すると、次のようにシンプルに書けます。

JavaScript
function isAdult(user) {
  if (!user) {
    return false;
  }

  return user.age >= 20;
}

関数名を isAdult にすることで、「成人かどうかを判定する関数」だとわかりやすくなりました。

また、条件を無理に1行にまとめず、読みやすい形にしています。

さらに、年齢が数値かどうかも確認したい場合は、次のようにできます。

JavaScript
function isAdult(user) {
  if (!user || typeof user.age !== "number") {
    return false;
  }

  return user.age >= 20;
}

少し行数は増えましたが、処理の意図は明確になっています。

シンプルなコードとは、必ずしも短いコードではありません。読みやすく、理解しやすいコードのことです。

4-5. 初心者がシンプルなコードを書くコツ

初心者がKISS原則を意識するなら、まずは次の点を見直すと効果的です。

関数を長くしすぎない、条件分岐を深くしすぎない、難しい書き方よりも素直な書き方を選ぶ、変数名や関数名をわかりやすくする、1つの関数に複数の役割を持たせない。

たとえば、無理に1行で書くよりも、途中結果を変数に入れたほうが読みやすいことがあります。

JavaScript
const isLoggedIn = user !== null;
const hasPermission = user.role === "admin";

if (isLoggedIn && hasPermission) {
  console.log("管理画面を表示します");
}

このように、条件に名前をつけるだけでもコードは読みやすくなります。

初心者のうちは、「短く書くこと」よりも「あとから読んで理解できること」を優先しましょう。

5. YAGNI原則とは？今必要ない機能は作らない考え方

5-1. YAGNIの意味

YAGNIは「You Aren’t Gonna Need It」の略です。日本語では「それはきっと必要にならない」という意味で使われます。

コーディングにおけるYAGNI原則は、今必要ない機能を先回りして作らないという考え方です。

開発をしていると、「将来使うかもしれないから、この機能も作っておこう」と考えたくなることがあります。

しかし、実際にはその機能が使われないことも多くあります。使われないコードは、読む人の負担になり、保守コストを増やします。

5-2. 先回り実装が失敗しやすい理由

先回り実装が失敗しやすい理由は、未来の仕様を正確に予測するのが難しいからです。

「将来こうなるだろう」と思って作った機能が、実際にはまったく使われなかったり、必要になったときには別の形で求められたりすることがあります。

また、不要な機能があると、コード全体が複雑になります。

使っていない関数、不要な設定項目、未使用の分岐、過剰なクラス設計などが増えると、どれが本当に必要な処理なのかわかりにくくなります。

YAGNI原則は、今必要なものに集中するための考え方です。

5-3. YAGNI原則を守れていないコード例

次のコードは、ユーザー登録処理に将来使うかもしれない機能を先回りして追加しています。

JavaScript
function createUser(name, email, options = {}) {
  const user = {
    name: name,
    email: email,
    role: options.role || "user",
    plan: options.plan || "free",
    points: options.points || 0,
    rank: options.rank || "normal",
    referralCode: options.referralCode || null
  };

  return user;
}

一見便利そうですが、現在必要なのが name と email だけなら、他の項目は不要です。

使わない項目が多いと、コードを読む人は「この値はどこで使われるのか」と考えなければなりません。

5-4. YAGNI原則を意識した改善例

今必要な情報だけでユーザーを作成するなら、次のようにシンプルにできます。

JavaScript
function createUser(name, email) {
  return {
    name: name,
    email: email
  };
}

必要になったタイミングで、role や plan を追加すれば十分です。

もちろん、すぐに使う予定が明確にある項目なら追加しても問題ありません。しかし、「いつか使うかもしれない」という理由だけで実装するのは避けたほうがよいです。

YAGNI原則では、「今必要かどうか」を判断基準にします。

5-5. 将来を考えることとYAGNIの違い

YAGNI原則は、将来をまったく考えないという意味ではありません。

将来の変更に備えて、読みやすいコードにする、関数の責務を分ける、テストを書きやすくする、といった工夫は大切です。

ただし、まだ必要かわからない機能まで作り込む必要はありません。

将来を考えることと、先回りして不要な機能を作ることは別です。

良い設計とは、未来のすべてを予測することではなく、必要になったときに変更しやすい状態を保つことです。

6. SOLID原則とは？オブジェクト指向設計の基本原則

6-1. SOLID原則の概要

SOLID原則とは、オブジェクト指向設計で使われる5つの原則の頭文字をまとめたものです。

Sは単一責任の原則、Oはオープン・クローズドの原則、Lはリスコフの置換原則、Iはインターフェース分離の原則、Dは依存性逆転の原則です。

SOLID原則は、特にクラスやインターフェースを使った設計で役立ちます。

初心者にとっては少し難しく感じるかもしれませんが、最初からすべてを完璧に理解する必要はありません。まずは「クラスや関数の役割を整理するための考え方」として捉えるとよいです。

6-2. 単一責任の原則：1つのクラスに1つの役割を持たせる

単一責任の原則は、1つのクラスやモジュールに1つの役割を持たせるという考え方です。

たとえば、次のクラスは、ユーザー情報の管理、バリデーション、保存、メール送信をすべて担当しています。

JavaScript
class UserService {
  createUser(user) {
    if (!user.email.includes("@")) {
      throw new Error("メールアドレスが不正です");
    }

    console.log("ユーザーをデータベースに保存しました");
    console.log(" welcomeメールを送信しました");
  }
}

このクラスは複数の責任を持っています。仕様変更があったときに、どの理由でクラスを修正しているのかわかりにくくなります。

単一責任の原則を意識すると、次のように役割を分けられます。

JavaScript
class UserValidator {
  validate(user) {
    if (!user.email.includes("@")) {
      throw new Error("メールアドレスが不正です");
    }
  }
}

class UserRepository {
  save(user) {
    console.log("ユーザーをデータベースに保存しました");
  }
}

class MailService {
  sendWelcomeMail(user) {
    console.log("welcomeメールを送信しました");
  }
}

役割を分けることで、変更の影響範囲がわかりやすくなります。

6-3. オープン・クローズドの原則：拡張しやすく変更に強くする

オープン・クローズドの原則は、拡張には開いていて、変更には閉じているべきという考え方です。

簡単に言うと、新しい機能を追加するときに、既存のコードをできるだけ変更せずに拡張できる設計を目指すということです。

たとえば、支払い方法によって処理を分けるコードを考えます。

JavaScript
function pay(type, amount) {
  if (type === "creditCard") {
    console.log(`${amount}円をクレジットカードで支払いました`);
  } else if (type === "bankTransfer") {
    console.log(`${amount}円を銀行振込で支払いました`);
  }
}

このコードでは、新しい支払い方法が増えるたびに pay 関数を変更する必要があります。

改善例として、支払い方法ごとにクラスを分けます。

JavaScript
class CreditCardPayment {
  pay(amount) {
    console.log(`${amount}円をクレジットカードで支払いました`);
  }
}

class BankTransferPayment {
  pay(amount) {
    console.log(`${amount}円を銀行振込で支払いました`);
  }
}

function processPayment(paymentMethod, amount) {
  paymentMethod.pay(amount);
}

新しい支払い方法を追加する場合は、新しいクラスを作ればよく、既存の processPayment は変更せずに済みます。

6-4. リスコフの置換原則：親クラスと子クラスの関係を正しく保つ

リスコフの置換原則は、親クラスの代わりに子クラスを使っても問題なく動くべきという考え方です。

たとえば、鳥クラスを作り、すべての鳥が飛べると仮定したとします。

JavaScript
class Bird {
  fly() {
    console.log("飛びます");
  }
}

class Penguin extends Bird {
  fly() {
    throw new Error("ペンギンは飛べません");
  }
}

この設計では、Bird を使う側が「鳥は飛べる」と期待しているのに、Penguin を渡すとエラーになります。

これは親クラスと子クラスの関係が適切ではありません。

改善するなら、飛べる鳥と飛べない鳥を分けて考えます。

JavaScript
class Bird {
  eat() {
    console.log("食べます");
  }
}

class FlyingBird extends Bird {
  fly() {
    console.log("飛びます");
  }
}

class Sparrow extends FlyingBird {}

class Penguin extends Bird {}

このようにすると、飛べないペンギンに無理に fly を持たせる必要がありません。

6-5. インターフェース分離の原則：不要な依存を減らす

インターフェース分離の原則は、使わない機能に依存させないという考え方です。

たとえば、複合機のようなインターフェースを考えます。

JavaScript
class Machine {
  print() {}
  scan() {}
  fax() {}
}

もし印刷だけできるプリンターを作りたい場合でも、scan や fax を持たなければならない設計になります。

これは不要な機能への依存です。

改善するなら、機能ごとに分けます。

JavaScript
class Printer {
  print() {}
}

class Scanner {
  scan() {}
}

class Fax {
  fax() {}
}

必要な機能だけを使えるようにすることで、クラスの役割が明確になります。

初心者は、「使わないメソッドを無理に持たせていないか」と考えるだけでも十分です。

6-6. 依存性逆転の原則：具体的な実装に依存しすぎない

依存性逆転の原則は、具体的な実装ではなく、抽象に依存するという考え方です。

少し難しく聞こえますが、簡単に言えば「特定のクラスにべったり依存しすぎないようにする」ということです。

たとえば、注文処理の中で直接メール送信クラスを作っている例です。

JavaScript
class EmailSender {
  send(message) {
    console.log(`メール送信: ${message}`);
  }
}

class OrderService {
  completeOrder() {
    const sender = new EmailSender();
    sender.send("注文が完了しました");
  }
}

このコードでは、OrderService が EmailSender に強く依存しています。

将来、メールではなくチャット通知に変えたい場合、OrderService を修正する必要があります。

改善例です。

JavaScript
class OrderService {
  constructor(notifier) {
    this.notifier = notifier;
  }

  completeOrder() {
    this.notifier.send("注文が完了しました");
  }
}

class EmailNotifier {
  send(message) {
    console.log(`メール送信: ${message}`);
  }
}

class ChatNotifier {
  send(message) {
    console.log(`チャット送信: ${message}`);
  }
}

OrderService は、具体的にメールなのかチャットなのかを知る必要がなくなりました。

このようにすると、通知方法を変更しても影響範囲を小さくできます。

6-7. 初心者はSOLID原則をどこまで理解すべきか

初心者がSOLID原則を最初から完璧に理解する必要はありません。

まずは、単一責任の原則を意識するだけでも大きな効果があります。

具体的には、1つの関数やクラスに多くの役割を詰め込みすぎないことです。

次に、条件分岐が増えすぎたときに「クラスや関数を分けたほうがよいかもしれない」と考えられるようになると、オープン・クローズドの原則も理解しやすくなります。

SOLID原則は、実際にコードを書き、設計で困った経験をしながら少しずつ理解していくものです。

7. コーディング原則を実務で使うときの優先順位

7-1. まずはKISSで読みやすさを優先する

実務でコーディング原則を使うときは、まずKISS原則を意識するのがおすすめです。

なぜなら、読みやすさはほぼすべてのコードに関係するからです。

どれだけ設計が優れていても、コードが読みにくければ保守は難しくなります。

初心者はまず、わかりやすい変数名をつける、関数を短くする、条件分岐を整理する、無理に難しい書き方をしない、といった基本を大切にしましょう。

7-2. 重複が増えてきたらDRYを意識する

次に意識したいのがDRY原則です。

ただし、最初から何でも共通化しようとする必要はありません。

コードを書いているうちに、同じ処理が何度も出てきたら、「これは関数にまとめられないか」「定数にできないか」と考えます。

目安として、同じ処理を2回書いた時点では様子を見ることもありますが、3回以上出てきたら共通化を検討するとよいです。

ただし、見た目が似ているだけの処理を無理にまとめるのは避けましょう。

7-3. 不要な機能追加を防ぐためにYAGNIを使う

実務では、納期や優先順位があります。

そのため、「いつか使うかもしれない機能」に時間をかけすぎると、本当に必要な機能の開発が遅れてしまいます。

YAGNI原則を意識すると、今必要な機能に集中できます。

たとえば、まだ管理画面で使う予定がない検索条件や、将来使うかもしれない設定項目を先回りして作る必要はありません。

必要になったときに追加しやすいよう、コードを整理しておけば十分です。

7-4. 設計が複雑になってきたらSOLIDを学ぶ

SOLID原則は、コードの規模が大きくなり、クラスやモジュールの関係が複雑になってきたときに役立ちます。

たとえば、1つのクラスが大きくなりすぎている、条件分岐が増え続けている、変更のたびに多くのファイルを修正している、といった場合は、SOLID原則を学ぶタイミングです。

最初からすべてのコードにSOLIDを厳密に適用しようとすると、かえって設計が複雑になることがあります。

まずは、必要な場面で少しずつ取り入れることが大切です。

7-5. 原則同士がぶつかったときの判断基準

コーディング原則は、ときにぶつかることがあります。

たとえば、DRYを意識して共通化すると、コードが抽象的になりすぎてKISSに反することがあります。

また、将来の拡張を考えて設計を作り込むと、YAGNIに反することがあります。

このようなときは、次のように考えると判断しやすくなります。

今のコードは読みやすいか、変更の予定は具体的にあるか、共通化する理由は明確か、チームメンバーが理解できるか、テストしやすいか。

初心者の場合は、迷ったらKISSを優先するのがおすすめです。シンプルで読みやすいコードは、あとから改善しやすいからです。

8. 初心者がコーディング原則を身につける方法

8-1. 小さなコードからリファクタリングする

コーディング原則を身につけるには、実際にコードを改善する経験が必要です。

最初から大きなアプリケーションで実践しようとすると難しいため、小さなコードから始めるのがおすすめです。

たとえば、長い関数を分ける、重複した処理を関数にする、変数名をわかりやすくする、といった小さなリファクタリングから始めましょう。

リファクタリングとは、外から見た動作を変えずに、コードの内部構造を改善することです。

動いているコードを少しずつ読みやすくすることで、コーディング原則の使い方が身につきます。

8-2. 他人の読みやすいコードを読む

自分でコードを書くことも大切ですが、他人のコードを読むことも勉強になります。

読みやすいコードを読むと、関数の分け方、命名、コメントの書き方、ファイル構成などを学べます。

特に、実務経験のある人のコードや、よくメンテナンスされているオープンソースのコードは参考になります。

ただし、最初から大規模なコードを読む必要はありません。小さなライブラリやサンプルアプリから始めるとよいです。

「なぜこの関数名なのか」「なぜここで処理を分けているのか」と考えながら読むと、コーディング原則への理解が深まります。

8-3. コードレビューで原則を意識する

コードレビューは、コーディング原則を学ぶ良い機会です。

自分では問題ないと思っていたコードでも、他の人から見ると読みにくかったり、重複があったりすることがあります。

レビューを受けるときは、指摘を単なる修正依頼として受け取るのではなく、「どのコーディング原則に関係しているのか」を考えると学びが増えます。

たとえば、「この処理は関数に分けたほうがよい」という指摘は、KISSや単一責任の原則に関係しているかもしれません。

「同じ処理が別の場所にもあります」という指摘は、DRY原則に関係しています。

コードレビューを通じて、原則を実務の判断に結びつけられるようになります。

8-4. 命名・関数分割・コメントから改善する

初心者が最初に取り組みやすい改善ポイントは、命名、関数分割、コメントです。

まず、変数名や関数名を見直しましょう。

data や result のような抽象的すぎる名前が多いと、何を表しているのかわかりにくくなります。

JavaScript
const d = 1200;

よりわかりやすくするなら、次のようにします。

JavaScript
const totalPrice = 1200;

次に、関数が長くなりすぎていないか確認します。1つの関数に複数の処理が入っている場合は、役割ごとに分けると読みやすくなります。

コメントは、コードを見ればわかることを書くのではなく、なぜその処理が必要なのかを書くと効果的です。

8-5. 完璧を目指さず少しずつ習慣化する

コーディング原則は、知ったその日から完璧に使えるものではありません。

最初は、コードを書いたあとに見直すだけでも十分です。

「同じ処理を繰り返していないか」「もっとシンプルに書けないか」「今必要ない機能を作っていないか」「1つの関数に役割を詰め込みすぎていないか」と確認してみましょう。

毎回少しずつ意識することで、自然と良いコードを書けるようになります。

完璧を目指しすぎると、コードを書く手が止まってしまいます。まずは動くコードを書き、その後で少しずつ改善していく姿勢が大切です。

9. コーディング原則でよくある失敗

9-1. 原則を暗記するだけで使えていない

コーディング原則は、名前や意味を暗記するだけでは役に立ちません。

DRY、KISS、YAGNI、SOLIDという言葉を知っていても、実際のコードでどう使うかがわからなければ意味がありません。

大切なのは、コードを書いたり読んだりするときに、原則を判断基準として使うことです。

たとえば、「このコードはDRYに反しているかもしれない」「ここはKISSを優先したほうがよさそうだ」と考える習慣を持つことが重要です。

原則は知識ではなく、実践して身につけるものです。

9-2. DRYを意識しすぎて逆に読みにくくなる

DRY原則でよくある失敗は、重複を嫌いすぎて無理な共通化をしてしまうことです。

共通化した結果、引数が多すぎる関数や、条件分岐だらけの共通関数ができることがあります。

JavaScript
function process(type, data, optionA, optionB, optionC) {
  if (type === "user") {
    // ユーザー処理
  } else if (type === "order") {
    // 注文処理
  } else if (type === "payment") {
    // 支払い処理
  }
}

このような関数は、一見DRYに見えますが、実際には責務が曖昧で読みにくくなっています。

重複をなくすこと自体が目的ではありません。コードを理解しやすく、変更しやすくすることが目的です。

9-3. SOLIDを過剰に適用して設計が複雑になる

SOLID原則は便利ですが、初心者が過剰に適用すると設計が複雑になりすぎることがあります。

小さな処理に対して、必要以上にクラスやインターフェースを分けると、かえって全体の流れが追いにくくなります。

たとえば、数行で済む処理を多くのクラスに分割してしまうと、どこで何が行われているのか理解するのに時間がかかります。

SOLID原則は、大きな設計を整理するための考え方です。小さなコードでは、まずKISSを優先し、必要になったときにSOLIDを取り入れるくらいで十分です。

9-4. YAGNIを誤解して設計を何も考えなくなる

YAGNI原則は、今必要ない機能を作らないという考え方です。

しかし、これを「将来のことは一切考えなくてよい」と誤解してはいけません。

何も考えずに場当たり的にコードを書くと、少し機能追加しただけで大きな修正が必要になることがあります。

YAGNIで避けるべきなのは、不要な機能の先回り実装です。

一方で、読みやすくする、関数を分ける、テストしやすくする、変更しやすい構造にする、といった基本的な設計は必要です。

9-5. チームのルールより個人の理想を優先してしまう

コーディング原則を学ぶと、自分の理想の書き方にこだわりたくなることがあります。

しかし、チーム開発では、個人の理想よりもチーム全体のルールや合意が重要です。

たとえば、自分はこの設計が良いと思っても、チームの既存コードと大きく違う書き方をすると、他のメンバーが理解しにくくなる可能性があります。

コーディング原則は、チームで良いコードを書くための道具です。自分の考えを押し通すためのものではありません。

コードレビューや設計相談を通じて、チームにとって最適なバランスを探すことが大切です。

10. コーディング原則に関するよくある質問

10-1. コーディング原則は初心者でも学ぶべき？

初心者でも、コーディング原則は学ぶべきです。

ただし、最初からすべてを深く理解する必要はありません。

まずは、KISS、DRY、YAGNIの3つを意識するだけでも十分です。

コードを書いたあとに、「もっと読みやすくできないか」「同じ処理を繰り返していないか」「今必要ない機能を作っていないか」と見直すだけで、コードの質は少しずつ上がります。

SOLID原則は、クラス設計やオブジェクト指向に慣れてきてから学ぶと理解しやすいです。

10-2. DRY・KISS・YAGNI・SOLIDの中で最初に学ぶべき原則は？

最初に学ぶなら、KISS原則がおすすめです。

初心者にとって最も大切なのは、読みやすくシンプルなコードを書くことだからです。

次に、同じ処理が増えてきたらDRY原則を意識します。

そして、余計な機能を作り込みすぎないためにYAGNI原則を学ぶとよいです。

SOLID原則は、コードの規模が大きくなり、クラスや設計に悩むようになってから学ぶと効果的です。

順番としては、KISS、DRY、YAGNI、SOLIDの流れが理解しやすいでしょう。

10-3. コーディング規約とコーディング原則の違いは？

コーディング規約とコーディング原則は似ていますが、意味が異なります。

コーディング規約は、コードの書き方に関する具体的なルールです。

たとえば、インデントはスペース2つにする、変数名はキャメルケースにする、1行の文字数を制限する、といったものです。

一方、コーディング原則は、良いコードを書くための考え方です。

たとえば、同じ処理を繰り返さない、シンプルに書く、不要な機能を作らない、役割を分ける、といった判断基準です。

コーディング規約は見た目や形式をそろえるためのルール、コーディング原則は設計や保守性を高めるための考え方だと捉えるとわかりやすいです。

10-4. すべての原則を必ず守る必要はある？

すべての原則を必ず守る必要はありません。

コーディング原則は、状況に応じて使う判断基準です。

たとえば、DRYを守るために共通化した結果、コードが読みにくくなるなら、あえて少し重複を残す選択もあります。

また、SOLID原則を意識しすぎて小さな処理まで細かく分割すると、かえって複雑になることがあります。

重要なのは、原則を機械的に守ることではなく、コードを読みやすく、変更しやすく、保守しやすくすることです。

10-5. 個人開発でもコーディング原則は必要？

個人開発でも、コーディング原則は必要です。

個人開発では自分しかコードを読まないと思うかもしれません。しかし、数週間後や数か月後の自分は、ほとんど他人のようなものです。

雑に書いたコードは、あとから見返したときに理解しにくくなります。

また、個人開発でも機能追加やバグ修正は発生します。コーディング原則を意識しておくと、あとから変更しやすくなります。

特に、KISSとYAGNIは個人開発でも効果的です。シンプルに作り、今必要な機能に集中することで、開発を進めやすくなります。

まとめ

コーディング原則とは、読みやすく、修正しやすく、保守しやすいコードを書くための考え方です。

代表的なコーディング原則には、DRY、KISS、YAGNI、SOLIDがあります。

DRY原則は、同じコードや同じ知識を繰り返さない考え方です。重複を減らすことで、修正漏れやバグを防ぎやすくなります。

KISS原則は、シンプルなコードを書く考え方です。難しい書き方や過剰な設計を避け、誰が読んでも理解しやすいコードを目指します。

YAGNI原則は、今必要ない機能を作らない考え方です。将来使うかもしれないという理由だけで先回り実装をすると、コードが複雑になりやすくなります。

SOLID原則は、オブジェクト指向設計で役立つ5つの原則です。特に、クラスの責任を分けたり、拡張しやすい設計を考えたりするときに役立ちます。

初心者は、まずKISSを意識して読みやすいコードを書くことから始めましょう。次に、重複が増えてきたらDRYを意識し、不要な機能を作りそうになったらYAGNIを思い出します。

SOLID原則は、設計が複雑になってきたときに少しずつ学べば問題ありません。

コーディング原則は、暗記するものではなく、実際のコードを書く中で使いながら身につけるものです。完璧を目指す必要はありません。小さな改善を積み重ねることで、読みやすく保守しやすいコードを書けるようになります。