give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

20年選手のエンジニアが「良いコード」を改めて学ぶために、最近の本を4冊買って読んでみた

はじめに:僕の知識はもう時代遅れかもしれない?

プログラマとして、毎日コードを読み書きし続けて約20年。
自分の中には何が良いコードで、何が悪いコードなのか、明確な基準があるし、どうして良いのか、どうして悪いのかを人に説明できる自信もあります。

が、ここ最近は「自分のこれまでの知識や経験」がその判断基準になっており、あまり積極的に新しい情報を外部からインプットしていませんでした。

ネットを見ていると「良いコードとは or 悪いコードとは」を論じてそうな新しい技術書がちょこちょこ発売されています。
もしかすると僕の知識は古くなってるかもしれない、最近の技術書を読むと僕の知らない新しい観点を学べるかもしれない、そう思って以下の4冊を購入してみました。

  • Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考(2023年2月発売)
  • Tidy First? ―個人で実践する経験主義的ソフトウェア設計(2024年12月発売)
  • 改訂新版 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方(2024年12月発売)
  • 良いコードの道しるべ 変化に強いソフトウェアを作る原則と実践 (2025年5月発売)

このエントリではこれら4冊の本を読んだ感想を書いてみます。

【もくじ】

で、どうだった?

実際読んでみた感想ですが・・・良いコード・悪いコードの基準やテクニックは、意外とあまり変わってないですね (あれ?)。

どの本も「うん、せやな」「たしかに、そう」と思う内容がほとんどで、「しまったわー、もっと早く勉強しておけば良かったわー」と思うような目新しい内容はありませんでした。

って書くと、この4冊をdisってるように聞こえるかもしれませんが、そういう意味ではありません!
あくまで「ベテランの僕から見ればだいたいわかっていたことばかり」という話であって、この業界に入って間もない若手エンジニアのみなさんが読んだら、まだまだ意識できていないポイントがたくさん載っているはずです。

ですので、これから貪欲に成長していきたいと思っている若手エンジニアのみなさんは、ぜひ手に取って読んでみてほしいです!

簡単に各書籍の紹介と感想を

が、それだけで終わってしまうと、どの本がどんな内容なのかわからないと思うので、個人的な感想とともに各書籍の内容を簡単に紹介しようと思います。
なお、書籍の紹介順は僕が考える「若手エンジニアへのオススメ順」です。

🥇良いコードの道しるべ 変化に強いソフトウェアを作る原則と実践

2025年5月に発行されたばかりの新しい本です。
今回読んだ4冊の中では一番読みやすいので、いわゆる「ジュニアエンジニア」のみなさんは、まずこの本を読んでみるのがいいと思います。

書籍内で使われている言語はKotlinですが、難しいコードは出てこないので雰囲気でだいたいわかりますし、ところどころに「Kotlin解説コラム」が入るので、Kotlinを知らない人でも大丈夫です。

僕がふだんコードレビューで指摘しているような内容がたくさん出てくるので、僕のコードレビューを受ける人は事前にこれを読んでおくといいかもしれません(苦笑)。

🥈改訂新版 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

以前からネットとかでよく見かけていたので、いつか読もう読もうと思っていたものの、後回しにし続けていたら、いつの間にか改訂版が出ていました(2024年12月発売)。

さすがベストセラーになるだけあって、「あー、こういうコード、よくあるね」「そうそう、こう書き替えた方がいいよね」と同意できる内容がたくさん載っていました。よくこんなにあるある事例を集めたもんだなあ。

読む前はもっと難しい本なのかと思っていましたが、基本的な事項も多く、説明もわかりやすいので、思ったよりも易しい本だと感じました。

書籍内で使われている言語はJavaです。
各サンプルコードには詳しい説明が入るので、Javaを知らない人でもだいたいわかるはず。

あえて難点を挙げるとすれば、悪いコードのことを「悪魔」とか「クソコード」みたいに呼ぶのはちょっと言葉が強すぎるように感じたところでしょうか。
人前でそういう言葉を使うと現場の雰囲気が悪くなりそう(それって俺の書いたコードのことか?みたいに思われかねない)なので、なるべく控えましょうね。

🥉Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考

こんなコードはダメだから、こういうふうに書こう、という実践的な考え方やテクニックを豊富なサンプルコードと詳しい解説で説明してくれる本です。
書籍内で使われている言語はJavaやC#っぽい雰囲気の擬似コード。

とても実践的で詳しいんですが、そのぶんボリュームも大きく、プログラミングを始めて間もない人が読むとちょっと消化不良を起こすかもしれません😅
なので対象読者は中級者以上、っていう感じですね。

