---
title: &quot;良いプログラム&quot; を作ろう
tags: 
author: [あずらた](https://www.docswell.com/user/azurata09)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/8ED3WXKN7G.jpg?width=480
description: &quot;良いプログラム&quot; を作ろう by あずらた
published: May 17, 25
canonical: https://www.docswell.com/s/azurata09/KYDJPR-2025-05-17-152920
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/8ED3WXKN7G.jpg)

&quot;良いプログラム&quot; を書こう
あずらた（@azurata09_）
2025年5月17日 @はこだて未来大×企業エンジニア 大LT2025


# Page. 2

![Page Image](https://bcdn.docswell.com/page/V7P49PKNE8.jpg)

あずらた (@azurata09_)
応用数学2が取れなくて留年。4年生2回目
オブジェクト指向 / ETロボコン / アジャイル / Webフロント / アイマス


# Page. 3

![Page Image](https://bcdn.docswell.com/page/2JVXM2VY7Q.jpg)

こんなプログラム、開発していませんか？
• 1ファイルがでかい
• 条件分岐が複雑
• どこで変数が更新されるかわからない
• 変更しづらい


# Page. 4

![Page Image](https://bcdn.docswell.com/page/5EGVGRLWEL.jpg)

&quot;変更しづらい&quot; プログラムは
&quot;良い&quot; プログラム ではない


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4JQ6XVYQJP.jpg)

&quot;良い&quot; プログラムならば、
&quot; 変更しやすい&quot; プログラム
である


# Page. 6

![Page Image](https://bcdn.docswell.com/page/K7446MWY71.jpg)

良いプログラムと
いえばこれ
リーダブルコードは良い本だけど、
初心者が読むにはちょっと厚い


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LJ14V8YNJG.jpg)

今日覚えてほしいこと
オブジェクト指向エクササイズ を意識しよう


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJWXLZ1ME2.jpg)

オブジェクト
指向
エクササイズ
• 1つのメソッドにつきインデントは1段階までにすること
• else 句を使用しないこと
• すべてのプリミティブ型と文字列型をラップすること
• 1行につきドットは1つまでにすること
• 名前を省略しないこと
「ThoughtWorks
アンソロジー」で
• すべてのエンティティを小さくすること
• 1つのクラスにつきインスタンス変数は2つまでにするこ
と
提唱された9つのルール
• ファーストクラスコレクションを使用すること
• Getter, Setter, プロパティを使用しないこと


# Page. 9

![Page Image](https://bcdn.docswell.com/page/4EZ6M1PME3.jpg)

今日は面白いと思ったものを
ピックアップして紹介


# Page. 10

![Page Image](https://bcdn.docswell.com/page/Y762NLM5EV.jpg)

&quot; else句を使用しないこと &quot;


# Page. 11

![Page Image](https://bcdn.docswell.com/page/G75251ZG74.jpg)

なぜelseを使わないのか？
• elseを使うとネストが深くなる
• 条件とその処理が追いにくくなる


# Page. 12

![Page Image](https://bcdn.docswell.com/page/9J24N1RD7R.jpg)

else句を使うとこうなるコードが
PurchaseResult processPurchase(User user, Item item) {
if (user != null) {
if (user.isActive()) {
if (user.hasPermission(&quot;purchase&quot;)) {
if (item != null) {
if (item.isInStock()) {
println(&quot;購入処理を実行します...&quot;);
return new PurchaseResult(&quot;SUCCESS&quot;, &quot;購入が完了しました&quot;);
} else {
return new PurchaseResult(&quot;FAILURE&quot;, &quot;商品が在庫切れです&quot;); }
} else {
return new PurchaseResult(&quot;FAILURE&quot;, &quot;無効な商品です&quot;);
}
...


# Page. 13

![Page Image](https://bcdn.docswell.com/page/DEYMPZDMEM.jpg)

平坦になる（= ネストが減る）
PurchaseResult processPurchase(User user, Item item) {
if (user == null) { return new PurchaseResult(&quot;FAILURE&quot;, &quot;無効なユーザーです&quot;); }
if (!user.isActive()) { return new PurchaseResult(&quot;FAILURE&quot;, &quot;ユーザーがアクティブではありません&quot;); }
if (!user.hasPermission(&quot;purchase&quot;)) {
return new PurchaseResult(&quot;FAILURE&quot;, &quot;購入する権限がありません&quot;);
}
if (item == null) { return new PurchaseResult(&quot;FAILURE&quot;, &quot;無効な商品です&quot;); }
if (!item.isInStock()) { return new PurchaseResult(&quot;FAILURE&quot;, &quot;商品が在庫切れです&quot;); }
println(&quot;購入処理を実行します...&quot;);
// 実際のデータベース更新や外部システム連携など...
return new PurchaseResult(&quot;SUCCESS&quot;, &quot;購入が完了しました&quot;);
}


# Page. 14

![Page Image](https://bcdn.docswell.com/page/VJNW5363J8.jpg)

フローチャートで比べると


# Page. 15

![Page Image](https://bcdn.docswell.com/page/YE9XY9LP73.jpg)

より顕著


# Page. 16

![Page Image](https://bcdn.docswell.com/page/GE8269XXED.jpg)

&quot;名前を省略しないこと&quot;


# Page. 17

![Page Image](https://bcdn.docswell.com/page/LEL29W8N7R.jpg)

なぜ名前を省略しないのか？
• 決して長い名前をつけろという意味ではない
• 長くなるような名前が関数やクラスの名前として適切か？
• 名前をつけづらいということは、複数のことを行なっている可能性が
高い
• Single Responsibility Principle（単一責任の原則）に反する


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4JM8Z96QJW.jpg)

名前を省略しないことにより、Whyが名前に
現れる
「Con gLoadParseValidator」という例を考える
設定を読み込むときのLoad→Parseは、一つの流れに見える
ただ、Validateは全く別の内容に見える
これが設定ファイルが正しく記載されているかをチェックするものなら
fi
fi
Con gSyntaxChecker みたいな名前の方が好ましい


# Page. 19

![Page Image](https://bcdn.docswell.com/page/PJR56GPKE9.jpg)

まとめ


# Page. 20

![Page Image](https://bcdn.docswell.com/page/PEXKMX35JX.jpg)

まとめ
• &quot;良い&quot; プログラムならば、&quot;変更しやすい&quot; プログラムである
• 変更しやすいプログラムにするには、オブジェクト指向エクササイズを
意識することが有用
• else句を使用しないことで、ネストを減らし、コードを読みやすくす
る
• 名前を省略しないことで、「なぜこれをしているのか」が名前に
現れる


# Page. 21

![Page Image](https://bcdn.docswell.com/page/3EK5GWYRJD.jpg)

参考文献
• ThoughtWorksアンソロジー: アジャイルとオブジェクト指向による
ソフトウェアイノベーション. オライリー・ジャパン, オーム社(発売),
2008.
[1]
• 「オブジェクト指向できていますか？ | ドクセル」, Docswell. 参照:
2025年5月17日. [Online]. 入手先: https://www.docswell.com/s/
8359686/ZN1LR7-2024-09-27-163611


