📖
【リーダブルコード】コード分量を減らす
🚫 無理に機能を実装しようとしない
新しいプロジェクトが始まると、テンションが上がって拡張性を意識した「すごい設計」をしようとしてしまいがちです。
しかし、実際には必要な機能を過大評価しがちで、またその実装にかかる手間を過小評価する傾向があります。
その結果、将来の修正で副作用(サイドエフェクト)が発生し、かえって保守が難しくなってしまいます。
最初から拡張性を完璧に考えるよりも、まず機能を実装 → 結果を確認 → 改善(リファクタリング)という流れの方が、集中しやすく成果も見えやすくなります。
public class FeatureBuilder {
public void build() {
// まずは動くものを作る
output();
}
private void output() {
System.out.println("まずは目に見える成果を!");
}
}
🔄 小さな機能の積み重ねが大きな成果に
- 小さな機能をしっかりと作り、それを積み重ねていくことで、より正確で安定した設計につながる。
- 抽象的な「大きな構想」から入ると、実際の開発とズレてくることがある。
- ただし、大きなビジョンをまったく持たないことも問題なので、バランスが重要。
📚 ライブラリやAPIの知識を習慣化する
「ライブラリ全体を暗記する必要はない。何があるか、ざっくり把握しておくだけで十分だ」
- 毎日15分、標準ライブラリのクラスや関数名を眺めるだけでも効果がある。
- 開発中に「これ、どこかで見たような…」と思い出せるだけでも大きな差になる。
📦 具体例:FlatList(React Native)
画像スライダーを作ろうとした際、ユーザーのジェスチャーを追跡して座標を計算する…といった処理を考えていたが、実際には以下のような簡単なAPI一つで完了した。
<FlatList
pagingEnabled={true}
/>
このように、既に用意された機能を知らなければ、無駄にコードを書いて時間を費やしてしまうこともある。
✏️ Javaでのコード例:できるだけ短く書く
❌ 冗長なコード
if (list != null) {
if (!list.isEmpty()) {
for (String item : list) {
System.out.println(item);
}
}
}
✅ 簡潔なコード
if (list != null && !list.isEmpty()) {
list.forEach(System.out::println);
}
または Java 8 の Optional を使って:
Optional.ofNullable(list)
.filter(l -> !l.isEmpty())
.ifPresent(l -> l.forEach(System.out::println));
🧼 コードが多ければ多いほどリスクも増える
「コードの分量が多ければ、保守も難しくなる」
- 新たに書いたコードはすべてテスト・ドキュメント化・保守が必要。
- コードベースが大きくなるほど、新しい機能の追加が重くなっていく。
- できるだけ標準APIや既存ライブラリを活用し、自作コードを減らすことが鍵。
✅ 第13章のまとめ
ポイント | 内容 |
---|---|
過剰実装は避ける | まず動く機能を作り、後から改善 |
小さく始める | 小さな部品の組み合わせで安定性UP |
APIに慣れる | 毎日15分の習慣が後の効率に |
コードは少なく | 書いた分だけメンテコストが増える |
💡 実践アドバイス
- 新しいプロジェクトでは、まず動くものを目に見える形で作る。
- 毎日少しずつ、ライブラリやAPIの関数名・型定義・使い方に目を通す。
- 書くコードは、常に減らせないかを考えて設計する。
Discussion