Tidy First? ―個人で実践する経験主義的ソフトウェア設計

僕みたいな歴の長いエンジニアは足を向けて寝られない大御所プログラマ、ケントベック大先生の新刊です。
どんなありがたいお話が書いてあるんだろう?と思ってワクワクしながら読んでみたのですが、短いエッセイ集みたいな感じで、なんかちょっと肩透かしをくらいました💧

第1部の「整頓」ではコーディングに関連する話題が出てくるのですが、あまり目新しい内容はなく、第2部「管理術」と第3部「理論」は、抽象的な話が多くていまいちピンと来ませんでした。

もしかすると人によっては「さすがケントベック先生!」と思うのかも(もしくは抽象的な話題も脳内でじっくり反芻するとまた感想が変わってくるのかも)しれませんが、残念ながら僕の中ではこの4冊の中では一番オススメ度が低かったです……。(すいません 🙏)

ちなみに僕はどんな本を読んできたのか?

最近出た本もそこまで大きく変わってないなあ、と思ったのであれば、じゃあ僕自身はどんな技術書を読んできたんでしょうか?
ちょっとこれまでに読んだ本を振り返って、「良いコード・悪いコード」を学ぶために役立った本をピックアップしてみました。

CODE COMPLETE

今となっては「リーダブルコード」を手に取る人が多いと思いますが、僕がこの業界に入った頃はまだ「リーダブルコード」は発売されていませんでした。
CODE COMPLETEはイメージ的には「リーダブルコード」よりももっと詳しくて、もっといろんな話題をカバーしている「リーダブルコードの上位互換」みたいな本です。

この本を初めて読んだとき、良いコードと悪いコードってこんなに明確に説明できるもんなんだ!と、めちゃくちゃ衝撃を受けたのを今でもハッキリと覚えています。

リファクタリング

現在ではみんな知っている「リファクタリング」という用語を普及させた名作中の名作です。
20年前は「動いているコードは壊れるから触るな」という思想が一般的でしたが、「動いているコードでも、もっときれいにできるなら書き直せ=リファクタリングしろ」という考え方はかなりエポックメイキングでした。
単に改善のテクニックを説明するだけでなく、パターン化(カタログ化)している点も素晴らしいですね。

達人プログラマー

Don't Repeat Yourself、いわゆる「DRY原則」はこの本から生まれました。
DRY原則に限らず、こんにちでは当たり前になっている、ITエンジニアのプラクティスがたくさん紹介されている本です。

増補改訂版 Java言語で学ぶデザインパターン入門

オブジェクト指向プログラミングの文脈でときどき登場する「デザインパターン」をわかりやすく解説してくれている本です。
オリジナルの書籍は「オブジェクト指向における再利用のためのデザインパターン」という本なのですが、Javaで易しく説明してくれている結城浩先生バージョンの方が僕としてはお勧めです。

デザインパターンはたくさんあるので全部覚えなくてもいいですが、ファクトリメソッド、デコレータ、ファサード、プロキシ、アダプタ、コマンド、ステート、ストラテジー、テンプレートメソッドあたりは日常業務でもたまに使ったりするので、教養として頭の片隅に入れておくのがいいと思います。

アジャイルソフトウェア開発の奥義 第2版

「単一責任の原則(SRP)」「オープン・クローズドの原則(OCP)」「パッケージ設計の原則」など、ある程度規模の大きいプログラムをきれいに整理整頓しやすくするための原理・原則を詳しく教えてくれる本です。

こういった話題は今回僕が読んだ本にも載っていました。
なので、僕が読むと「あー、それ知ってる〜!」となるわけですね。

ふつうのHaskellプログラミング

純粋な関数型言語を学ぶと、値が不変であることや、関数に副作用がないことのメリット(というかむしろ、変更可能な値や副作用を持つ関数のリスク)を感じ取ることができ、日々のプログラミングにおける意識が変わります。
Rubyのような非関数型言語を使うときでも、「値はなるべく不変にすること」「メソッドには副作用は持たせないこと」といった心がけを徹底すれば、堅牢でバグを起こしにくいプログラムを書くことができます。

ちなみに:僕が期待してた内容ってどんなの?

たとえば、最近ではGoやRust、Reactといった言語やフレームワークが流行しています(あ、もはや最近とは言わない?)。
こうした言語やフレームワークは、僕がこれまで慣れ親しんできたJava、C#、Ruby、Ruby on Railsなどとはパラダイムが結構異なるイメージがあります(実はそうでもない??)。

