リファクタリングとは？
AI開発を楽にするコード改善術！

1. リファクタリングとは？意味と目的をまず整理しよう

1-1. リファクタリングを一言で言うと？

リファクタリングとは、プログラムの挙動は変えずに、内部のコードを整理して理解しやすくすることです。 見た目をきれいにする作業というより、後から直しやすく、壊れにくく、育てやすい構造へ整える作業と考えるとつかみやすくなります。

機能追加のたびに場当たり的に書き足していると、同じ処理が増え、長い関数が生まれ、命名もぶれていきます。すると「今は動くけれど、次に触るのが怖いコード」になりやすくなります。

だからリファクタリングは、品質のための飾りではありません。変更コストを下げるための実務スキルです。

1-2. 何を変えて、何を変えないのか

リファクタリングで変えるのは、名前、関数の分け方、責務の境界、重複の置き方のような内部構造です。 一方で変えないのは、ユーザーから見た画面の動き、入力に対する結果、公開APIの契約といった外から見た振る舞いです。

この線引きが曖昧になると、内部改善のつもりが仕様変更にすり替わってしまいます。安全に進めるコツは、「動作は据え置き、構造だけ整える」を小さな単位で守ることです。

1-3. リファクタリングの語源は？因数分解の発想とどうつながるのか

リファクタリングという言葉は、ただ「書き換える」よりも、要素を整理し直す感覚に近い言葉です。英語の refactor は factor を含み、数学の因数分解や、共通部分をくくり出す factor out のイメージと相性が良い言葉でもあります。

複雑に見えるものを、意味のある単位に分けて見通しをよくする。ぐちゃっとした処理から、名前・分割・責務・重複という基本観点を見つけて整理し直す。そう考えると、リファクタリングは「コードを因数分解する作業」として腹落ちしやすくなります。

例えば、2, 3, 5 という「因数」が整理されていれば、それを組み合わせるだけで 6, 10, 15, 60 といった多くの数字（機能）を迷わず表現できますよね。コードも同じで、共通部分をくくり出して小さな部品にしておくからこそ、新しい機能を最小限の手間で追加できるようになります。

1-4. リファクタリングで得られるメリット

• 読みやすくなる：名前と責務がそろい、初見でも追いやすくなります。
• 直しやすくなる：変更箇所を小さく絞れ、影響範囲を読みやすくなります。
• 壊しにくくなる：テストしやすい形に寄せることで、変更時の事故を減らせます。
• AIに意図が伝わりやすくなる：曖昧な命名や責務の混在が減り、修正依頼の精度が上がります。

2. リファクタリングを始めるべきサイン：「コードの不吉な匂い」とは？

2-1. コードの不吉な匂い（Code Smell）とは？具体的な匂いの代表例

Code Smell（コードの不吉な匂い）とは、コード自体が即バグだと断定できるわけではないけれど、その奥にある設計の乱れや保守しづらさを知らせるサインのことです。マーチン・ファウラー氏は Code Smell を、システムのより深い問題に対応していることが多い「表面上の兆候」として説明しており、リファクタリングの文脈でも重要な出発点として扱っています。

つまり、プログラムは今は動いていても、「このまま育てるのはつらそう」「次の修正で事故が起きそう」と感じるなら、それは保守性や品質に問題がある不吉な兆候かもしれません。匂いがあるから必ず全面改修、ではありません。ただし、匂いを放置すると変更のたびに迷いが増え、AI に修正を頼むときも意図ズレや重複提案が起きやすくなります。

大切なのは、匂いを「見た目の問題」として片付けないことです。どんな匂いか、なぜ問題か、どう直すか、AI 時代にはどう見えるかまでセットで捉えると、次の一手がかなり明確になります。

