Entry

休み中に読む本買った - 『ひなた先生が教えるデバッグが256倍速くなるテクニック 』他

2008年11月17日

明日は休みにしたので本を読む。で,本を買いました。もう半分くらいずつ読んじゃったんですが。

ひなた先生が教えるデバッグが256倍速くなるテクニック (Software Design Books) (Software Design Books)
やねうらお
技術評論社
売り上げランキング: 516

ソフトウェアデバッグの書籍っつのは,出ているようであまり出ていないもんで,そゆコンテンツでも作ろうかと思ってたんですけれど,ちゃんとした書籍が出てしまって出遅れてしまいました。最近よく思うんですけれど,一見初心者向けの装丁の割に中身がしっかりしている技術本がかなり出回っている気がします。『Cプログラムの中身がわかる本』にしてもそう。初心者向けの装丁そのものについては,まぁ,それでもいいとは思うんですけどね。多分,腕に覚えのある技術者さんには見過ごされてるんだと思う。もったいない。反面,装丁がかっちょいいくせに中身がショボい本も増えているんですが。

Cプログラムの中身がわかる本
日向 俊二
翔泳社
売り上げランキング: 296036

デバッグ本の話に戻ると,例えば類似の書籍では『C言語 デバッグ完全解説』というのがあります。本書も C のデバッグをする際に,示唆深い点がたくさんある。けど,これはあまり現場では役に立ちません。

C言語 デバッグ完全解説 (Gihyo Technology)
坂井 弘亮
技術評論社
売り上げランキング: 76212

というのも,『完全解説』は,「どういうバグがあるのか」を並べることが中心になっているからです。言い換えれば,バグの性質や存在が既知になっている場合に有効なわけで,こゆケースは現場にはない。バグってのは,大抵,どこから来るか分からない(分かってたら作り込まない)もんなわけで,デバッグは実践的な要素が多分に含まれます。症例にだけ詳しい医者が,患者を診れないのと同じようなもん。『完全解説』にも,そうした実践的な記述はあるんですけれど,いかんせん記述が薄い。臨床的なデバッグ本は,これまでほとんどなかったし,ベテラン技術者さんのノウハウとして,属人的に帰属していたのでした。

その点,本書は臨床的なデバッグ手法がてんこ盛りです。デバッグというと,動的なデバッグでは,ブレークポイントで止めた位置からトレースしながら,変数やレジスタの値を見ていくってのが一般的ですけど,こゆのは超初級者レベルです。あたしも見ているけれど,ベテランさんのデバッグは本当にすごい。オペコードを読んで,実際にどのような機械語が生成されているのかを見るのはもちろん(機械語表は頭の中にある),論理演算を使ってテストケースを効率化したり,スタックの戻り値まで静的なデータが割り込んでいないかメモリをチェックしたり,傍から見てると神業に見えます(最初は何やってるのか謎だった)。

ここでは,機械語を見る機会のある C/C++ の話でしたけれど,本書では,バグの原因の絞り込み方から,バグを作り込まないコーディング法まで,実践的で臨床的なデバッグ手法が盛りたくさん。現場でも,すぐ使える本になるはずです。

続きまして,『はじめてのプロジェクトマネジメント』。

はじめてのプロジェクトマネジメント 日経文庫
近藤 哲生
日本経済新聞社
売り上げランキング: 9128
おすすめ度の平均: 4.0
4 プロジェクトマネジメント関連本の中で最もお勧めできる本。
4 初〜中級レベルのプロマネに大変有効
3 まずまずの解説書
4 プロジェクトは最初と最後が肝心
4 入門書と言いながら・・・

例年,秋に行われていた情報処理技術者試験のプロジェクトマネージャ(PM)が,春に行われることになったってことで,「今回は」ちと真面目に対策を取ろうかと思っています。て,あたしゃ PM 経験あんまないんですけどね。試験っつのは経験少なくてもできるもんだと信じてるわけです(だって試験だし)。

で,対策を立てるわけですけれど,いくらなんでも11月の今の時期に問題をガリガリ解くのもアレだし,歳が歳なので覚えるもんを覚えてもすぐ忘れるだろう(昔から忘れっぽいんだけど)ということで,とりあえずモチベーション作りに,「一般的なプロマネ」は,どんなことやってるのかを見ることにしました。

本書は,新米のプロジェクトマネージャ向けに書かれた入門本です。特徴的なのは,プロジェクトの立ち上げから計画の策定,プロジェクトの遂行,完成,反省と,順を追ってプロマネが取るべき行動を説明している点。各章ともシナリオ仕立てになっていて,シナリオの後に要点の解説と Step Up Point !(発展)が付いています。Amazon の書評によると,プロマネ経験者さんも勧めているみたいなので,内容に大きな無理はないんだと思います。

で,半分くらい読んで思ったんですけれど,本書では,「チーム全員が納得してプロジェクトに参加する」であるとか「腹を割って話す」とかいった具合に,プロマネの役割のうちで割とソフトな側面を重視している印象がありました。たしかに,信用されない人がプロマネをやっていると,プロマネ自身が孤立するのはもちろん,メンバーもばらばらになりがちです。反面,いいことも悪いことも共有して,プロジェクト全体の成果なり問題として共有しているプロマネさんが中心にいると(あたしが知ってるのはプロマネみたいなプロジェクトリーダーだったんですが)は,メンバーの結束も強くなるし,プロジェクトの問題意識も明確になりやすい印象があります。そういう意味で,本書の方針は,当を得ているのだと思います。

一方,今読んだところまでで思うのは,プロジェクトの成果物についての言及が薄いということ。これくらいはあたしも知ってますけど,プロジェクトを遂行するに当たっては,必ず何かしらの成果物が出てきます。しかし,実情では,形式的な日報が垂れ流されていたり,実現されてるのかされてないのか分からない進捗表が出回っているプロジェクトもあるんじゃないでしょうか。問題点を共有するに当たって,こうしたハード面(制度面)とどのように連携をとるべきか,といった話もあればよかったと思います。

試験との関係でいうと,本書は多分直接役には立たないんだと思います。けど,PMBOK とかアローダイアグラムとかいった,こまごまとしたことの基盤には,現実に存在する「生のプロジェクト」っつもんがあるわけで,そゆもんをまず「プロマネの立場で」体感する必要はあるはず。本書はシナリオ仕立てだし,お手軽にプロマネを体験させてくれます。もちろん,大半のプロジェクトがこんな風に終わってるわけじゃなくて,生き地獄の様相を呈していることは,重々承知なわけですが。

ともあれ,ページ数も少ないし,さくっと読んじゃうことにします。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN