関連サイト
本書の関連ページが用意されています。
内容紹介
多くのプログラマーは、正しいコード、つまり、動作するコードを書く方法は知っています。しかし、エクセレントなコード、つまり、うまく書かれていて、理解することが容易なコードを巧妙に作り上げる方法を知っているとは限りません。本書は、自分の仕事にこだわりを持つプログラマーを対象に、まだ誰もあなたに教えてくれていないことが書かれています。それは、この現実の世界でプログラムをどのように正しく書くかということです。
本書では、教科書が省いた部分を拾い上げます。もちろん、それは良いコードが持つ技術的かつ専門的な性質や複雑さに関することです。しかし、それだけにとどまらず、正しいコードを正しいやり方で書く方法に関することも含まれます。また、良いプログラマーと悪いプログラマーとを分ける「姿勢」についても言及します。
具体的には、「ソースコードの見栄え」「防御的コーディング手法」「プログラムを効果的にデバッグする方法」「上手な共同作業のスキル」「ソースコードの管理」といったトピックを詳しく取り上げています。さらに、プログラマーの「姿勢」や取り組みといった「プログラマーの実態」(さまざまなコードモンキー)、仕様書の作成、コードレビューの実施、期間見積もりの黒魔術などの「ソフトウェア開発プロセス」、そして、「ソフトウェア開発の方法論」「さまざまなプログラミングの規律」などの、より高度な開発プロセスについても触れています。
何より「自分の頭で考える」ことが重要ですが、各章末にはQ&Aセクションがあり、教科書として使用することも可能になっています。
※本書は、『Code Craft』(2007年12月日本語版刊行)の復刊です。
書誌情報
- 著者: Pete Goodliffe(著), 鵜飼文敏, 後藤正徳, 平林俊一, まつもとゆきひろ(監訳), (株)トップスタジオ(訳)
- 発行日: 2014-09-17 (紙書籍版発行日: 2014-09-17)
- 最終更新日: 2014-09-17
- バージョン: 1.0.0
- ページ数: 722ページ(PDF版換算)
- 対応フォーマット: PDF
- 出版社: マイナビ出版
対象読者
著者について
Pete Goodliffe
ソフトウェア開発の専門家としてソフトウェア産業のいくつもの職場を渡り歩き、さまざまなプロジェクトで数多くの言語を扱ってきた。また、プログラマーの教育と指導にも幅広い経験を持ち、ACCUの『C Vu』誌（http://www.accu.org/）で「Professionalism in Programming(プログラミングにおけるプロ意識)」という定期コラムを書いている。子供と遊ぶ時間をもっと増やせるように、質が高くてバグのないコードを書くことを楽しんでいる。
鵜飼文敏
Debian Projectオフィシャルメンバー、元Debian JP Projectリーダー、日本Linux協会前会長、The Free Software Initiative of Japan副理事長、平成15年度16年度「未踏ソフトウェア創造事業」プロジェクトマネージャー。大学院在籍中に386BSDやLinuxをPC98アーキテクチャで動かして以来、フリーなオペレーティングシステムの世界にはまる。Debian JP Project創設時のメンバーで以後Debianを中心に活動。debian.or.jpおよびlinux.or.jpなどの運用管理を行っている。『Code Reading』『Write Great Code』など監訳多数。著書に『Binary Hacks』など。
後藤正徳
Debian、GNU C LibraryやLinuxカーネルドライバなどのオープンソースソフトウェア開発プロジェクトにおいて活動を行っている。Debian Projectオフィシャル開発者、YLUG（横浜Linux Users Group）発起人。
平林俊一
WideStudio開発者。1971年生まれ。1992年東京工業大学情報工学科卒。1993年富士電機（株）に入社、1999年富士通（株）に入社。一貫して大規模ミドルウェアの開発に従事し、現在、基幹システムの通信基盤ミドルウェアの開発を行っている。また、他方ではソフトウェア開発に魅せられ、オープンソースで進めているWideStudio開発を通じ、ソフトウェア開発技術の普及に尽力している。
まつもとゆきひろ
高校生時代からのプログラミング言語おたく、オブジェクト指向おたく。1993年からRubyを開発。1997年から（株）ネットワーク応用通信研究所特別研究員としてRubyの開発をメインとして雇われている。オープンソース／フリーソフトウェアにはうるさい、自称オープンソースエバンジェリスト。最近はRubyの開発よりも文章を書いている時間のほうが長いのが悩み。鳥取県米子市出身。
目次
第1部 コードと向き合う
第1章 守りを固める
- 1.1 優れたコードを目指して
- 1.2 最悪を想定する
- 1.3 防御的プログラミングとは何か
- 1.4 広大で邪悪な世界.
- 1.5 防御的プログラミングの技法
- 1.6 制約
- 一言で言えば
- 関連項目
- 考えてみよう
第2章 見事に描かれた設計図
- 2.1 なぜ表記スタイルは重要なのか
- 2.2 コードを書き示す相手を知る
- 2.3 優れた表記スタイルとは何か
- 2.4 さまざまな中カッコスタイル
- 2.5 1つのスタイルですべてを規定する
- 2.6 社内スタイル（およびそれを適用すべき対象）
- 2.7 コーディング規約を定める
- 2.8 正義の戦い？
- 一言で言えば
- 関連項目
- 考えてみよう
第3章 名前の意義
- 3.1 適切な名前を付けることの重要性
- 3.2 名前を付ける対象
- 3.3 名前ゲーム
- 3.4 実践的な名前付けの要点
- 3.5 バラの香りも名前次第
- 一言で言えば
- 関連項目
- 考えてみよう
第4章 必要な情報を余さず書く
- 4.1 自己解説的コード
- 4.2 自己解説的コードを書くための手法
- 4.3 自己解説的コードの実践的方法論
- 一言で言えば
- 関連項目
- 考えてみよう
第5章 的確なコメント
- 5.1 コードコメントとは何か
- 5.2 コメントはどのように記述・表示されるか
- 5.3 どのくらいの数のコメントを書くべきか
- 5.4 コメントの内容として何を書くべきか
- 5.5 コードの改善例
- 5.6 コメントの表記に関する留意点
- 5.7 コメントを活用するための注意
- 一言で言えば
- 関連項目
- 考えてみよう
第6章 過ちは人の常
- 6.1 エラーは何から生まれるのか
- 6.2 エラー通知機構
- 6.3 エラーを検出する
- 6.4 エラーを処理する
- 6.5 エラーを発生させる
- 6.6 エラーに対処する
- 一言で言えば
- 関連項目
- 考えてみよう
第2部 コードの秘められた生活
第7章 プログラマーの道具箱
- 7.1 ソフトウェアツールとは何か
- 7.2 なぜツールのことを気にするのか
- 7.3 パワーツール
- 7.4 どのツールにするか
- 一言で言えば
- 関連項目
- 考えてみよう
第8章 テスト
- 8.1 現実性チェック
- 8.2 誰が、何を、いつ、なぜ
- 8.3 テストは難しくない……
- 8.4 テストの種類
- 8.5 単体テストケースの選択
- 8.6 テストを考慮した設計
- 8.7 ほら、両手放しだよ！
- 8.8 障害の外観
- 8.9 欠陥を管理できるか
- 一言で言えば
- 関連項目
- 考えてみよう
第9章 誤りの検出
- 9.1 避けがたい現実
- 9.2 野獣の本性
- 9.3 害虫駆除
- 9.4 バグハンティング
- 9.5 欠陥の修正方法
- 9.6 予防策
- 9.7 スズメバチスプレー、ナメクジ除け、ハエ取り紙
- 一言で言えば
- 関連項目
- 考えてみよう
第10章 アイツがビルドしたコード
- 10.1 言語の壁
- 10.2 ちょっと大げさな話ですが
- 10.3 ビルドをビルドする
- 10.4 良いビルドシステムの条件
- 10.5 仕組み
- 10.6 リリース
- 10.7 ビルドマスターのお仕事
- 一言で言えば
- 関連項目
- 考えてみよう
第11章 速さを追い求める
- 11.1 最適化とは何か？
- 11.2 最適ではないコードが生じる原因
- 11.3 最適化を行うべきではない理由
- 11.4 最適化を行うべき理由
- 11.5 実践的な最適化のアプローチ
- 11.6 最適化の手法
- 11.7 効率的なコードを書く
- 一言で言えば
- 関連項目
- 考えてみよう
第12章 不安の固まり
- 12.1 リスク
- 12.2 敵を知る
- 12.3 戦況
- 12.4 脆弱性の種類
- 12.5 保護の手段
- 一言で言えば
- 関連項目
- 考えてみよう
第3部 コードの形態
第13章 グランドデザイン
- 13.1 プログラミングの設計としての側面
- 13.2 何を設計するのか？
- 13.3 どうしてそんなに騒ぐのか？
- 13.4 優れたソフトウェア設計
- 13.5 コードの設計方法
- 一言で言えば
- 関連項目
- 考えてみよう
第14章 ソフトウェアアーキテクチャ
- 14.1 ソフトウェアアーキテクチャとは？
- 14.2 優れたアーキテクチャとは？
- 14.3 アーキテクチャのスタイル
- 一言で言えば
- 関連項目
- 考えてみよう
第15章 進化か革命か？
- 15.1 ソフトウェアの老朽
- 15.2 警告のサイン
- 15.3 コードはどう成長するか？
- 15.4 そんなことあり得ないのに
- 15.5 これに関して何ができるか？
- 一言で言えば
- 関連項目
- 考えてみよう
第4部 プログラマーの群れ
第16章 コードモンキー
- 16.1 モンキービジネス
- 16.2 理想的プログラマー
- 16.3 それで？
- 16.4 最も愚かな者
- 一言で言えば
- 関連項目
- 考えてみよう
第17章 チームの力
- 17.1 チームの概略
- 17.2 チーム編成
- 17.3 チームワークのためのツール
- 17.4 チームを襲う病魔
- 17.5 優れたチームワークのための個人のスキルと特質
- 17.6 チームワークの基本原則
- 17.7 チームの一生
- 一言で言えば
- 関連項目
- 考えてみよう
第18章 ソースを安全に扱う方法
- 18.1 私たちの責務
- 18.2 ソース管理
- 18.3 構成管理
- 18.4 バックアップ
- 18.5 ソースコードのリリース・公開
- 18.6 ソースの置き場所
- 一言で言えば
- 関連項目
- 考えてみよう
第5部 ソフトウェア開発プロセス
第19章 仕様の具体化
- 19.1 具体的に言うと何？
- 19.2 仕様書の種類
- 19.3 仕様書に盛り込むべき内容は？
- 19.4 仕様書執筆手順
- 19.5 なぜ仕様書を書かないのか？
- 一言で言えば
- 関連項目
- 考えてみよう
第20章 美しき獲物たちか？
- 20.1 コードレビューとは
- 20.2 いつレビューするか
- 20.3 コードレビューの実施
- 20.4 心構えをレビューする
- 20.5 完全なるコード
- 20.6 コードレビューの向こうにあるもの
- 一言で言えば
- 関連項目
- 考えてみよう
第21章 完了日は未定
- 21.1 暗闇での一突き
- 21.2 見積もりが難しい理由
- 21.3 プレッシャー
- 21.4 見積もりの実際的な方法
- 21.5 計画ゲーム
- 21.6 間に合わせる
- 一言で言えば
- 関連項目
- 考えてみよう
第6部 頂上からの眺め
第22章 プログラムのレシピ
- 22.1 プログラミングスタイル
- 22.2 レシピ：方法と目的
- 22.3 開発プロセス
- 22.4 もう十分！
- 22.5 開発プロセスの選択
- 一言で言えば
- 関連項目
- 考えてみよう
第23章 アウターリミッツ
- 23.1 アプリケーションプログラミング
- 23.2 ゲームプログラミング
- 23.3 システムプログラミング
- 23.4 組み込みプログラミング
- 23.5 分散プログラミング
- 23.6 Webアプリケーションプログラミング
- 23.7 エンタープライズプログラミング
- 23.8 数値計算プログラミング
- 23.9 まとめ
- 一言で言えば
- 関連項目
- 考えてみよう
第24章 次の行き先は？
- 24.1 これからどうするか