なので、こういった言語やフレームワークが主流になってきたことで、世間一般の「良いコード・悪いコード」の基準もこうした言語やフレームワークに合わせて変わってきてるんじゃないかな?と予想していました。
今回僕が読んだ4冊の本に期待していたのはそういった「新しい時代の良いコード・悪いコードの判断基準」です(が、特段変わっていなかった💧)。

でも、僕が期待していた内容は、きっと「GoやRust(あるいはReact)におけるベストプラクティス」でしかなく、言語やフレームワークを限定せずに「良いコード・悪いコード」として一般化できるほどの共通性は持っていないのかもしれませんね。

ちなみに、今月発売された「Software Design 2025年7月号」にはRustの入門記事が載っていて、ふだんRustを使っていない僕としては「へえ〜、これが巷でときどき耳にする所有権ってやつかあ」と勉強になりました(このレベルの知識でどうもすいません 😅)。

余談:「良いコード・悪いコード」の将来?

最近では生成AIにコードを読み書きさせる事例が増えてきています。
もしかすると数年後には「良いコード・悪いコード」の基準が「人間が読み書きしやすいコード」ではなく、「AIが読み書きしやすいコード」に移り変わっていくのかもしれないなあ、とぼんやり考えたりしています。

なので数年後こそ、「ヤバい、僕の知識は完全に古くなってた!!😱」と慌てることになるのかもしれません。(さて、どうなるやら??)

まとめ

というわけで、このエントリでは最近僕が買った「良いコード」を改めて学ぶための技術書を4冊紹介してみました。

良いコードと悪いコードの判断基準はしっかり自分の中にありますか?
なぜそのコードが良いのか、なぜそのコードが悪いのか、自分の言葉でしっかり説明できますか?

上の質問に自信をもって「YES」と答えられなかった人は、ぜひこのエントリで紹介した技術書を手に取ってみてください!

あわせて読みたい

新しい技術は次から次に登場してきますが、エンジニアとして基礎となる部分については、意外と賞味期限が長かったりします。
その昔書いた以下のエントリも、もしかすると今のみなさんの参考になるかもしれません。
blog.jnito.com
blog.jnito.com

あ、そういえば去年もこんな本(「プログラマー脳」と「脳に収まるコードの書き方」)を読んでましたね。
blog.jnito.com

【書評】開発チームのコードレビューをより改善したい人に!「Looks Good To Me」を読んでみた

はじめに

はてなブックマークを見ていて「お、なんか気になる本!」と思った「Looks Good To Me」を買って読んでみました。

ちなみに届いた本を手に取ったときの感想は「意外と分厚いな」でした。

でも、すごく読みやすくて、サクサクとページをめくっていくことができました!

どんな本?対象読者は?

「Looks Good To Me」はコードレビューに関するプロセスや文化、仕組み作りなどを詳しく解説した本です。

僕が考えるに、本書はこういう人が読むといいんじゃないかなーと思いました。

  • 開発チーム内にコードレビューの文化がなく、これから導入したいと思っている人
  • コードレビューは形式的にはやっているものの、いまいちしっくり来てなかったり、いろいろストレスを抱えたりしていて、もっと改善したい人

僕の感想

本書の冒頭で「『Looks Good To Me』は、コードレビューの教科書となることを目指して執筆されました」と書いてありますが、まさにその通りで、「コードレビューをこれから始めたい」もしくは「コードレビューをもっと良くしていきたい」と考えている人にとっては、あれも、これも、それも、コードレビューに関するイロハがふんだんに詰め込まれています。

僕も本書を読みながら、「うんうん、せやな、そーやな」と首を何度も縦に振りながら読みました。

プルリクは小さく!小さく!小さく!(大事なことなので3回)

中でも僕が一番首を大きく縦に振ったのは、58ページの以下の部分です。

扱いやすいPRとは……
信頼できるガイドラインの1つは、合計500行を超えるコードを提出しないことです。

(略)

もう1つの信頼できるガイドラインは、PRで変更されたファイルの合計数を20未満に抑えることです。

これは僕もほぼ同じことを考えていて、プルリクのdiffは300行以下に、変更されたファイルは30ファイル以下に抑えるのが良いと思っています。
以前僕が執筆した以下の記事にもその話を書いています。

絶対的な基準があるわけではありませんが、筆者は経験的に以下の範囲に収まっていれば許容範囲かなと考えています。

  • File changedは30ファイル以下
  • 追加された行数は300行以下
