良いコードを書く技術
読みやすく保守しやすいプログラミング作法
読みやすく保守しやすいプログラミング作法
書籍「良いコードを書く技術」から分かるポイントをまとめます。
読みやすく保守しやすいプログラミング作法
本書は[増補改訂]良いコードを書く技術として、2011年の初版から10年ぶりに改訂されたものです。
10年前の初版から人気を博し、改訂版が出る直前までもプログラマーのバイブルと愛されている本です。
時代の変化の特に激しいIT業界の書籍の中で今尚愛されているということから、それほど基礎や基本といった本質的な情報が載っているということがわかります。
増補改訂の主な更新点は以下のとおりです。
- コード例を執筆時点の最新版であるJava15に対応（ライブラリやフレームワークも更新）
- データ構造の理解を深めるために、第7章「データ構造」を新規に書き下ろし
- 第11章「メタプログラミング」の題材の外部DSLを、導入が手軽で保守性が高い内部DSLに変更
こんな方におすすめです。
- よりよい美しいコードを書きたい人
- 一度プログラムを書いてみたものの、本当にこれでいいのかと疑問を感じる人
- 人の書いたコードが読みづらいと感じる人
- リファクタリングを必要としている初級〜中級プログラマー
- 新人や後輩へ指導しなければならない立場の先輩・上司
- 保守をする部署へ移動になったプログラマー
ポイント
良いコードとは何か？
そして良いコードの基本でもある名前付けについて、本書からわかることについてまとめます。
良いコードとは
これが本質的で一番大事なポイントです。
ここが抜けていると、テクニックに溺れたり、先人の悪習に飲み込まれる恐れがあります。
良いコードの定義
本書の前提にもなりますが、以下の４つを満たすものを良いコードとします。
- 保守性が高い
- すばやく効率的に動作する
- 正確に動作する
- 無駄な部分がない
他人が見て理解できるコードであるべきです。
将来自分が見ることになったとしても、記憶に期待はできず初見同然であることを知っておきましょう。
似たような実装がいくつか考えられるときに、効率が悪い必要はありません。
良いコードは適切なパフォーマンスで動作します。
確実に動作するという信頼性が高いことが良いコードの条件です。この値がくるはずと決めつけることをせず、不正な値がきても被害を受けないような防御をしっかりすべきです。不測のバグを回避できます。
無駄がないコードは、理解するのも修正するのも簡単で時間がかからないため良いコードといえます。
上記の定義に沿って、本書の章立ては以下のような構成になっています。
ここでは基本中の基本となる名前付けの部分にフォーカスして紹介したいと思います。
名前付け
良いコードは良い名前から生まれます。
変数名、メソッド名、クラス名などの名前は基本中の基本です。
良い名前の条件
良い名前の条件とは、説明的で意味・意図を表していることです。
良い変数名、メソッド名、クラス名は、コメントを見なくとも名前だけで役割が理解できます。
逆に悪い名前は読む人に混乱を与え、勘違いを生み、バグの発生につながります。
例えば以下のコードはどうでしょうか。
String s = fmt(value);
out.println(s);変数名のsとvalue、メソッド名のfmtが短すぎて名前だけでは何の役割を持つのかがわかりません。
では詳しくするために以下のコードであればどうでしょうか。
String formattedConsumptionTax = insertGroupingSeparators(consumptionTax);
out.println(formattedConsumptionTax);今度は意味や役割の理解がしやすくなっています。
しかし、いささか長すぎて可読性が落ちてしまいます。
次のコードではどうでしょうか。
String formattedTax = insertGroupSeps(consumptionTax);
out.println(formattedTax);ずいぶんすっきりしてコードが読みやすくなりました。
このように、意味や役割がわかるようにしつつ、省略する場合は本来の意味を失わないようにすることが大事です。
一貫性がある
一貫したポリシーで名前付けをしましょう。例えば以下のとおりです。
- 対称性を持つ
- begin/end、write/read、on/offなど
- 単語の組み合わせ方を一貫させる
- scoreAvg、scoreAverage、avgScoreなどが混在しないこと
英語でつけられている
- オレオレ単語を作らない
- 日本人がよく間違える例で「regist」があります。実際にregistという単語は存在せず、正しくはregisterです。
- スペルミスに注意する
- 自信がない単語があれば、辞書サイトで調べてスペルミスのないようにしましょう。
- 誤訳に気をつける
- 翻訳サイトを使用すると、直訳されてしまい意図の異なる単語を使ってしまう恐れがあります。例えば、音楽を再生するメソッドを作るために「再生」で翻訳すると「reproduction（複製品、復元）」が翻訳されてしまうことがあります。「play」でよいはずが全く異なる意味になってしまいます。
イディオムに従っている
言語ごと、対象領域ごと、会社やチームごとに命名に関するイディオム（慣習）があります。例えばJavaであればメソッド名は小文字から始まるのが標準的ですが、C#では大文字から始まります。C++ではメンバ変数に接頭辞「m_」を付けるのが一般的です。
コーディング標準に従っている
プロジェクトでコーディング標準や命名規約を定めてチームメンバー全員が合せていくことが重要です。
プログラミング言語ごとにコーディング標準が公開されていることがあるので、そちらも参考にしましょう。
まとめ
本書では具体的な良いコードだけでなく、心構えや習慣についても触れられています。
最後に習慣について簡単にまとめておきます。
- よく読む
- GitHubなどにあるオープンソースのコードリーディングをたくさんしてみましょう。
- よく書く
- 初心者はコードの写経もよいでしょう。とにかくコピペで済まさず手を動かしましょう。
- 道具を磨く
- 統合開発環境やエディタ、バージョン管理などのツールや自動化、OSなどを駆使して、最高のパフォーマンスが出せる環境を整えましょう。
- よく知る
- 書籍やリファレンス、仕様書や情報系のWebサイトより良い情報を得るようにしましょう。
- よく聞く
- コードレビューを受けたり、コミュニティーや勉強会に参加し、アウトプットに対するフィードバックをもらうようにしましょう。
目次
- 良いコードとは何か
- 良いコードの定義と価値
- 良いコードの定義
- 良いコードの価値
- 代表者の声
- まとめ
- 良いコードを書くための5つの習慣
- 良いコードは1日にしてならず
- 習慣その1 読む ── コードを読んで読んで、読みまくれ!
- 習慣その2 書く ── とにかくコードを書こう
- 習慣その3 道具を磨く ── 使う道具は常に磨いておこう
- 習慣その4 知る ── 良い知識を得よう
- 習慣その5 聞く ── アウトプットと人からのフィードバックでさらなる成長を
- まとめ
- 名前付け
- 良いコードは良い名前から生まれる
- 代表者の声
- 良い名前の条件
- 変数名
- メソッド名
- クラス名
- パッケージ/ネームスペース名
- プロジェクト名
- まとめ
- スコープ
- スコープを意識していますか?
- スコープって何?
- スコープを小さくして覚えておくことを減らそう!
- 代表者の声
- 変数のスコープ
- メソッドのスコープ
- クラスのスコープ
- キャストを使用した可視性の制御
- より大きな粒度のスコープ
- まとめ
- コードの分割
- 適切な長さにコードを分割する
- なぜコードを分割するのか
- 代表者の声
- 2つの方向からの分割
- お題 クライアントにXMLを返すWeb APIの処理を分割する
- ステップ1 ベタなコードで書いてみる
- ステップ2 共通処理をメソッドに抽出して分割する
- ステップ3 処理単位で分割する
- ステップ4 状態を持つ処理をクラスに抽出して分割する
- まとめ
- コードの集約
- コードの重複は悪
- 代表者の声
- メソッドに抽出してまとめる
- 継承でまとめる
- ユーティリティクラスにまとめる
- サービス層にまとめる
- オブジェクトにまとめる
- 定数にまとめる
- 列挙型(enum)にまとめる
- まとめ
- データ構造
- データ構造で勝負が決まる
- 代表者の声
- データ構造とは?
- データ構造の指針
- お題 美容室の予約画面のHTMLを出力する
- ステップ1 データベースのデータ構造をそのまま利用する
- ステップ2 処理に最適なデータ構造を把握する
- ステップ3 最適なデータ構造に変換して利用する
- まとめ
- コードのパフォーマンス
- パフォーマンスを意識していますか?
- 代表者の声
- パフォーマンスは計算量で決まる
- パフォーマンスチューニングの手順
- アルゴリズムの選択以外のパフォーマンスチューニング
- パフォーマンスチューニングの指針
- まとめ
- ユニットテスト
- テストはお好きですか?
- ユニットテストって何?
- 代表者の声
- ユニットテストの効能
- お題 Webアプリケーションのセキュリティテスト
- ステップ1 データベースにテストデータを登録する
- ステップ2 画面の実装
- ステップ3 画面のユニットテスト(正常系)
- ステップ4 画面のユニットテスト(異常系)
- ユニットテストの指針
- まとめ
- 抽象化
- 抽象化がプログラミングのパワーを最大化する
- 配列/リストって何?
- 配列/リストを利用した抽象化とは?
- 代表者の声
- お題 画像ファイルの一覧を表示するWebアプリケーション
- ステップ1 ベタなコードで書いてみる
- ステップ2 可読性を高めるためのメソッド抽出
- ステップ3 関連するデータのデータ構造を整理
- ステップ4 配列/リスト化して抽象化
- 抽象化の指針
- まとめ
- メタプログラミング
- プログラミングをプログラミングする
- 代表者の声
- メタプログラミングって何?
- お題 Javaコードを使った内部DSL
- ステップ1 ベタなコードで書いてみる
- ステップ2 メタデータを内部DSLに移動する
- ステップ3 変換ルールに対応する
- まとめ
- フレームワークを作ろう
- フレームワークの動作原理を知る
- 代表者の声
- お題 Webアプリケーションフレームワークを作ろう
- ステップ1 素のサーブレットで書いてみる
- ステップ2 フロントコントローラとアクションクラスの導入
- ステップ3 ルーティング情報の外部ファイル化
- ステップ4 よく使う処理を簡単に実行できるように共通化する
- ステップ5 フレームワークをパッケージ化する
- まとめ
【内容情報】
読みやすく保守しやすい「良いコード」の書き方を解説した入門書です。
本書を読むと，良いコードを書くための習慣から，名前の付け方，コードの分割や集約を行う方法，抽象化の作法，計算量とアルゴリズム，ユニットテストやメタプログラミング，そして簡単なフレームワークの自作まで，プログラマーとして長く役立つ基本が身に付きます。
2011年に刊行し，大好評を博した初版を，10年ぶりに改訂しました。
改訂版では，コード例をモダン化したほか，第7章「データ構造」を新たに書き下ろしました。
10年ぶりの改訂であるにも関わらず，本書の根幹は驚くほど変わっていません。
それはすなわち，基礎や基本といった本質的な知識は，陳腐化しないということです。【著者情報】
良いコードを書く技術 読みやすく保守しやすいプログラミング作法 内容紹介より
縣俊貴（あがたとしたか）
学生時代にMSXで制限された環境でのプログラミングの楽しさを学ぶ。
以来，オープンソースのWiki実装「MobWiki」の開発や受託開発，プロジェクト管理ツール「Backlog」，ドローツール「Cacoo」などコラボレーション型Webサービスの企画と製品開発を経て，現職の株式会社ADliveではWebマーケティング関連の製品開発やコンサルティングを行う。