• よく見かける匂い：ほぼ同じコードがあちこちに出てくる状態です。問題は、直すたびに複数箇所を追いかける必要があり、修正漏れが起きやすいこと。改善するときは、共通部分を見つけて 1 つの関数・メソッドにまとめます。AI は似た処理をその場で複製して増やしやすいので、人間が「本当に別物か」「共通化できないか」を判断するのが重要です。
• 長すぎる匂い：1 つの関数やファイルが非常に長く、途中で何の話をしているのか見失う状態です。問題は、修正範囲が曖昧になり、影響範囲を読むだけで消耗すること。改善するときは、処理のまとまりごとに関数やクラスへ分割して短くします。長い関数は AI にとっても文脈がにごりやすく、意図しない場所まで触りやすくなります。
• 大きすぎる匂い：1 つのモジュールが取得・計算・保存・表示など多くの責務を抱え込んでいる状態です。問題は、何を直しても別の役割まで巻き込みやすいこと。改善するときは、「1 つのモジュール = 1 つの役割」に寄せるように分解します。責務が混ざった構造は、AI にとっても文脈が濁り、場当たり的な変更が起きやすくなります。
• 多すぎる匂い：ほとんど仕事をしていない中間モジュールやラッパーがたくさんあり、流れがかえって追いにくい状態です。問題は、依存関係や修正経路が見えにくくなること。改善するときは、不要な仲介を取り除き、まとめられるものは統合します。無意味な層が多いと、AI も依存関係を誤解しやすく、余計な修正提案をしやすいです。
• 名前が合わない匂い：名前から想像した動きと、実際の動きが違う状態です。問題は、読む人も AI も推測で補うしかなくなること。改善するときは、実際の役割に合わせて名前を改善し、必要なら中身の責務も調整します。曖昧な名前やズレた名前は、AI の推測を増やし、修正依頼の意図ズレを起こしやすくします。

2-2. 同じような処理が何度も出てくる（DRY）

似たような if 文、計算、表示整形が何度も出てくるなら、変更のたびに修正漏れが起きやすくなります。重複は「今は速い」ように見えて、あとで遅く返ってくる典型です。

2-3. 関数やファイルが長すぎて読みにくい

1 つの関数で取得・判定・保存・表示までやっていると、変更点を追うだけで疲れます。長さそのものより、どこで責務が切り替わっているか分からない状態が危険です。

2-4. 命名が曖昧で責務が混ざっている

data や handle のような広すぎる名前が並び、関数名から役割が読めないと、読む側も AI も意図を推測するしかなくなります。命名が曖昧なコードは、そのまま責務も曖昧であることが多いです。

※プリンシプル オブ プログラミング第4章『コードの臭い（Bad smell in code）』も参考にしてください

3. リファクタリングと「書き直し・作り直し」の違いと判断基準

3-1. 書き直しとの違い

書き直しは、同じ機能を別の書き方に置き換える広い意味で使われがちです。そこには、動作変更や実装方針の変更が混ざることもあります。

それに対してリファクタリングは、外部仕様を変えないことが前提です。成功条件も「きれいになった」ではなく、振る舞いを保ったまま内部構造が良くなったかにあります。

3-2. 作り直しとの違い

作り直しは、技術選定やアーキテクチャごと入れ替えるような大きな変更を指すことが多く、画面や振る舞いも含めて刷新される場合があります。

もちろん全面的な作り直しが必要な場面もあります。ただ、日常の改善の多くはそこまで大きくありません。まずは今のコードを小さく整えて延命できるかを見るのが、現実的な判断になりやすいです。

3-3. 迷ったときの判断基準

迷ったら、次の 3 つで切り分けると整理しやすいです。

• 外から見た動きが変わらないなら、まずリファクタリングで考える。
• 画面や仕様の結果が変わるなら、仕様変更として切り分ける。
• 構造ごと持ち替える必要があるなら、作り直しの検討に入る。

4. 【図解とコード】リファクタリングのやり方と4つの重要観点

4-1. 命名：名前だけで役割や意図が伝わるか

最初に見るなら名前です。変数・関数・ファイル名から役割が読めるようになると、コード全体の形が急に見えやすくなります。迷ったら、「何を持ち、何を返し、何のために存在するか」が名前に出ているかを確認します。

4-2. 分割：1つの関数や処理が長すぎないか

長い関数を無理に細切れにすれば良いわけではありません。ただ、取得、計算、描画、保存のように役割が切り替わる場所は、分けると読みやすさと修正しやすさが大きく上がります。

4-3. 重複の排除：共通部分を因数分解のようにくくり出せるか

重複は「今は分かりやすい」顔をして潜みますが、あとで変更漏れを生みます。ここで大事なのは、表面だけ同じコードをまとめることではなく、背後にある共通の意図を見つけることです。

たとえば 2 / 3 / 5 という因数が見えていれば、6 / 10 / 15 / 60 を組み立てやすくなりますよね。コードでも同じで、似た処理の奥にある「共通の判断」「共通の変換」「共通の責務」を見つけてくくり出すと、あとから機能を足すときも迷いにくくなります。