調査をサクサク進めるために。伊藤淳一が考える「良いプルリクエスト、悪いプルリクエスト」 | レバテックラボ(レバテックLAB)

微妙に数字は違うものの、感覚的にはだいたい同意見と考えて差し支えないでしょう。

そう、プルリクは小さくしないといけません!
diffの行数は多くても300〜500行程度、変更されたファイルは20〜30件程度に抑えましょう!!
頼むから1000行を超えるようなプルリクはやめてね 🥺

コードレビューするときの技術的な観点は少なめだった

一方、僕が本書に期待していたのはもう少しテクニカルな内容でした。
レビュアーがプルリクのコードと対峙する際の脳内分析とでも言うんでしょうか?
言葉で説明するのが少し難しいですが、

  • コードレビューするときはコードのどういうポイントに着目するべきか
  • コードレビューするときはどういう順番でコードを読み進めていけばいいか
  • コードに関する典型的な指摘事項にはどんなものがあるのか

といった内容を具体的なコード例とともに説明してくれたら嬉しかったなーと思いました。

もちろん、本書ではそうした内容にも触れられてはいるのですが、割合としてはわずかです。
冒頭にも書いたとおり、本書はコードレビューのプロセスや仕組み作り(ツールを使った自動化等)にフォーカスを当てている印象です。

僕が働いている株式会社ソニックガーデンでは、本書で書かれているような取り組みはだいたいすでにやっていて、僕自身、コードレビューのプロセスについては大きな不満は持っていません。
ですので、本書を読んでいて「うん、そのとおり」とか「やっぱりそうだよね」と思うことはあっても、「それは知らなかった!」と思うような目新しい内容はあまりありませんでした。

とはいえ、それはあくまで僕の場合です。
みなさんは「うちのコードレビュー、なんかうまく回ってない気がするんだよなあ……」と思っているかもしれません。
そういう人にとっては、本書を読むことで改善のヒントが見つかるんじゃないかなと思います!

「伝わるコードレビュー」と被る内容もあった

コードレビューといえば、先日「伝わるコードレビュー」という本も発売されました。
この本については以下のエントリで書評を書いています。

blog.jnito.com

「伝わるコードレビュー」はテキストコミュニケーションにフォーカスを当てた本です。
PRのdescriptionや、レビューコメントのやりとりについて、どう書けばわかりやすくなるのか、どういう言葉遣いをすればお互い気持ちよくコミュニケーションできるのか、といったポイントを解説しています。

「Looks Good To Me」でも「Chapter 6 効果的なコードレビューコメントの作成」で同じようなテーマが語られています。
たとえば「あなた(You)」で始まるレビューコメントは、攻撃的なトーンとして捉えられやすいそうです。へ〜、知らなかった!

「伝わるコードレビュー」を読んだときは、「こういう本が必要になるのって、日本人エンジニア特有なのかな〜」と思ったりしていたのですが、そんなことはなく、世界共通みたいですね。
テキストコミュニケーション、ムズカシイw

まとめ

というわけで、今回は書籍「Looks Good To Me」の感想を書いてみました。

何度も書いているとおり、「コードレビューの文化やプロセスをこれから導入したい」とか「うちのコードレビューはもっと上手にやれるはずだ」と思っている人にとっては、打ってつけの一冊だと思います。

より洗練されたコードレビューのプロセスや仕組み作りを目指している人は、ぜひ本書を手に取ってみてください!

あわせて読みたい

こちらは以前僕が執筆した、「良いプルリク、悪いプルリク」に関する記事です。
プルリクとコードレビューは切っても切れない関係だと思うので、こちらもあわせてどうぞ!
levtech.jp

レビューコメントのやりとりでギクシャクしがち、という人は「伝わるコードレビュー」もお勧めです。
blog.jnito.com

【書評】もっといいコメントの書き方がわかる!『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』

はじめに

翔泳社さんより、『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』をご恵贈いただきました。

実はこの本は発売前から気になっていて、Amazonですでに予約購入していました。
ところが今回、翔泳社さんから本書を贈ってもらえることができたので、僕としては願ったり叶ったりでした😄
翔泳社さん、どうもありがとうございます!

どんな本なのか?

ひとことで言うと、プルリク上でITエンジニア同士が交わすテキストコミュニケーションに関する本です。

「こういうコメントはGOOD」「こういうコメントはBAD(なのでこう改善しましょう)」といったコードレビュー上のポイントが、豊富な具体例とともに説明されています。

どんな人におすすめか?

