書籍購入：『プログラマが知るべき97のこと』がやっと届いた

積読 読書

Amazonで昨年頼んで、ようやく届いた。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

最近はこういう「その分野のいろいろな人が書いたエッセイ集」的なものが結構出版されているし、自分自身も結構買っている気がする。

日本語版で追加されたものも含めると、81人が書いた107のエッセイが載っている。ただ大半のエッセイは2ページ（見開き1ページ分）ぐらいだし、長くても3ページと軽めなので、読み進めるのに苦にならない。

つまみ食いの要領でパラパラと見ているが、流石にこれだけの数のエッセイがあると微妙にネタがかぶっていたり（しかし意外と差異がある）、自分が予想していなかった方向性のものもある。比較的技術的な話もあればプログラマとしての態度・姿勢に関する助言もあるし、システム内部側のネタもあればユーザインターフェース側のネタもあるし、最近の流行りに乗っかったものから「10年前・現在・10年後」も変わらないだろうなあ的なものまで──つまり色々と載っている。

どのエッセイも頷ける内容のものばかりだが、適当にいくつか雑感を記しておく。

09「他人よりまず自分を疑う」

私自身が今週にやってしまった恥ずかしいネタなので。うん、まさか修正が不十分だった為にエンバグしてたとは……。

ちなみに、個人的にこのネタの変形として「他人が優秀なら自分のミスが目立つ」というのを信奉していて、要は他のモジュールの品質が高ければ高いほど何か不具合が見つかったときに自分が書いたモジュールを疑うだけで済む（他人が書いたコードを読まなくて済む）ので非常に楽だ、ということだが──これも今週悟ったことだ*1。

26「言語だけでなく文化も学ぶ」

『JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス』片手にJScriptでツールを書いたおかげで、プログラマとして少しは幅が広まった気がする。まあ、まだCプログラマ文化の香りが濃厚だと思うけど。

34「API設計の黄金律」

私自身はCプログラマだけど、モジュール屋というか、単体のアプリケーションではなくてライブラリを開発・提供する立場なので、自戒を込めて。

あるいはWindows APIやUnixシステムコールを直に叩いているコードの単体テストですら苦労した立場としての「そうそう、そうなんだよ」という思いを込めて。

35「超人の神話」

2ちゃんねるとか「教えて！　HogeHoge」的な所で繰り広げられそうな。

69「車輪の再発明の効用」

自前で簡単なWAV録音アプリを書いたことで、WindowsのマルチメディアAPIとMFCへの理解が以前より進んだと思う。

76「コード分析ツールを利用する」

CやC++の定番ネタ「警告レベル最大でビルド」。そしてサンマイクロシステムズのOS開発チームといえば「lintパーティー」。

Splintは確かに結構良いツールだ。英語のドキュメントが障害になって未だに使いこなせてないけど、それでも結構な恩恵を受けている。C++だとCppCheckなんかも地味にバージョンアップしていていい感じだと思う。

97「ステートに注目する」

状態遷移大好き。状態遷移表もenumによる状態管理フラグも関数ポインタ*2も好き。でも状態遷移図は好きじゃない*3。

CプログラマなのでStateパターンは使ったことがないのだが*4、オブジェクト指向プログラミング向きな言語を使うようになったら重宝すると思う。私の認識ではStateパターンは「状態遷移を実装する手段の一つ」でしかないのだけど、オブジェクト指向プログラミングするのならその文化に合わせるまでだ。

ところで、言語にも依存する話だろうけど、Stateパターンの実装って静的解析ツールでどこまで解析できるものだろうか？　いや、C言語で関数ポインタの配列で状態を管理するような実装って「switchで書かないと静的解析できない！」って咎められることがあるのだけど*5、例えばC++で継承を使ってStateパターンを実装した場合とかはどうなんだろうかと。

*1:自分が書いたモジュールも他人のモジュールも微妙な出来だと、何か不具合らしきものに気づいた後の対応がグダグダになってしまう。

*2:関数ポインタの配列を用意して、enum等の状態フラグ値を添字にすることで呼び出す関数を切り替える。又はステートが変化したときに関数ポインタにセットする関数を差し替えることで、呼び出される関数を切り替えてしまう。

*3:自分で書くのが下手なので。

*4:似たような考え方をSMF解析ツールのC++による実装で適用したことならある。SMFは複数種類のチャンクによって構成されるのだが、チャンクのインターフェースクラスと個別のチャンククラスを用意し、SMF全体のデータをインターフェースクラスのオブジェクトの可変長配列として管理した。またトラックチャンクは複数種類のイベントによって構成されているが、それも同様に実装した。これによって、チャンクやイベントを操作する処理を書く際に個々のチャンク／イベントの種類を気にする必要がなくなった。ただ、その時はC++の派生／継承の勉強が主目的だったのだが……。

*5:静的解析ツールで解析可能なコードが求められる職場なら仕方ないけど。