プログラマが知るべき 97 のこと
昨年末に話題になっていた「プログラマが知るべき 97 のこと」を読み終えた。
まず大半の項目が見開き 2 ページ (ごく一部、3 ページの項がある) に収まっている点に感心させられる。
これは前に読んだ Head First SQL でも見られた工夫。ページをめくる事なく必要十分な情報を一望できて爽快だ。見開き単位で統一されているため読了時間も予測しやすく空き時間や就寝前などに少しずつ読み進めることができた。読書を中断しても再会するトピックは見開きで完結しているため、中断前の状態を思い出さなくて済むのもよい。
もちろん本編もすばらしい。
「～べき」という表現には啓蒙とか求道的な厳しさが感じられて思わず身構えてしまうものだけど、この本の論調は一貫して優しい。啓蒙より提案であり求道のかわりに目標の提示を主眼に置いているようだ。技術ネタを肴によき先輩や仲間たちと飲んでいるような気分になる。
読み終えるまでトピック数が 100 ですべてが見開き 2 ページならば完全なのにと思ったのだが、そこをあえて崩すところにも人間味を感じる。わずかな加筆修正で完全にできるのだけど、これは意図的なのだろうか？日本語版ではトピックを 10 加えて 107 としている。これは日本人的 (仏教的？) なマジックナンバーである 108 の近似であり趣を感じる。思わず読者側からトピックをひとつ足したくなる。
こうして普通の感想を書くつもりだったのだけど、どうせならすべてのトピックについてコメントしておきたい。懐かしの自分への 100 の質問とかそんな風。というわけで以下に 97 + 10 の感想を。
プログラマが知るべき 97 のこと
1. 分別のある行動 セブ・ローズ（Seb Rose）
問題は負債のようなもので放置するほど利息がつく。BTS はそれを記録する通帳。BTS の重要性を説明するときのたとえ話がひとつ増えた。
2. 関数型プログラミングを学ぶことの重要性 エドワード・ガーソン（Edward Garson）
学びたいと思いつつ未開拓。F# あたりからはじめてみようかな。
3. ユーザが何をするかを観察する（あなたはユーザではない） ジャイルズ・カルバン（Giles Colborne）
Joel on Software でも取り上げてた話題。これは絶対にやったほうがよい。
4. コーディング規約を自動化する フィリップ・ヴァン・ラーネン（Filip van Laenen）
コーディング ルールの論争には誰もが辟易としており、いつのまにか緩い「暗黙の」規約がうまれるものだ。よくないことだと思う。規約だと守るのも面倒。フォーマッターの設定ファイルを配布する運用なら、受け入れられやすい気がする。
5. 美はシンプルさに宿る ヨルン・オルムハイム（Jorn Olmheim）
意味に拘るあまり、サイズは見過ごされがち。私も関数やメソッドは 10 行ぐらいを分割の目安にしている。
6. リファクタリングの際に注意すべきこと ラジット・アタパトゥー（Rajith Attapattu）
既存のコードが複雑すぎた場合、私は Wrapper を検討する派。非破壊で単純化できる点がメリット。包んだあとに、中身をリファクタリングしてゆく
7. 共有は慎重に ウディ・ダーハン（Udi Dahan）
ライブラリ的なものを作ってると過剰な共有や抽象化に走りがち。コンテキスト超重要。私もたくさん失敗した。
8. ボーイスカウト・ルール ロバート・C・マーティン（Robert C. Martin アンクル・ボブ）
小学校の林間学校でこのルールを教わった。あらゆる事柄に適用できる、有用な思想。
9. 他人よりまず自分を疑う アラン・ケリー（Allan Kelly）
これを心がけるだけで大半の質問は不要になる。2ch を見てると、よくそう思う。
10. ツールの選択は慎重に ジョヴァンニ・アスプローニ（Giovanni Asproni）
フリーウェアのフリーとは無料や思想ではなくインストール フリーだと思ってる。私がツール選定で最も重視するポイント。
11. ドメインの言葉を使ったコード ダン・ノース（Dan North）
typedef より変数の命名が重要。型の抽象化には有用だが意味の明示に利用しだすときりがない。名前付けが必要になったらそれを包むミニ ドメインを作るほうがよいのでは？とはいえ STL コンテナとイテレータを使うときは typedef を多用してしまうのだが。
12. コードは設計である ライアン・ブラッシュ（Ryan Brush）
本書で繰り返されるテスト コードの重要性トピックその 1。私に不足している部分なので、必ず学ぶ。
13. コードレイアウトの重要性 スティーブ・フリーマン（Steve Freeman）
コードの美観はもっと語られてもいい。視覚効果についての分析があれば読みたい。シンタックス ハイライトやコメント、視点の移動など。
14. コードレビュー マティアス・カールソン（Mattias Karlsson）
昔、在籍していたプロジェクトでもすばらしい効果があった。専用ツールよりメールでレビュー依頼 & 返信するのが気楽でよいと思う。
15. コードの論理的検証 イェッチェル・キムチ（Yechiel Kimchi）
論理的というより安全なコードの書き方。具体的で取り入れやすい。
16. コメントについてのコメント カル・エヴァンス（Cal Evans）
処理の説明ではなく目的を書く。あと doxygen などのドキュメンテーション ツールは意識したほうがいい。
17. コードに書けないことのみをコメントにする ケブリン・ヘニー（Kevlin Henney）
コードを読めばわかるという意見はこの観点が抜けてる。適切にコメントを書けば読むべきコードとそうではないものも区別しやすくなる。書かない理由ではなく、どのように読まれるかを考える。
18. 学び続ける姿勢 クリント・シャンク（Clint Shank）
学習を楽しめるのも重要。デザインのよいサイト、サービス、ツール。文章がうまい、丁寧、ユーモラスな人。そういったものを探すのにはてブが役立ってる (主に ROM だけど)。
19. 誰にとっての「利便性」か グレゴー・ホーぺ（Gregor Hohpe）
よい API の設計について。私は既存のライブラリやフレーム ワークを参考にすることが多いかな。
20. すばやくデプロイ、こまめにデプロイ スティーブ・P・バーチャック（Steve Berczuk）
インストーラ作成を担当してたことがあるので大いにうなづける。正しくインストールできたことを検証するツールも大事。
21. 技術的例外とビジネス例外を明確に区別する ダン・バーグ・ヨーンソン（Dan Bergh Johnsson）
例外についてきちんと扱えてる自信がない。なのでこのトピックのような生きた例はとてもありがたい。理解が深まった。
22. 1万時間の訓練 ジョン・ジャガー（Jon Jagger）
私はこの原則を信じている。才能、年齢、性別などは道を閉ざす要因にはならない。才能ないとかもう遅いだとかありえない。何も始めていないか十分に継続していないだけだではないか？昔、私にギターを教えてくれた人が「練習を続ければ腕が落ちることはない。つまり上手くなるだけだ」と言っていたのを思い出した。
23. ドメイン特化言語 マイケル・フンガー（Michael Hunger）
Lua とか成功例なんだろうね。自分で作る機会はなくても DSL という考え方を知るのは有用。
24. 変更を恐れない マイク・ルイス（Mike Lewis）
複雑なソフトウェアって生物のようだ。若いうちは活発で大手術にも耐えるけど年を経るとメスを入れることすら危うくなる。そんなことを思う一編。
25. 見られて恥ずかしいデータは使わないこと ロッド・ベグビー（Rod Begbie）
実例を見たことがある。確か開発者の個人名がエラー ダイアログに表示されてた。
26. 言語だけでなく文化も学ぶ アンダース・ノラス（Anders Noras）
Web 系開発のおかげで複数の言語を使う機会が増えた。カルチャー ショックもその分、受けた。これは確実にプラスだと感じている。
27. 死ぬはずのプログラムを無理に生かしておいてはいけない ヴェリティ・ストブ（Verity Stob）
ライフ サイクルは短く。そう考えると状態を持つシングルトンがどれだけ危険かよくわかる。
28. 「魔法」に頼りすぎてはいけない アラン・グリフィス（Alan Griffiths）
魔法という誤解を解くというのが重要だと思った。そのために魔法の原理を自明にする。説得力を持たすにはタスク管理システムが有用。
29. DRY原則 スティーブ・スミス（Steve Smith）
何となく知っていたけどちゃんとした説明を読んだのは初めてな気がする。
30. そのコードに触れてはならない！ カル・エヴァンス（Cal Evans）
当たり前のようでいて意外に横行してそうな問題。
31. 状態だけでなく「ふるまい」もカプセル化する アイナー・ランドル（Einar Landre）
メソッドの呼び出し順を強制するオブジェクトとかも失敗例だと思う。遅延初期化のためとはいえ initialize メソッドを設けるのも心苦しい。
32. 浮動小数点数は実数ではない チャック・アリソン（Chuck Allison）
Decimal を使う機会がないとしても丸めについては意識しておいたほうがいい。
33. オープンソースプロジェクトで夢を実現する リチャード・モンソンヘーフェル（Richard Monson-Haefel）
やっぱりみんな参加しているものなのかな？意義は理解できるけど参加したいものがない。
34. API設計の黄金律 マイケル・フェザーズ（Michael Feathers）
API を設計するときに心がけてほしいこと。やはりユニット テストは取り入れなくては。
35. 超人の神話 ライアン・ブラッシュ（Ryan Brush）
「ある人に魚を一匹与えれば、その人は一日食える。魚の取り方を教えれば、その人は一生を通して食える」ということわざを思い出した。
36. ハードワークは報われない オルヴ・モーダル（Olve Maudal）
本来なら定時すら不要。
37. バグレポートの使い方 マット・ドーア（Matt Doar）
テスターを経験してよかったと思うのはバグ レポートの書き方を学べたこと。それはちょうどここで説明されているような感じだった。
38. 余分なコードは決して書かない ピート・グッドリフ（Pete Goodliffe）
仕様書がないとやりがち。必要十分を定義しないとあらゆるコードが等価になり無尽蔵に膨らみやすい。趣味コードについて仕様書を書くべきか迷ってる。
39. 最初が肝心 マーカス・ベイカー（Marcus Baker）
ヒューリスティック テストで改善できるかな？ベストを選ぶよりワーストを避けるほうが期待値に近づけやすいと思う。
40. プロセス間通信とアプリケーションの応答時間の関係 ランディ・スタッフォード（Randy Stafford）
処理時間の短縮に成功するのは稀。そこをがんばるならキャッシュとか応答性の向上を考えたほうがよい。
41. 無駄な警告を排除する ヨハンネス・ブロドワル（Johannes Brodwall）
コンパイラの警告レベルは最大。エラー・警告は常にゼロ。これに慣れるべし。きれいな部屋の埃は目立つ。
42. コマンドラインツールを使う キャロル・ロビンソン（Carroll Robinson）
はじめは抵抗があったけど仕事や趣味で Linux に触るうちにコマンドライン ツールのよさを理解できた。 小さく完結してテキスト ベースで何でも連携できるというのはなんと便利なのだろう。なによりコマンドがそのままスクリプトになるのがすばらしい。
43. プログラミング言語は複数習得すべき ラッセル・ワインダー（Russel Winder）
スクリプト言語の動的型付けはショックだった。未開拓の関数型言語を学びたい。
44. IDEを知る ハインツ・カブーズ（Heinz Kabutz）
Eclipse、Aptana、Visual Studio は押さえておきたい。
45. 限界を知る グレッグ・コルヴィン（Greg Colvin）
オーダーに関する話。最近は言語やフレームワーク標準ライブラリのコンテナに任せることが多いけど、その選定には必須の知識。
46. すべきことは常に明確に ダン・バーグ・ヨーンソン（Dan Bergh Johnsson）
チケット駆動のメリットは作業を明確にしないと始められないこと。
47. 大量のデータはデータベースで ディオミディス・スピネリス（Diomidis Spinellis）
検索を SQL に任せられるのもメリット。SQLite と MySQL ぐらいは押さえておきたい。
48. いろいろな言葉を学ぶ クラウス・マルカルド（Klaus Marquardt）
分野に固有の用語や文化を学ぼうという話。その分野を好きになるのが近道だと思う。
49. 見積りとは何か ジョヴァンニ・アスプローニ（Giovanni Asproni）
見積もりの本質とよくある誤解。期限付きの作業をおこなうなら、必須の知識。
50. Hello, Worldから始めよう トーマス・ゲスト（Thomas Guest）
ここで語られてる方法はよくやる。本実装の試案にも有効。
51. プロジェクト自身にしゃべらせる ダニエル・リンドナー（Daniel Lindner）
採用するなら SofTalk かな。ゆっくり声は和む。
52. 「その場しのぎ」が長生きしてしまう クラウス・マルカルド（Klaus Marquardt）
暫定策に不快な命名を施すのはどうだろう？例えば aDhocAdhOcAdHocClass とか FOoBAr のように。これを使い続けたいとは思わないはず。
53. 正しい使い方を簡単に、誤った使い方を困難に スコット・マイヤーズ（Scott Meyers）
間違ったコードは間違って見えるようにするを思い出した。
54. 見えないものを見えるように ジョン・ジャガー（Jon Jagger）
プロジェクト管理ツールを導入する最大の理由。
55. 並行処理に有効なメッセージパッシング ラッセル・ワインダー（Russel Winder）
このあたりの話。参照型を持つ言語はメモリ共有が暗黙的なので注意する。
56. 未来へのメッセージ リンダ・ライジング（Linda Rising）
複雑なものを簡潔に表現することの価値。
57. ポリモーフィズムの利用機会を見逃さない カーク・ペパーディーン（Kirk Pepperdine）
うまく使えば分岐やループはかなり減らせる。Factory と Strategy はかなり好き。
58. テスト担当者はプログラマの友人 バーク・ハフネーゲル（Burk Hufnagel）
最も近いエンドユーザーともいえる。彼らの意見は超重要。
59. バイナリは常に1つ スティーブ・フリーマン（Steve Freeman）
可変にしてよいのは最小の設定だけ。
60. 真実を語るはコードのみ ピーター・ゾンメルラード（Peter Sommerlad）
誤解してほしくないのは、これがコメントを書かない理由ではないこと。
61. ビルドをおろそかにしない スティーブ・P・バーチャック（Steve Berczuk）
IDE や Apache Ant などが隠蔽してくれるけれど、なにが行われているかは知っておいたほうがいい。
62. プリミティブ型よりドメイン固有の型を アイナー・ランドル（Einar Landre）
型を作るより、型に包むほうが好み。
63. ユーザの操作ミスを防止する ジャイルズ・カルバン（Giles Colborne）
Web フォームで住所入力するときとかフリー フォーマットだと不親切だと感じる。候補が限定できるなら UI もそうあるべき。
64. プロのプログラマとは？ ロバート・C・マーティン（Robert C. Martin アンクル・ボブ）
心に刻みます。
65. バージョン管理システムを有効に使う ディオミディス・スピネリス（Diomidis Spinellis）
趣味の開発でも絶対に使った方がいい。継続的に変更する予定があるものなら、ソース以外も積極的に登録する。
66. いったんコンピュータから離れてみる バーク・ハフネーゲル（Burk Hufnagel）
断線活動もオススメ。私の場合、土曜あたりをネットに繋がない日にしている。
67. コードを読む カリアンヌ・バルク（Karianne Berg）
読んだコードをリファクタリングしてみるのも勉強になる。無意味に見えた処理が深淵な思考の産物であることに気づかされたりする。
68. 「人間」を知る ケース・ブレイスウェイト（Keith Braithwaite）
よくわからない。哲学や心理学の本も素養として押さえとくべきなのだろうか。
69. 車輪の再発明の効用 ジェイソン・P・セージ（Jason P. Sage）
学ぶには書く。書き損じも重要な学習機会。コピペ可能でもまずは書いてみる。
70. シングルトンパターンの誘惑に負けない サム・サーリスト（Sam Saariste）
シングルトンを適用できることって案外、少ない。
71. パフォーマンスへの道は地雷コードで敷き詰められている カーク・ペパーディーン（Kirk Pepperdine）
メトリクス ツールについて調べてみる。
72. シンプルさは捨てることによって得られる ポール・W・ホーマー（Paul W. Homer）
増やさないことより減らすことのほうが難しい。
73. 単一責任原則 ロバート・C・マーティン（Robert C. Martin アンクル・ボブ）
複雑さを解きほぐすのに有用な考え方。粒度がデカイぞ！と思ったら責任で分割してみよう。
74. 「イエス」から始める アレックス・ミラー（Alex Miller）
まずは肯定する。村上龍の超伝導ナイトクラブを思い出した。
75. 面倒でも自動化できることは自動化する ケイ・ホルストマン（Cay Horstmann）
自動化は作業の非同期化にも繋がる。余剰マシンに作業を丸投げとか、非常に便利。
76. コード分析ツールを利用する サラ・マウント（Sarah Mount）
Lint 系ツールや FxCop はたしかに便利。
77. 偶然の仕様ではなく本物の仕様のためのテストを書く ケブリン・ヘニー（Kevlin Henney）
テストコードの考え方。これは前編。
78. テストは夜間と週末に ラジット・アタパトゥー（Rajith Attapattu）
専用ないしは余剰マシンでおこなうのがよいと思う。プラットフォーム分岐は VMware でカバーできそう。
79. テストのないソフトウェア開発はあり得ない ニール・フォード（Neal Ford）
すみません学びます。
80. 1人より2人 エイドリアン・ワイブル（Adrian Wible）
体制にするのが難しいなら相談という形で実行するのがよいと思われ。
81. エラーがエラーを相殺してしまう アラン・ケリー（Allan Kelly）
これを解決するとき複数の問題を同時に修正しないのも大事。
82. 他者への思いやりを意識したコーディング アスラム・カーン（Aslam Khan）
かなり哲学的な話。人生論というか。Ubuntu の由来をはじめて知った。
83. UNIXツールを友にする ディオミディス・スピネリス（Diomidis Spinellis）
Cygwin はパッケージをインストールする GUI がわかりにくい。いちど入れたら yum 的なツールでメンテさせてほしい。
84. 正しいアルゴリズムとデータ構造を選ぶ ヤン・クリチアン・"JC"・ヴァン・ウィンケル（Jan Christiaan “JC” van Winkel）
ループやコピーが必要になったときは対象のコストを正しく把握しよう。
85. 冗長なログは眠りを妨げる ヨハンネス・ブロドワル（Johannes Brodwall）
致命的なものだけ記録する。ログを出力するシステムはその例をドキュメントや UI で説明すべきだと思う。
86. WETなシステムはボトルネックが見つかりにくい カーク・ペパーディーン（Kirk Pepperdine）
DRY (Don't Repeat Yourself) に反するものを WET (Write Every Time) と呼ぶのか。上手い命名。
87. プログラマとテスターが協力してできること ジャネット・グレゴリー（Janet Gregory）
テスターとの協業はもっと語られてもいい。Selenium とかのテスト項目も、プログラマとテスターの協議が必要なはず。
88. コードは生涯サポートするつもりで書く ユーリー・ズバリョフ（Yuriy Zubarev）
ワンライナーでも、目的を示すコメントぐらいは付けたい。意外に再利用したくなるものなので。
89. 関数の「サイズ」を小さくする ケース・ブレイスウェイト（Keith Braithwaite）
記述量ではなく扱う値のサイズに関する話。どちらかというとレンジかな。例示されてるコードの場合 enum を適用したくなる。
90. コードを見る人のためにテストを書く ジェラルド・メサローシュ（Gerard Meszaros）
テストコードの書き方と効能。うーん、やっぱりまとまった本を読むべきだ。
91. 良いプログラマになるには ピート・グッドリフ（Pete Goodliffe）
すごくいいこと書いているのだけどプロフ写真で足の裏を見せるのはやめてほしい。
92. 顧客の言葉はそのまま受け取らない ネイト・ジャクソン（Nate Jackson）
同じ言葉を交わしながら全く別のものを思い浮かべているのはよくあること。「言葉を換えて言い直す」という案は取り入れたい。
93. エラーを無視するな ピート・グッドリフ（Pete Goodliffe）
足の裏の人。足の骨折に関する話からはじまりエラー チェックの重要性に至る。エラー処理についてガッツリ解説している本があったら読みたいな。
94. リンカは魔法のプログラムではない ウォルター・ブライト（Walter Bright）
コンパイラの仕組みとあわせて説明するのがよいのかな。メモリ上にひとつの巨大なソースを構築している、と考えれば定義の重複や参照の不足が問題になる理由がわかりやすい。
95. ペアプログラミングと「フロー」 グドニー・ハウクネス（Gudny Hauknes）、カリ・ロスランド（Kari Rossland）、 アン・カトリン・ガナット（Ann Katrin Gagnat）
個人に話しかけるのは容易だが会話に割って入るのは心理的な障壁を感じる、というのもフロー状態の保護に役立つ気がする。
96. テストは正確に、具体的に ケブリン・ヘニー（Kevlin Henney）
テストコードの考え方、後編。誤解の余地が入らないデータや処理でテストする。副次効果としてテスト コードが分かりやすいサンプルになる。
97. ステートに注目する ニクラス・ニルソン（Niclas Nilsson）
冒頭の例が非常にわかりやすい。状態遷移図を書く習慣をつけたい。
日本人プログラマによる知っておくべき 10 のこと
1. 命を吹き込む魔法 森田 創
プロジェクトを好きになるためのよい工夫。マスコット超重要。実践できたら雰囲気は確実によくなり帰属意識も大きく向上するだろう。
2. ロールプレイングゲーム 関 将俊
昔、なにかの本で「半歩先の自分を目指す」という方法を読んだ。私はそれぐらいでよい。
3. ルーチンワークをフローのきっかけに 宮川 達彦
助走のための簡単な儀式。自分なりのスイッチを構築する。検討したい。
4. プログラマが持つべき3つのスキル 吉岡 弘隆
テストをするスキルが不足しているので身につける。
5. 快適な環境を追求する 舘野 祐一
はてブと Google アラートが役立ってる。前者で未知の分野を開拓。後者によって既知を掘り下げ。
6. 見知らぬ人ともうまくやるには 小飼 弾
見知らぬ人に何か相談するときは、それとなく選択肢を見せておく。A と B が本命ですが C も捨てがたいですね、といった感じで。
7. 不具合にテストを書いて立ち向かう 和田 卓人
実践的なテストの書き方。蓄積してゆけば、問題の起きやすい部分も自動的に浮かび上がるのだろう。ぜひ、ものにしたい。
8. 育ちのよいコード 森田 創
リファクタリングはそれだけをおこなってコミットするのがよいと思う。前に在籍していたプロジェクトではそうしていた。リスト アップした時に読み飛ばすためコミット ログへ専用の語句を入れていた。
9. Noといえることの大事さ 宮川 達彦
ニッチな要求は基本的に No。不可避ならオプションを検討。ところで、要求・要望を採点するシステムがほしい。あるかな？
10. 名前重要 まつもと ゆきひろ
名前の表記にもこだわりたい。例えばキャメルケースの場合、単語の区切りにアセンダありの文字がこないようにする、など。