共通化はやりすぎても読みにくくなるので、同じ意味の処理が 2 回 3 回と出てきたら、その共通意図を言葉にしてから整理するくらいが実務では扱いやすいです。

4-4. テストと確認：壊れていないことを小さく確かめながら進める

リファクタリングは正しさの証明ではなく、壊していないことの確認が大事です。自動テストがあれば理想ですが、なくても確認手順を先に決めて、小さな差分ごとに確かめれば安全度はかなり上がります。

// 今日の売上合計を表示するボタン
document.getElementById('show-today-sales').addEventListener('click', function () {

	const resultEl = document.getElementById('today-sales-result');
	resultEl.textContent = '読み込み中...';

	// API から全売上一覧を取得
	fetch('/api/sales')
		.then(function (res) {
			if (!res.ok) {
				throw new Error('API error');
			}
			return res.json();
		})
		.then(function (data) {

			// 今日の日付文字列を作成（YYYY-MM-DD）
			const now = new Date();
			const yyyy = now.getFullYear();
			const mm = ('0' + (now.getMonth() + 1)).slice(-2);
			const dd = ('0' + now.getDate()).slice(-2);
			const todayStr = yyyy + '-' + mm + '-' + dd;

			// 今日の売上だけに絞って合計
			let total = 0;
			for (let i = 0; i < data.length; i++) {
				const row = data[i];
				if (row.date === todayStr) {
					total += row.amount;
				}
			}

			// 金額フォーマットをその場で実装
			const formatted = total
				.toString()
				.replace(/\B(?=(\d{3})+(?!\d))/g, ',');

			// 結果の HTML をここで直接組み立て
			if (total === 0) {
				resultEl.innerHTML = '<p>本日の売上はありません。</p>';
			} else {
				resultEl.innerHTML =
					'<p>本日の売上合計：<strong>' +
					formatted +
					'</strong> 円</p>';
			}
		})
		.catch(function (err) {
			console.error(err);
			resultEl.innerHTML =
				'<p class="error">売上の取得に失敗しました。</p>';
		});
});
			

// ---- ドメイン寄りの小さな関数群 --------------------------

function formatDateYYYYMMDD(date) {
	const yyyy = date.getFullYear();
	const mm = ('0' + (date.getMonth() + 1)).slice(-2);
	const dd = ('0' + date.getDate()).slice(-2);
	return `${yyyy}-${mm}-${dd}`;
}

function formatCurrencyJPY(amount) {
	return amount
		.toString()
		.replace(/\B(?=(\d{3})+(?!\d))/g, ',');
}

/**
 * 売上配列から、指定した日付の合計金額を計算する
 * @param {Array<{date: string, amount: number}>} sales
 * @param {string} targetDate YYYY-MM-DD
 */
function calculateTotalSalesForDate(sales, targetDate) {
	return sales
		.filter((row) => row.date === targetDate)
		.reduce((sum, row) => sum + row.amount, 0);
}

/**
 * API から全売上一覧を取得する
 * @returns {Promise<Array<{date: string, amount: number}>>}
 */
function fetchAllSales() {
	return fetch('/api/sales').then((res) => {
		if (!res.ok) {
			throw new Error('API error');
		}
		return res.json();
	});
}

/**
 * 計算結果を DOM に描画する
 * @param {HTMLElement} container
 * @param {number} total
 */
function renderTodaySales(container, total) {
	if (total === 0) {
		container.innerHTML = '<p>本日の売上はありません。</p>';
		return;
	}
	const formatted = formatCurrencyJPY(total);
	container.innerHTML =
		'<p>本日の売上合計：<strong>' +
		formatted +
		'</strong> 円</p>';
}

// ---- UI 側：イベントハンドラは「流れ」を組み立てるだけ --------

document.getElementById('show-today-sales').addEventListener('click', function () {
	const resultEl = document.getElementById('today-sales-result');
	resultEl.textContent = '読み込み中...';

	const todayStr = formatDateYYYYMMDD(new Date());

	fetchAllSales()
		.then((sales) => {
			const total = calculateTotalSalesForDate(sales, todayStr);
			renderTodaySales(resultEl, total);
		})
		.catch((err) => {
			console.error(err);
			resultEl.innerHTML =
				'<p class="error">売上の取得に失敗しました。</p>';
		});
});
			

