関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
0.9M
各ページのテキスト
"良いプログラム" を書こう あずらた（@azurata09_） 2025年5月17日 @はこだて未来大×企業エンジニア 大LT2025
あずらた (@azurata09_) 応用数学2が取れなくて留年。4年生2回目 オブジェクト指向 / ETロボコン / アジャイル / Webフロント / アイマス
こんなプログラム、開発していませんか？ • 1ファイルがでかい • 条件分岐が複雑 • どこで変数が更新されるかわからない • 変更しづらい
"変更しづらい" プログラムは "良い" プログラム ではない
"良い" プログラムならば、 " 変更しやすい" プログラム である
良いプログラムと いえばこれ リーダブルコードは良い本だけど、 初心者が読むにはちょっと厚い
今日覚えてほしいこと オブジェクト指向エクササイズ を意識しよう
オブジェクト 指向 エクササイズ • 1つのメソッドにつきインデントは1段階までにすること • else 句を使用しないこと • すべてのプリミティブ型と文字列型をラップすること • 1行につきドットは1つまでにすること • 名前を省略しないこと 「ThoughtWorks アンソロジー」で • すべてのエンティティを小さくすること • 1つのクラスにつきインスタンス変数は2つまでにするこ と 提唱された9つのルール • ファーストクラスコレクションを使用すること • Getter, Setter, プロパティを使用しないこと
今日は面白いと思ったものを ピックアップして紹介
" else句を使用しないこと "
なぜelseを使わないのか？ • elseを使うとネストが深くなる • 条件とその処理が追いにくくなる
else句を使うとこうなるコードが
PurchaseResult processPurchase(User user, Item item) {
if (user != null) {
if (user.isActive()) {
if (user.hasPermission("purchase")) {
if (item != null) {
if (item.isInStock()) {
println("購入処理を実行します...");
return new PurchaseResult("SUCCESS", "購入が完了しました");
} else {
return new PurchaseResult("FAILURE", "商品が在庫切れです"); }
} else {
return new PurchaseResult("FAILURE", "無効な商品です");
}
...
平坦になる（= ネストが減る）
PurchaseResult processPurchase(User user, Item item) {
if (user == null) { return new PurchaseResult("FAILURE", "無効なユーザーです"); }
if (!user.isActive()) { return new PurchaseResult("FAILURE", "ユーザーがアクティブではありません"); }
if (!user.hasPermission("purchase")) {
return new PurchaseResult("FAILURE", "購入する権限がありません");
}
if (item == null) { return new PurchaseResult("FAILURE", "無効な商品です"); }
if (!item.isInStock()) { return new PurchaseResult("FAILURE", "商品が在庫切れです"); }
println("購入処理を実行します...");
// 実際のデータベース更新や外部システム連携など...
return new PurchaseResult("SUCCESS", "購入が完了しました");
}
フローチャートで比べると
より顕著
"名前を省略しないこと"
なぜ名前を省略しないのか？ • 決して長い名前をつけろという意味ではない • 長くなるような名前が関数やクラスの名前として適切か？ • 名前をつけづらいということは、複数のことを行なっている可能性が 高い • Single Responsibility Principle（単一責任の原則）に反する
名前を省略しないことにより、Whyが名前に 現れる 「Con gLoadParseValidator」という例を考える 設定を読み込むときのLoad→Parseは、一つの流れに見える ただ、Validateは全く別の内容に見える これが設定ファイルが正しく記載されているかをチェックするものなら fi fi Con gSyntaxChecker みたいな名前の方が好ましい
まとめ
まとめ • "良い" プログラムならば、"変更しやすい" プログラムである • 変更しやすいプログラムにするには、オブジェクト指向エクササイズを 意識することが有用 • else句を使用しないことで、ネストを減らし、コードを読みやすくす る • 名前を省略しないことで、「なぜこれをしているのか」が名前に 現れる
参考文献 • ThoughtWorksアンソロジー: アジャイルとオブジェクト指向による ソフトウェアイノベーション. オライリー・ジャパン, オーム社(発売), 2008. [1] • 「オブジェクト指向できていますか？ | ドクセル」, Docswell. 参照: 2025年5月17日. [Online]. 入手先: https://www.docswell.com/s/ 8359686/ZN1LR7-2024-09-27-163611