前編では、なぜ“良いコード”を目指すのかという目的から、保守性・可読性の重要性までを森さん自身の原体験を交えて伺ってきました。（前編はこちらから）後編では、その実践にどう向き合えばいいのか、具体的な書籍の読み方の工夫や、書籍の構成意図、中堅層やレビュー担当者へのヒントも含めてお届けします。
“良いコード”に少しずつ近づくための一歩として、ぜひこの後編も読み進めてみてください。
“良いコード”への気づきを増やす入り口に
『良いコードの道しるべ - 変化に強いソフトウェアを作る原則と実践』は、読んですぐに全部理解しようとする必要はありません。究極、本のイラスト部分だけ読んで「なんとなく雰囲気をつかむ」ぐらいの読み方でも、すごく意味があると思っています。
本の中に登場するイラストは、株式会社MIXIの久野（X：@Kunodayo_oboete）さんにすごく可愛く描いていただいています。
本を読み始める前に簡単なまとめをしているnoteを読んでいただくと、全体像を掴みやすいです。
そして、なによりも大切なのは、本でキーワードや考え方を知っておいて、実際の現場やプロジェクトで「あ、これってあの本に書いてあったやつかも」と気づくこと。本を読み、実際に現場で試す。その上でたまに本を読み返す、というサイクルの繰り返しで、だんだんと“良いコード”が身についていくはずです。
とにかく小さな一歩を踏み出す
実は、この本で“良いコード”を伝えるにあたって、構成にこだわった部分があります。それは、2章から5章までの一連の流れです。なるべく読んでくれる方が自然に理解を深めていけるように意識しています。まずは小さな単位から改善をはじめ、そこから徐々にグルーピングしたり、それぞれの関係性を見て整理していくような流れになるように整理しました。
基本、「なんとなく雰囲気をつかむ」という気軽な気持ちで自由に読んでいただけたらと思いますが、2章「動くコードから意図の伝わるコードへ」から5章「絡まった依存関係を解きほぐせ」までは、ぜひ順番に読んでもらえると嬉しいです。
ただ、各章、前半の1,2は比較的わかりやすく、後半の3,4などに進むにつれて内容が専門的になっていく構成にしています。読み進めて理解がなかなか進まない部分があれば、無理して読み切らずにあとからもう一度戻ってくるぐらいの気持ちで読んでみてください。全体を一周したあと、もう一度戻ることで「あ、これはこういうことだったんだ」と理解が深まることもあると思います。まずは前の方から順に読んでみて、「ちょっと難しいな」と感じるところがあれば、思い切って飛ばしてもOKです。
変更するときこそ“良いコード”への意識が必要
そしてもうひとつこだわったのが、8章「コードは書くより変更が難しい」というパートです。内容自体は他の章と重なる部分もあるんですが、“変更にこそ注意が必要”という視点をしっかり伝えたかったので、あえて独立した章にしたこだわりのポイントです。
ここでは、プロダクト開発の中で実際に起こりがちな、“変更による崩れ”のような問題について掘り下げています。最初にコードを書くときは丁寧に設計するのに、後から機能を追加するときは、ついその場しのぎに。あとで気づいた時には、全体の整合性が崩れてしまっていた...。そんな経験がある人も多いのではないでしょうか？
この章では、そんな一見そのコードの変更自体はうまくできているように見えて、全体で見ると重複や破綻が起きてしまっている、というケースを紹介しています。既存のコードに新しい処理を追加するとき、どこで保守性が損なわれやすいのか？などを、よくあるその場しのぎについて、解決方法をステップバイステップで具体的に解説しています。
現場で「その場しのぎ」に出会った時、この本を思い出してもらえたら嬉しいなと思います。
初心者だけじゃない、レビューをする立場の方へ伝えたいこと
“本書は主に初学者の方に向けて書かれておりますが、ぜひとも中堅以上のエンジニアの方にも手に取ってもらいたいと考えています。
基本的な原則や考え方は常に重要であり、この本を基本を振り返るきっかけにしてもらえると嬉しいです。また、チーム内での情報共有や若手の育成にも役立つと考えています。”
「書籍『良いコードの道しるべ - 変化に強いソフトウェアを作る原則と実践』を出版します」より引用
僕自身も日々感じていますが、コードレビューのときの言語化ってすごく難しいと感じる方もいるんじゃないかなと思っています。
特に、確かに正しく動いてるけど、将来問題になりそうだな…という、先を見据えたレビューなどは、指摘するかどうか悩んだり、上手に伝えようとしてもレビューする手が止まってしまったり、なんてことはありませんか？そういった場面で、本を読んで、言語化の一助として活用してもらうと、現場でのコミュニケーションもしやすくなるのかなと思っています。「この原則に従ってください」というレビューだけではなく、「なぜその原則が有効なのか」を伝えるためのボキャブラリーを持っておくと、先ほどのような場面でもレビューがしやすくなると思います。僕自身、この本を書く中でそういう発見がたくさんありました。そういった背景から、まだ、レビューをする立場の方にも何かのヒントになる一冊になればいいなと思っています。
“良いコード”を書くために必要な観点はまだまだある
今回は、重要な内容に絞って、これから“良いコード”を始めようとする方にも無理なく読んでもらえる構成になるように意識しました。
ただ、コードのメンテナンス性を高め、そのプロダクトの開発を続けるために他の人や将来の自分が読んで正しく理解できるコードにするためには、本では触れていない、コードを書いたあとそれをどうリリースして運用していくかに関わる開発フローや運用面など、DevOps.の観点は欠かせません。たとえば、テストの仕組みを整えたり、CI/CDのような自動化を活用して、コードを書いてからユーザーに届くまでのサイクルをどう短くしていくか。こうした考え方も、実はコードの保守性や変更容易性にとってはすごく大事な要素のひとつです。
僕自身、まだ運用やインフラについては専門分野というほど詳しくはないのですが、この領域も“良いコード”を支える大事な視点だと感じているので、もしかしたら、次の一冊として扱う可能性があるかもしれません。
様々なAIツールの登場によってコードを書くこと自体のハードルは下がっている今。「コードを書く」だけではなくより良いプロダクト、そして今後どんどん大きくなるプロダクトを作るために必要な“良いコード”の視点を意識するようなきっかけになったらなと思います。
TechTrainメディアではこれからも、「テクノロジーを支える、すべての人のターミナルに。」を目指して、実践に根ざしたコンテンツをお届けしていきます。
書籍が気になった方は以下の森さんのnoteからぜひチェックです！