// 純粋関数: 入力→出力だけを扱う
function calculateSubtotal(items) {
	return items.reduce((sum, item) => sum + item.price * item.qty, 0);
}

// I/O層: 取得や描画はここで扱う
async function showSubtotal() {
	const items = await fetchCartItems();
	const subtotal = calculateSubtotal(items);
	renderSubtotal(subtotal);
}
			

// テスト例（入力→出力）
expect(calculateSubtotal([
	{ price: 1000, qty: 2 },
	{ price: 500, qty: 1 }
])).toBe(2500);
			

5. なぜ『リファクタリングは意味ない』と誤解されるのか？

5-1. 「機能が増えないのになぜやるの？」と言われやすい理由

リファクタリングは、画面の機能が増えるわけでも、売上に直接つながるわけでもありません。だから短期の成果だけで見ると、価値が見えにくいのは事実です。

ただ実際には、次の変更を速く安全にするための下準備として効きます。価値がないのではなく、価値の出方が遅れて見えるだけです。

5-2. 仕様変更や書き直しと混同されやすいから

「ついでに仕様も変えた」「書き方も動きも一緒に変えた」という変更は、もう純粋なリファクタリングではありません。これが混ざると、内部改善の評価が難しくなり、「結局バグが増えた」と見られやすくなります。

5-3. テストなしで壊してしまい、逆効果になることがあるから

テストや確認手順なしで大きく触ると、動作を守るという前提が崩れます。その結果「意味ないどころか危ない」と感じられてしまいます。リファクタリングの価値を出すには、小さく直して小さく確かめることが欠かせません。

6. AI時代の新常識：AIと共存するリファクタリングの観点

最近は AI に実装や改修を頼む場面が増えましたが、コードの構造が曖昧だと、速く書けるほど崩れも速くなります。AI 時代のリファクタリングは、読みやすさだけでなく意図を誤解されにくい構造に整える意味も強くなっています。

6-1. AIに丸投げするとなぜコードが汚れやすいのか？

AI は局所的な修正には強い一方で、曖昧な文脈の補完では「もっともらしい追加」をしがちです。命名がぶれ、責務が混ざり、似た処理が点在しているコードほど、その傾向は強くなります。

6-2. プロンプトの精度を上げる「AIフレンドリー」な構造とは？

AIフレンドリーな構造とは、どこがロジックで、どこが I/O で、どの関数が何を担当するかがコード自体から読める構造です。前提がコードに埋まっていれば、プロンプトも短く正確にできます。

6-3. 命名：AIに意図が伝わる名前になっているか

formatCurrencyJPY や calculateTotalSalesForDate のように、対象と目的が名前に出ていると、修正依頼のズレが減ります。逆に曖昧な名前は、AI の推測余地を増やします。

6-4. 分割：修正範囲を小さく切り出せる構造か

関数分割は人間のためだけではありません。小さく切り出せると、AI にも「この関数だけ直す」「ここは触らない」と境界を示しやすくなります。

6-5. 責務：1つの関数・1つのファイルに役割を詰め込みすぎていないか

責務が混ざると、AI は関連しそうな別処理まで一緒に編集しやすくなります。ファイルや関数ごとに役割を寄せておくと、意図しない巻き込みが減ります。

6-6. 境界線：AIにテストを書かせやすい構造になっているか

AI にテストを書かせるなら、純粋関数と I/O の境界が重要です。入力と期待結果が明確なら、テスト生成もレビューも安定します。逆に DOM や通信に依存したままだと、確認コストが上がります。

6-7. モジュール：因数分解のように共通部分をくくり出せているか

AI は場当たり的なコードや、その場しのぎの追加実装を素早く作るのは得意です。一方で、似た処理の背後にある共通の意図を見つけて因数分解し、再利用しやすい形へまとめることは、人間が主導したほうがうまくいきます。

たとえば、似た計算や判定が複数の場所に散らばっているなら、「本当に別物なのか」「共通化できる考え方はないか」を見直します。こうして小さな意味のある部品へ整理しておくと、AI に修正を頼むときも影響範囲を伝えやすくなり、重複や修正漏れも減らしやすくなります。

7. 実際にやって迷ったポイントと、もちもちみかんの体験談

7-1. まずは「名前」から変えると、コードの形が見えてくる

