Good Code, Bad Code ...の「読み方」をミスったかも

ポゥシュウ

2024年12月15日 01:25

良書と思います。

しかし私は読み方をミスってしまったため、「他の人が同じようなミスをしないといいな」という視点のレビュー記事です。

本書について

まず、正式タイトルは『Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考』です。

『リーダブルコード』は発刊からだいぶ時が経っていることもあり、本書が気になっている方も多いのではないでしょうか。

秀和システムの書籍紹介ページよりもAmazonの方が得られる情報が多いため、Amazonのリンクを置いておきます。
（例えば、目次を全て見ることができます）

アフィリリンクではないため安心して踏んでください。

本書の特徴

こちらは公開情報ではなく、私の所感です。

トピック毎にBad Codeを示し、その解決策としてGood Codeが示される
- あらゆる説明に具体的なコード例が伴うため、だれでも理解しやすい(はず)
「理想を述べて終わり」ではなく、実務適用への配慮が随所に見られる
- 例1. Good Code適用により生じうる副作用にも言及、対応を提示
  - 関数の入力パラメーターの変更は良くないから、インスタンスをコピーして変更しよう。但し、パフォーマンス上の理由で必要悪であることも。その場合は関数名やドキュメントで確実に表現しよう。
- 例2. 対立意見も提示する等、主張を持ちつつも原理主義的でない論調
  - 筆者は「モックの利用は最小限に抑えるべき」と考えている。
    しかし、「モックを頻繁に使用する考え方」も存在する。双方の主張は…（略）

どう「ミスった」のか

タイトルの回収です。

端的に言うと、期待値が高すぎました。

本書は、経験が3年以内のソフトウェアエンジニアをターゲットとして執筆されていますが…（略）

Amazonの紹介文より

とあり、私はターゲット層に該当していません。
ただ、「Googleでテックリードを務める著者のレベル感からすると、学びは多いだろう」と思い購入しました。

しかし、読んでみると本当に「既に知っていることが多い…」でした。

「読むのがだるい」と感じてしまった

経験3年以内のエンジニアがターゲットなので、基本的な内容もしっかり丁寧に解説する構成になっています。

当初の期待値(=意欲)こそ高かったものの、ページをめくれどめくれど新鮮な情報がほぼ出てこないため、3分の1ほど読み進めたところで「だるい」と感じてしまいました。

読書によるインプット効率を高めるためには、「価値がある」と認識することが重要と考えています。（同様のことは、『Learn Better』という書籍でも述べられています。よろしければどうぞ）

途中から「気になるトピックのみを追う読み方」に変更しましたが、一度「だるい」と思ってしまったためか、あまり響かない感じを抱えたまま読み終えてしまいました。

学びはゼロだったのか

そんなことは全くなくて、随所に学び・気づきはありました。以下例です。

beforeEachなどでテスト用の構成を共有することのリスク

共有された構成の中で、どのテストケースがどの構成に依存しているのかを追跡するのが困難であり、構成に変更が加わると、結果としてテストケースが対象のコードをテストしなくなる可能性があります。

太字箇所。
歴史あるテストコードをメンテナンスするとき、beforeEachは「触らぬ神に…」状態になりがちですが、その理由がまさにこれだなと。

言語化されたことで今後留意することができます。

テストのセットアップを共有することは諸刃の剣です。コードの重複やコストのかかるセットアップの実行を防ぐのにとても便利である一方、役に立たず、わかりにくいテストができあがるリスクもあります。適切に使えるように、慎重に検討すると良いでしょう。

「"常に正しい選択"があるわけではない」という点もしっかり補足されます。

将来の列挙値を暗黙的に処理することのリスク

通常、switch文はデフォルト(default)ケースをサポートしています。これは、未処理の値をすべてキャッチするものです。しかし、列挙型を処理するswitch文にデフォルトケースを追加すると、将来の列挙値が暗黙的に処理され、想定外の事態やバグが発生する可能性もあります。

コードのシンプルさのためについやってしまいそうですが、確かに危険です。例えば次のようなコード（コードサンプルは私のオリジナルです）

enum class CarType {
    DIESEL,
    GASOLINE,
    ELECTRIC,
    HYBRID;

    fun hasElectricMotor(): Boolean {
        return when (this) {
            ELECTRIC, HYBRID -> true
            else -> false // WARNING: 将来、PLUG_IN_HYBRIDが追加されたときに気づける？
        }
    }
}

勿論、列挙値の追加時にコードベース全体を精査することで問題を発見できますが、人間依存のアプローチはなるべく避けたいです。

※{enum}.values()と件数を使い、列挙値全ての検証を強制するようなテストを書くことでも検知できるとは思います。

実際、付箋はたくさん貼った

「完全に定着していること」はさておき、少しでも「常に意識できているか怪しいな」と感じた内容には付箋を貼りました。

どうすれば良いか

さて、期待値が高すぎたという私の失敗を踏まえ、こうすれば良いのでは？の話です。~~しらんけど~~

買う前に目次を"しっかり"見る

前述の通り、Amazonで目次を全て見ることができます。

目次をしっかり見て「良さそう！」と思えるのであれば、まず間違いないのではないでしょうか。（私はざくっとしか見なかった）

リファレンスとして使う、つもりで買う

そもそもちゃんと書いてくださっています。

本書は、経験が3年以内のソフトウェアエンジニアをターゲットとして執筆されていますが、チームで開発を行う際のリファレンスとしても利用できるでしょう。あるいは、経験のあるエンジニアであっても、自分の経験を整理し、言語化するための便覧としても使えるはずです。そして、チーム開発で、他のエンジニアをメンタリングするための便利なリソースとしても活用できます。