前に買ったのですが前半だけ軽く読んだだけなので、この度は後半に絞って読みました。(良いコードを書く技術という本にて、オススメ書籍として紹介されていたので思い出しました。)

制御フロー

調査対象(変化する値)を左側に置くようにする
- if(act < exp)
否定系のifは”極力”避ける
- × if(!debug) 〇if(debug)
- よく指摘されていたのを思い出した(笑)あくまで極力です
  - あくまで極力です
感心を引く条件が先に来るようにする
三項演算子は完結になる場合のみ使う
- まずはif文を優先する
ネストは浅く
- ネストしたものは書かないってルールで書かされたこともありました
- メソッド抽出や早めに返す(return)で対応する

巨大な式を分割する

式を変数として捉えることで巨大なコードがスッキリする

説明変数
- 式が表すものを変数として格納する
要約変数
- 何度も登場してくるような条件式を変数として格納する

変数と読みやすさ

変数のスコープを縮める
- クラス変数を全て消し去るというリファクタリングをしたことがありますが、メソッド抽出→クラス分割のような手順でやっていきました。
イミュータブルな変数を利用する
- 値があちこちで変わってると追いつかなくなる

無関係の下位問題

無関係の下位問題

関数、ブロックに存在している、高レベルの目標ではない記載
- メソッド抽出して対応する個別にテスト可能になる再利用可能になる
  - 個別にテスト可能になる
  - 再利用可能になる
プログラムの核となる基本的なタスクをutilとして切り離す
- ファイル操作やハッシュテーブル、文字列操作など
- ドメインに関係しない部分

高レベルの目標

その関数が解決しようとしている目的

一度に一つのことを

コードが１つずつタスクを行うようにする

コードが行っているタスクを明確にする
- 別のメソッド、クラスに分離できるものがある
- それ以外が、そのタスクが段落になる

コードに思いを込める

コード全体で何をやってるのか説明する
- 箇条書きでいい
- 簡単な言葉でわかりやすく
説明を元にコードを改善する
- 巨大な条件式の塊の正体を明確にする

短いコードを書く

汎用的なユーティリティクラスを作る
- 処理の重複を削除する
- 無関係の下位問題を解決する
未使用や無用のクラスを削除する
- 過剰な機能を持たせない
既存のAPIなどをライブラリを読む
- 自分で実装する必要がなければしなくていい

テストと読みやすさ

テストコードを保守しやすいようにする
- 「テストコードを変更したくないから対象のコードが修正できない」は汚い
- 新しいコードが増えたらテストコードを書く品質担保
  - 品質担保
「こういう状況と入力から、こういう振る舞いと出力をする」というのがテストコードの本質
- オブジェクトの生成などは別のメソッドに移動させる
- checkHogeResult(input,exp)のようになると良い
小さいテストを複数作る

自分なりにコード改善

自分なりにコードを見直してみます。

if文の修正とテスト

以下のif文は怒られてしまうやつです

public boolean canGacha(int sub){
        if(0 > stone_amt - sub ){
            return false;
        }
        return true;
    }

条件式が見にくいので左側にactを置くようにします。

public boolean canGacha(int sub){
        if( stone_amt - sub < 0 ){
            return false;
        }
        return true;
    }

テストコードも書いてみます

class StoneTest {
    @Test
    public void test_CanGacha(){
        assertTrue(checkCanGacha(3000,3000));
        assertFalse(checkCanGacha(2999,3000));
        assertTrue(checkCanGacha(3001,3000));
        assertTrue(checkCanGacha(0,0));
        assertTrue(checkCanGacha(3000,0));
    }
    private boolean checkCanGacha(int amt, int sub){
        return makeStone(amt).canGacha(sub);
    }
    private Stone makeStone(int amt){
        Stone stone = new Stone();
        stone.add(amt);
        return stone;
    }
}

複数のロジック

ガチャを引くロジックは以下のことを行う

ユーザーデータを取得する
ユーザーがガチャを引く
キャラクターをランダムで取得する
ログを出力する

public List<CharacterDTO> play(int user_id, String gachaType) {

        UserData userData = this.userDataRepository.findById(user_id);
        if(!userData.useStone(3000)){
            throw new NotEnoughException();
        }

        this.userDataRepository.save(userData);
        List<Character> characters = this.characterRepository.getCharacters();
        // TODO factory
        Gacha gacha = new NormalGacha(characters);

        List<Character> result = gacha.getCharaceters();
        CharacterDTOMapper mapper = new CharacterDTOMapper();

        // Event
        this.logEventPublisher.call("ガチャ石を利用しました。使用数 : "+ 3000 + "使用ガチャ" + gachaType);

        return mapper.toDTOList(result);
    }

ユーザーの処理

ユーザー取得
石の使用

ガチャの処理

ガチャ作成
キャラクター取得

やり方は色々あると思いますが今回はクラス分割をしてみます。それぞれを別のアクションとして切り離してしまいます。

public List<CharacterDTO> play(int user_id, String gachaType) {
        // ユーザーが石を利用する
        this.userDataAction.useStone(user_id);
        // ガチャを引く
        List<Character> result = this.gachaAction.getCharacters();
        // イベントの発火
        this.logEventPublisher.call("ガチャ石を利用しました。使用数 : "+ 3000 + "使用ガチャ" + gachaType);
        // View用のフォーマットに変換して返却する
        return new CharacterDTOMapper().toDTOList(result);
    }

※わかりやすくコメントをつけています

最初のコードよりもガチャ引くという処理がわかりやすくなったと思います。それぞれのActionでは元々のコードをそのまま利用しています。

コード

https://github.com/jirentaicho/spring-api-gacha

終わりに

「リーダブルコード」でも「良いコードを書く技術」でも「コードリーディングの重要性」について語っています（触れています）

APIの使い方を知るために読む
書き方とか知るために読む

とにかく作れ！っていうのも大事ですが、とにかく読めってのも大事そうですね。読む量をバチバチに増やしていきたいと思います。

リーダブルコード | 読書メモ