実際に見直すとき、最初から大きく分割するより、まず名前を整えたほうが進めやすいことが多いです。名前がそろうと、どこで責務が混ざっているかが見えてきます。

7-2. 一度に大きく変えすぎると、原因追跡が難しくなる

まとめてきれいにしたくなりますが、大きく動かすほど「どこで壊れたか」が追いにくくなります。小さなコミット単位に分けたほうが、結果的に速く安全でした。

7-3. AIへの依頼単位を小さくすると、意図ズレが減る

AI に依頼するときも、「命名だけ直す」「この関数を分割する」「I/O を外へ出す」のように単位を小さくすると安定します。まとめて頼むより、意図ズレの修正コストがかなり減りました。

7-4. もちもちみかんの体験談：あれもこれも直したくなると、かえって進みにくい

もちもちみかん.com の記事やコードを見直していても、最初は「ついでにここも、あそこも」と広げたくなりがちでした。ですが実際には、最初に全部を整理しようとすると論点が増えすぎて、どこを直したかったのかがぼやけやすかったです。

特に AI と一緒に直すときは、その傾向がさらに強くなりました。命名変更・構造変更・説明文の調整を一度にまとめて頼むと、それぞれは正しそうでも、全体としては意図がずれたり、別の場所にしわ寄せが出たりします。

その途中で役に立ったのが、まず名前をそろえるという順番でした。名前が整うと、何が取得で、何が計算で、どこからどこまでが同じ責務なのかが見えやすくなります。形が見えてから分割すると、無理な抽象化を避けやすいです。

私の中では、リファクタリングは因数分解に近い感覚があります。たとえば 2 / 3 / 5 という少ない要素を意識すると、6 / 10 / 15 / 60 のような多くの数を表現できます。同じようにコードでも、共通する意図や責務をくくり出して、小さく意味のある部品に分けると、全体がぐっと整理しやすくなります。この「共通部分をくくり出す」感覚がしっくり来てから、手当たり次第に触ることが減りました。

そのため今は、まず名前を整える → 次に責務を分ける → 最後に重複や細部を整える という順で、小さく進めるようにしています。この順番にしてからは、コードの形も説明の流れも見えやすくなり、AIへの依頼もかなり安定しました。

FAQ：リファクタリングでよくある質問

Q. リファクタリングと仕様変更は何が違うの？

A. リファクタリングは外から見た動作を変えずに内部構造を整える作業です。仕様変更はユーザーから見た結果そのものを変える作業なので、目的も確認方法も別です。

Q. リファクタリングは意味ないと言われるのはなぜ？

A. 機能が増えないので短期の成果として見えにくく、仕様変更や大きな書き直しと混同されやすいからです。価値がないのではなく、次の変更を安全にする価値が見えにくいだけです。

Q. リファクタリングはいつやるのがいいの？

A. おすすめは変更の直前です。機能追加やバグ修正で触る場所を、先に少しだけ整えてから本題に入ると、影響範囲を読みやすくできます。

Q. リファクタリングの語源は何？

A. 数学の因数分解や factor out の感覚に近く、複雑に見えるものを意味のある単位へ整理し直すイメージで捉えると分かりやすいです。

Q. Code Smell（コードの不吉な匂い）って何？

A. それ自体が即バグとは限らないけれど、設計の乱れや保守しづらさが奥に潜んでいるサインです。重複、長すぎる関数、責務の混在、名前のズレなどが代表例です。

Q. テストがなくてもリファクタリングできる？

A. できます。ただし「同じ動作を保てた」と判断する物差しが必要です。自動テストがなくても、手動の確認手順を先に作って小さく進めると安全です。

Q. AIにリファクタリングを頼むとき、最初に何を伝えるべき？

A. まず「外部仕様は変えない」「どこまで触ってよいか」「命名や責務の方針」を伝えるのが重要です。依頼単位を小さくすると、ズレた差分を減らせます。

まとめ：リファクタリングは「動くコード」を「育てられるコード」に変える

リファクタリングとは、動作を変えずに内部構造を整えることです。命名、分割、重複、テストという少数の観点で見直すだけでも、コードはかなり読みやすく、直しやすくなります。

特に AI と一緒に開発する今は、意図が伝わる構造かどうかが差になります。つまりリファクタリングは、ただ整える作業ではなく、動くコードを、これからも育てられるコードへ変えるための習慣です。

