関連サイト
本書の関連ページが用意されています。
内容紹介
動くコードを書くことは実はさほど難しくありません。大事なのは書いたコードを他の人や将来の自分が読んで正しく理解できることです。それが、継続的な開発をスムーズに進める鍵となります。
本書では、簡単に変更できる保守性が高いコードを「良いコード」と定義し、そのようなコードを書くための原則や手法を解説します。
まず、「なぜ良いコードを書く必要があるのか」という根本的な問いからスタートし、命名、コメント、関数やクラスの分割、ディレクトリやモジュールの整理といった基本要素を順を追って解説。さらに、アプリケーション全体のアーキテクチャ設計や自動化テスト、チーム開発にも触れ、コードの保守性を高めるための最低限の知識をこの一冊で網羅します。
■本書のねらいと想定読者（本書の「はじめに」より抜粋）
本書ではコードの保守性を上げる方法を複数紹介しますが、決して真新しい方法は出てきません。その代わり、ソフトウェア開発における「基本」であり、今なお重要な原則や手法に焦点を当てています。誤解されやすいもの、理解や実践が難しい原則については、思い切って省略したものもあります。厳選された重要な原則について、具体的な例を交えながら、すぐに実践できるよう丁寧に解説をしています。
本書の主な読者として想定しているのは、コードを書き始めてから数年以内の若手エンジニアです。より良いコードを書くための実践的なスキルだけでなく、なぜ良いコードを書く必要があるのか、どうしてその原則が有用なのか、といった目的や背景まで理解する助けとなることを目指しています。
一方、経験豊富なエンジニアの方にとっては、本書の内容はありきたりに感じるかもしれません。しかし、基本的な原則は常に重要であり続けます。これを機に、基本を振り返る機会としてご活用いただければ幸いです。また、チーム内での情報共有の一環としても、本書が少しでもお役に立てればと思っています。
書誌情報
- 著者: 森 篤史, 久野 文菜
- 発行日: 2025-05-29
- 最終更新日: 2025-05-29
- バージョン: 1.0.0
- ページ数: 336ページ(PDF換算)
- 対応フォーマット: PDF
- 出版社: マイナビ出版
対象読者
著者について
森 篤史
LINE ヤフー株式会社所属、Android アプリエンジニア。山口県に生まれ、幼少期は兵庫県で過ごす。明石工業高等専門学校に入学後、プログラミングを学び始める。複数のプログラミングコンテストで受賞する一方、継続的な開発の難しさや大切さに気がつく。現在はコミュニケーションアプリ「LINE」のAndroid 版の開発に携わる。2019 年度未踏IT 人材発掘・育成事業スーパークリエータ。
久野 文菜
1997 年、愛知県名古屋市生まれ。幼少期よりドラえもんに魅了され、その影響でドラえもんや秘密道具の創造を夢見てプログラミングの世界に足を踏み入れた。株式会社ミクシィ（現MIXI）に新卒入社後、新規事業の開発を経て、現在はmixi2 のクライアントアプリ開発を担当。さらに、技術者としての経験を活かし、イラスト制作にも取り組んでいる。2019 年度未踏IT 人材発掘・育成事業スーパークリエータ。
目次
Chapter 1 なぜ良いコードを書くのか
- 1.1 ソフトウェアの価値
- 1.2 保守性とスピード
- 1.3 技術的負債の発生と解消
- 1.4 良いコードを書くために
Chapter 2 動くコードから意図の伝わるコードへ
- 2.1 意図を表現する
- 2.2 名前で伝える
- 2.3 コメントで補足する
- 2.4 ドメイン知識をコードで表現する
Chapter 3 大きな問題は分割して考えよう
- 3.1 関数やクラスを分ける
- 3.2 詳細を読まなくても使えるようにする
- 3.3 コードの複雑度を計測する
- 3.4 凝集度を高める
Chapter 4 コードの分類術
- 4.1 ディレクトリ単位での整理
- 4.2 モジュール単位での整理
Chapter 5 絡まった依存関係を解きほぐせ
- 5.1 依存を意識する
- 5.2 依存の方向
- 5.3 抽象に依存させる
- 5.4 結合度を低くする
Chapter 6 良いコードを書く原則・教訓
- 6.1 KISS原則: シンプルに保つ
- 6.2 YAGNI原則: 必要になるまで実装しない
- 6.3 DRY原則: 重複する知識を減らす
- 6.4 車輪の再発明：同じものを作らない
- 6.5 ハンマーしか持っていなければ、すべてが釘のように見える
- 6.6 銀の弾丸などない
Chapter 7 うっかりミスを防ぐために
- 7.1 マジックナンバーを避ける
- 7.2 型による制限を有効活用する
- 7.3 変更できないデータを使う
- 7.4 データを一箇所で管理する
- 7.5 状態の変更と情報の取得を分ける
Chapter 8 コードは書くよりも変更するほうが難しい
- 8.1 ボーイスカウトルール：来たときよりも美しく
- 8.2 ゼロベースでコードを考える
- 8.3 少しずつ変更する
- 8.4 いらなくなったコードを削除する
Chapter 9 アーキテクチャを考える
- 9.1 レイヤを整理する
- 9.2 レイヤ構成のアイデア
- 9.3 機能に着目して分割する
- 9.4 アーキテクチャを考えるということ
Chapter 10 壊さないための自動化テスト
- 10.1 手動テストの限界と自動化
- 10.2 自動化テストの種類
- 10.3 単体テストを書く
- 10.4 依存しているコードを偽物に差し替える
- 10.5 テストカバレッジを計測する
- 10.6 結合テスト/E2Eテスト
Chapter 11 チームで書く良いコード
- 11.1 Git でバージョン管理
- 11.2 コードレビューを行う
- 11.3 コーディング規約を作る
- 11.4 自動でチェックする
- 11.5 設計書を作る