May 22, 2007

達人プログラマー―システム開発の職人から名匠への道


達人プログラマー―システム開発の職人から名匠への道

キーワード:
 アンドリュー・ハント、デビッド・トーマス、自己啓発、スキルアップ、ヒント、実践的
より効率的、生産的なよりよいプログラマーになるために必要なことが書かれた本。かなりの良書。値段は4000円近くだが、買って損はない。

原題は『The Pragmatic Programmer』であり、達人と訳されている。Pragmaticは実践的という意味。ソフトウェア開発に必要な行動指針やヒントが多く書かれている。以下のような内容となっている。
  1. 達人の哲学
  2. 達人のアプローチ
  3. 基本的なツール
  4. 妄想の達人
  5. 曲げるか壊すか
  6. コーディング段階
  7. プロジェクトを始める前に
  8. 達人のプロジェクト
まぁ、この目次だけでは内容がいまいち分かりにくいので、各章を簡単に説明してみる。

1章は普通の人と達人の違いについてで、達人になるためには眼前の問題を考えるだけでなく常にその問題をより大きな背景の中で捉え、より大きな問題について気付こうとする姿勢が必要とあり、自分のソースコードに責任を持つことや質の悪いコードを放置しておかないことや、常に技術を学習し続けよとある。

2章では開発におけるアプローチが示されている。例えば、コードやドキュメントの2重化は避けろということやコードの直交性(独立性)をつねに意識すべきといったことが示されている。

3章では、達人たるものは生産的な作業を行うためにエディタやCVSなどのツールを使いこなせないとならないということが示されている。

4章では完璧なソフトウェアを作ることは不可能であるということを前提に防衛的なプログラミングを行う必要があると示されている。デバッグの仕方や例外の使い方が示されている。

5章ではコードの柔軟性と適用性を保つためにどうすればいいかということが示されている。例えば、モジュール間の結合度を減らす、コード量を減らすといったことが示されている。

6章ではコーディング時に偶発的なプログラミングになることを避けろとある。つまり、自分が何を意図してコーディングをしているのかということをしっかり把握し、また自分のコードを再点検するためにリファクタリングを実行すべきとある。

7章では主に要求分析段階での内容で、要求分析ではユーザの話を聞くだけでは足りないので要求を掘り起こすことが重要であるとあり、さらにコーディング時や要求に対して問題が発生した場合は、枠にとらわれず違った視点で考えてみることが大切とある。

8章ではプロジェクトの成否を分けることにテストと自動化が挙げられている。テストは何をどの程度やるのかといったことが示されており、自動化に関しては、何度も繰り返して行わなければならないようなことは全てバッチやシェルスクリプトを使って人的ミスを少なくせよとある。

どの章もあるあるwwwとうなづきながら読んだ。それだけ自分が体験してきたことに対して的を射た内容となっている。全体を通して70のヒントが示されているが、以下に特に自分がそのとおりだと思ったものを抜粋。
  • ヒント1: 自らの技術に関心を持つこと
  • ヒント3: いい加減な言い訳よりも対策を用意すること
  • ヒント8: 常にあなたの知識ポートフォリオに投資すること
  • ヒント11: DRY―Don't Repeat Yourself (繰り返しを避けること)
  • ヒント18: あとでびっくりしないために、見積もりを行うこと
  • ヒント21: コマンド・シェルの力を使うこと
  • ヒント27: 仮定せずに、証明すること
  • ヒント30: あなたは完璧なソフトウェアを作ることができない
  • ヒント44: 偶発的なプログラミングを行わないこと
  • ヒント50: 理解できないウィザードのコードは使わないこと
  • ヒント61: 手作業は危険である
プロジェクトをひとつ経験したあとに読んだので、本当にそのとおりだなと思うことばかりだと思った。特に、ヒント3などは、「できない」とか「それは無理」と言わずに、ではどうやったらできるようになるかという姿勢が問われる内容だと思った。ヒント8は達人プログラマーになるためには常に知識に対して投資を行う、つまり書籍やネットなどで技術を学習し続けなければならないとあった。やはりそうでないといけないようだ。

また、ヒント27では、バグが発生したときは、バグのわけがないと思い込む危険性を指摘しており、バグになったからにはそれを客観的に証明する必要がある。これは自分もプロジェクトに参加していたときに、自分が改修したものがあとでエラーが発生したときに痛い目を見た。SQL文で取得したデータのバリデーション部分だったのだけど、自分の思い込みでこのようなデータだろうと思って修正したが、実際は違っていた。まさに思い込みはだめで、必ず証明する必要があるなと実感した。

他にも、ヒント61なども、DDL文作成時に手作業が多く、初期のころはミスしてばかりだった。そのため自動化すべきだと言われていたが結局、ヒント21にあるようなコマンド・シェル、つまりシェルスクリプトに精通していなかったために実現できなかったりと耳が痛いことが多い・・・・。

各節のはじめに偉人の格言などが引用されている。洋書の技術本はこういうのが多いなと思う。その格言が言い当て妙なので、いいなと思う。

ところどころプログラムが出てくる。C言語、Perl、Java、C++など。特にリファクタリングの部分や例外の扱い方の部分に多い。また、各章に演習問題があり、クラスを実装しろとかこのコードのリファクタリングをしろとか、ケーススタディ的な問題などもある。そのため、オブジェクト指向言語を理解していると分かりやすいと思う。

かなりの部分に線を引いた。技術書でここまで線を引くことはほとんどない。達人プログラマーになるための啓発的な内容となっており、ユーモアたっぷりなので読み物としても面白いと思う。

身にしみることばかり書いてある気がした。プロジェクトにアサインされる前、またリリース後に読み返してみるとまた勉強になるかもしれない。

買って損はない。絶対。IT技術者として生きるならこれは必読。あと、なによりもカバーが漆黒にゴールドの字体なので玄人っぽいデザインなので飾っておいてもいいと思う。もちろん、読後はかなりスキルアップした気もするけど。

読むべき人:
  • スキルアップしたいIT技術者の人
  • プロジェクトでバリューを発揮したい人
  • 格言が好きな人
Amazon.co.jpで『プログラマー』の他の本を見る



トラックバックURL

コメントする

名前:
URL:
  情報を記憶: 評価:  顔   星