おまけ：AI時代のリファクタリング・チェックリスト

• [　] 名前だけで役割や意図が伝わるか？

  変数名や関数名があいまいだと、人間もAIもコードの目的を誤解しやすくなります。まずは「何をするものか」が名前だけで読める状態を目指しましょう。

• [　] 1つの関数に役割を詰め込みすぎていないか？

  取得・計算・表示のように複数の責務が混ざっていると、修正の影響範囲が広がりやすくなります。1関数1責務を意識すると、読みやすさも直しやすさも上がります。

• [　] 同じ処理が複数箇所に散らばっていないか？

  似たような処理が点在していると、修正漏れや仕様ずれの原因になります。重複を見つけたら共通化を検討し、保守しやすい形へ寄せていきましょう。

• [　] ロジックとI/Oの境界が分かれているか？

  計算や判定のロジックと、画面表示・DB・APIなどの入出力処理が混ざると、テストしにくくなります。壊れていないことを確かめやすくするためにも、境界線を意識して分けることが大切です。

• [　] AIへの依頼単位を小さく分けているか？

  命名変更・分割・ロジック修正を一度にまとめて依頼すると、意図ずれや想定外の変更が起きやすくなります。小さな単位で依頼し、確認しながら進めるほうが安全です。

• [　] 外から見た動作を変えずに進められているか？

  リファクタリングは機能追加ではなく、構造を整える作業です。見た目の動きや仕様を変えていないかを都度確認しながら進めることで、安心して改善を積み重ねられます。

おみやげ：AIにリファクタリングを頼むときのプロンプト例

そのまま使える基本プロンプト

次のコードをリファクタリングしてください。
- 外部仕様と出力結果は変えない
- 変更範囲はこのファイル内に限定する
- 命名・責務分離・重複排除の観点で改善する
- どこをどう直したか、理由を箇条書きで説明する
- 必要ならテスト観点も最後に示す

[ここにコードを貼る]

命名だけ直したいときのプロンプト

次のコードについて、処理内容は変えずに命名だけ改善してください。
- 変数名・関数名・引数名を対象にする
- 外部仕様、返り値、呼び出し方は変えない
- なぜその名前にしたのかを簡潔に説明する
- 役割が名前とズレている箇所があれば指摘する

[ここにコードを貼る]

関数分割を頼みたいときのプロンプト

次のコードを、仕様を変えずに関数分割してください。
- 取得、計算、表示など責務ごとに分ける
- 影響範囲は最小限にする
- どの関数が何を担当するかを明示する
- 分割後に確認すべきテスト観点があれば挙げる

[ここにコードを貼る]

重複の排除を頼みたいときのプロンプト

次のコードに重複があるか確認し、仕様を変えずに整理してください。
- 表面的な共通化ではなく、共通の意図がある処理だけまとめる
- 外部仕様は変えない
- 共通化した理由と、逆に共通化しなかった箇所の理由も説明する
- 変更後に注意すべき影響範囲を示す

[ここにコードを貼る]

AIに頼むときの注意点

AI に丸投げするより、人間が意図と境界線を先に与えるほうが結果は安定します。特に「仕様は変えない」「どこまで触ってよいか」「変更理由を説明してほしい」「必要ならテスト観点も出してほしい」を最初に明示すると、差分の質がかなり上がります。

また、1 回で全部直そうとせず、命名だけ、分割だけ、重複整理だけというように依頼単位を小さくするのが実務では安全です。AI は速いですが、因数分解のように共通の意図を見つける軸は人間が握っておくほうが、最終的なコード品質は高くなります。

関連リンク

• 原則の全体像から整理したい人向け：101 の原則一覧はこちら
• 変更の波及を読む視点を補強したい人向け：結合度の意味と見方を図で確認する
• 責務のまとまりを見直したい人向け：凝集度の考え方をやさしく理解する
• 分割後のつなぎ方まで見たい人向け：疎結合に寄せるコツを学ぶ
• 命名の軸を強くしたい人向け：ドメインの考え方から言葉をそろえる
• 「コードの不吉な匂い」に気づく視点を、クイズでやさしく確認する
• 宣言的に整理する例も見たい人向け：htmx の実例集で UI 側のリファクタリング発想を広げる

関連原則 🔗

• コードの臭い(Bad smell in code)
• エントロピーの法則(Law of Entropy Increase)