これはズバリ、実務に入ったばかりの新人エンジニアさんですね!
コードレビューをする側(レビュアー)よりも、される側(レビュイー)に回ることが多いITエンジニアのみなさんにおすすめです。

「コードレビューって何?」「レビューコメントが付いたけど、どう対処すればいいの??」と右往左往している新人エンジニアさんは、本書を読むことでコードレビューに対する向き合い方や心の準備ができるようになると思います。

一方、本書はレビュイーだけでなく、レビュアーにもお勧めです。
なぜなら「こういうコメントは書いちゃダメ」という、レビュアー向けのNG例とその改善策もたくさん載っているからです。

最近レビューする側にも回るようになった人は、本書を読むことで「そういえばあのコメントはわかりにくかったかも」とか「ああいう書き方をすると、相手を萎縮させちゃったかもしれないなあ」といった反省点が見つかったりするんじゃないかなーと思います。

僕の感想:あるあるパターンの連続!開発チーム全員で読んでおくと良さそう

僕が本書に別名を付けるなら「コードレビューあるある大全」と名付けたいです。

というのも、本書を読む進めていくと、「あるある!」「あー、これもよくある!」と、次から次に過去に自分も遭遇したことのあるコードレビューコメントの例が登場したからです。
「よくこんなにあるある事例を集めてきたな〜」と感心するほどです。

こういったNGパターンは、おそらくどの現場でもよく見かける光景なんでしょうね。
ですので、きっとこのブログを読んでいるあなたの現場でも絶対に役立つ情報が載っているはずです。

コードレビューを必須にしている現場で働いているみなさんは、開発メンバー全員で本書を読むといいと思います。
とくに、輪読会形式で読んでいくと「これはうちでもよくあるよね」とか「今度からみんなでこの点に気を付けよう!」といった具合に、参加者同士で話が盛り上がりそうな予感がします 😄

その他、思ったことなど

かわいいイラストが多くて読みやすい

「本を読むのが苦手」「文字ばっかり読むのはしんどい」と考えている人も大丈夫!
かわいいイラストがたくさん載っていて、普段本をあまり読まない人もすっと理解できるような構成になっています。


コード例はRubyが多め(でも誰でも読める)

執筆者がRuby界隈の方たちなので、コード例はRubyやRailsを想定したものが多かったです。
とはいえ、コードが主役の本ではないので、Rubyプログラマ以外の人が読んでもまったく問題ありません。

テクニカルな話は少なめ

本書を読む前は「コードレビュー全般に関する本」だと思っていましたが、実際に読んでみると「コードレビューにおけるテキストコミュニケーションに特化した本」だとわかりました。
なので「コードレビューするときは、こういう観点でコードをチェックしよう」というようなテクニカルな話は本書には出てきません。
個人的にはそういう話も読みたかった、というか、僕が書きたいな!!

一方、ソニックガーデンのコードレビューでは……

ちなみに弊社ソニックガーデンではこんなに丁寧ではなく、もっと殺伐としたやりとりが交わされています(苦笑)。

というと、「めっちゃ怖い」と思われるかもしれませんが、これはレビュアーもレビュイーもどちらも優れたプログラマで、なおかつお互いを技術者としてリスペクトしあえているからです。
加えて、普段からよくZoom等で話していて、お互いの人となりがよくわかっているから、という側面もあります。

つまり、互いに気を遣わなくてもよい関係性を構築できているので、コードレビューのコメント自体はシンプルで素っ気ないものになることが多いです。

たとえば、こんな感じですね。

素っ気ないコメントでもお互いに気分を害さないのであれば、コードレビューにかける時間も短くて済むので効率的です。

まとめ

というわけで、今回は『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』の感想を書いてみました。

コードレビューコメントに特化した本というのは、おそらく今までなかったと思います。
今までなかったけど、コードレビューの文化は日本のIT業界にかなり浸透してきているはずです。
ですので、「コードレビューやってます」という現場で働いているITエンジニアは全員必読の一冊、と言っても過言ではないかもしれません。

若手ITエンジニアのみなさんはもちろん、ベテランエンジニアのみなさんもプルリク上のテキストコミュニケーションを見直すために、本書を一度手に取ってみることをお勧めします!

あわせて読みたい

これに関連して、良いコミットや良いプルリクエストに関する議論を僕も以前、レバテックラボさんのサイトに寄稿しました。
「伝わるコードレビュー」とあわせて、こちらもぜひチェックしてみてください。

levtech.jp

levtech.jp

なお、個人的なコードレビューの極意は「自分のことを棚に上げる」ですw

qiita.com