無職になってから図書館に行く機会が増えました
意外とソフトウェア系の本も充実していて、ちょこちょこ借りて読んでいます
特に最近は「AIコーディングエージェント」を利用した開発が主流になりつつあるので、プログラミング言語の解説やフレームワークの解説本よりも、テスト方法やコード品質について書かれた本を意識して読んでいます
基本情報
| 出版社 | オライリー・ジャパン |
| 出版日 | 2024/6/18 |
| ページ数 | 284ページ(ページが印刷されている最終ページ) |
総評
翻訳本のためか、非常に読みにくく脳に収まらない内容になっている
というのが正直な感想です
そのため、正直おすすめできません
読みにくさの原因として感じたのが、とにかくカタカナ語が多く登場します
特に説明のないまま多様なカタカナ語(メタファー、スキャフォールドプログラム、リグレッション、サイクロマティック複雑度、コードメトリクスなど)が登場し、わからない言葉が出てくるたびに意味を調べて、書いてある内容を理解する必要がありました
少なくとも自分にはすらすら読めるような内容ではありませんでした
そのため、読み進めても「何となくわかった気になった」だけで、「じゃぁこの章に書かれていた内容を要約してみて？」と聞かれたら、きっと自分は説明できないと思います
一通り目を通しましたが、とにかく読みにくく頭に全然入ってこなかったので別途日本のエンジニアの方が描かれた書籍を別途読もうと思いました
印象に残った部分
リファクタリングとテストコードの話
リファクタリングを行うのであればテストコードは必須なので、まずはテストコードから整備せよと本書では記載されていました
リファクタリングは「外部に対してのふるまいは変更せず、内部構造のみ変更すること」と本書では定義してました
テストをパスすることで外部への振る舞いが変更されていないことが保証されるため、リファクタリングも自信をもって行えるようになります
チームワーク
チームでの開発について、以下の手法が紹介されていました
・Gitコメントの50/72ルール
・マイクロコミット
50/72ルールは「修正内容のサマリーを50文字以内で書く。ほかの記載事項は好きなだけ記載してよいが、幅が72文字以内に収まるようにする」というルールです
このルールは英語でコメントが書かれることを想定されていると思うので、日本語のコメントを記述する場合はそのまま当てはめるのは難しいかもしれません
いずれにせよ、Gitに記載するコメントは「コミュニケーションを意識する」ことが大事で、「修正が行われた背景を記載することが重要」だと理解しました
マイクロコミットは「プログラムを修正し、ビルドが無事に通るようであればその都度コミットしましょう」という内容です
ビルドが通らないコードはコミットすべきではないとも記載されていました
細かくコミットすることで、万が一修正が失敗してもプログラムのビルドが通ったコミットまで簡単に戻すことが出来ます
（なので、ほかの人が作業するときにもコードを修正しやすい）
トラブルシューティング
トラブルシュートの面白い方法として「二分法」というものが紹介されていました
これは乱暴な言い方をすれば「問題のあるコードの内容を理解できるまで、コードを半分ずつ削除して動作を絞り込んでいく」方法です
実際にはGitのマイクロコミットを利用して、どの時点の修正で問題が発生したのか絞り込んでいくのが良いようです
最近のIDEではデバッグ実行が行えるのが当たり前なので、自分は問題が発生した場合にデバッグ実行で絞り込んでいくことが多いのですが、コードを削除することで一度に理解するコード量を削減し、より理解しやすい状態が作れそうだと感じました
以上
ということで「脳に収まるコードの書き方」という本について簡単に感想を記載しました
正直1度や2度読んだだけでは内容を理解することは難しく、襲い来るたくさんのカタカナ語を都度理解しながら読む必要があり、難易度が高い本だと感じました
ただ、上記に紹介したような、自分の知らなかったツールやテクニックも多数紹介されており、何とか理解できた範囲からでも今後の業務やソフトウェア開発に利用できそうな内容が含まれていたことも事実です
ソフトウェア開発初級者(自分も含めて)にはお勧めしにくい内容ですが、理解できる範囲で役に立ちそうなテクニックを吸収するのが良いと思いました
