どういうきっかけで知ったの？

伊藤淳一(@jnchito)さんの記事で知りました。

blog.jnito.com

伊藤淳一さんのブログは読みやすく、とても勉強になるのでオススメです。
この記事をみて、興味を持ったので探してみたら絶版・・・プレミア価格！というわけで手がだせなかったんですよね〜

どんな本？

いわゆる古典と言われる技術書。
プログラミングだけではなく設計、プロジェクト運営、ユーザーとのコミュニケーション等様々な場面で達人プログラマーはどのようなことをやっているのか、ということを綴った本。

プログラマの聖典として長い間多くのプログラマから親しまれていたが、絶版になってしまい、プレミアがついたこともあってなかなか手が出せませんでしたが、 2016年に新装版として再販されたので、これを気に手に取ってみました。

こういった古典は内容が古くさくて今では使われない、と言われることも多いのですが、達人プログラマー[新装版]はそういったものを現代に合わせアップデートしたり、訳者の脚注などで現在はこういうツールが有る、等紹介されています。

本の特徴として、序文に以下の文があります。

この本はただTipを集めただけのものではありません。
それぞれのTipが経験に裏打ちされており、具体的なアドバイスとして記述され、解決策のシステムを構成するよう
お互いに関連付けられているからです。

実際に読み進めるとその通り、単にTipが集まっているのはではなく、お互いリンクしています。
特に、最初の章となる達人の哲学の各Tipは、様々なTipからリンクされています。

また、プリンシプルオブプログラミングほどではありませんが、プログラミング言語などを限定せず、抽象的に書かれているためどのようなシチュエーションに対しても使えるようになっています。

対象読者

この本のターゲットについては、まえがきにこう書かれています。

本書は、より効率的、おして、より生産的なプログラマーになりたいと願う方々のためのものです。

どういった経緯でより効率的、生産的になろうとしたのかは関係なく、より上を目指したいプログラマーのための本です、というのが筆者の気持ちです。

ただし、

すべての状況に我々のアイデアが適用可能である、と主張するつもりは毛頭ありません。

とありますので、なんでも型にはめて解決する、ということは出来ない、というのは頭に入れておく必要があります。
ただ、その後に

このアプローチに従えば、経験を積む速度が飛躍的に向上し、生産性が高まり、開発プロセス全体のより良い理解もえられるようになるはずです。
そして、結果的により良いソフトウェアを構築することができるようになるのです。

と続きます。
すべての回答にはならないが、本書のアプローチを使えるようになればソフトウェア開発プロセスの全体が向上するでしょう、というのが筆者の思いだと思います。

ソフトウェア開発をすべて枠にはめるということは色々な本でも書かれているのですが非常に難しいことです。
それでも、開発の効率化、生産性の向上のために努力していくプログラマーを想定読者とするという本です。

特に自分の琴線にかかったトピック

石のスープと蛙の煮物

達人の哲学の章に出ててきます。
自分のイメージかもしれませんが、色々なTipからリンクされていたTipでした。

どういうことなのか、一言で言ってしまえば、何かを変えようとするのであれば、急に変えてしまうのではなく緩やかに変化させ、最終的なゴールに導くようにすることで成功し易いということです。

たとえば、一気に色々とシステムを変えるとなるとユーザーから抵抗は強いものになります。
ですが、少しずつシステムを変えていって、最終的に一気に変えた時と同じシステムになるとしても、ユーザーの抵抗は弱いものです。

これは様々なことに使えますよね。わかり易い例で言えば消費税の増税です。
2014年に8%,2019年に10%と段階的に増税になります。もしこれが一気に5%から10%になったら受け入れられなかったでしょう。

あなたの知識ポートフォリオ

達人の哲学の章に出ててきます。
自分が持っている知識、というのは有効期限つき、という書き出しから始まります。
どういうことかというと、一度得た知識をずっとほったらかしにしてアップデートしなければ、陳腐化しやがていらなくなってしまう、ということです。
これを防ぐため、毎年新しい言語を取得したり、本を読んで知識をアップデートし、自分の持つ技術が常に最新の状態になるよう勤めなければいけません。

製造業や建設業など、ずっと同じ知識でやっていける業界もあるかもしれません。
ですが、情報産業は１年前の知識はすでに古い、ということもしばしばあり、常に知識のアップデートをしていかなければ行けません。
そのため、自分の知識に対し投資していく必要がある、というのがキモです。

実際に自分も勉強をしっかりやり始めたのは２，３年前で、その前は最新技術等知らず、今の技術にしがみついている状態でした。
その状態ではいつか仕事がなくなる可能性はあったでしょう。

曳光弾

達人のアプローチの章に出ててきます。
曳光弾とは、暗闇の中で光る弾です。夜間で銃を打つ時に１０発の弾のに対し１発の割合で曳光弾を入れ、撃った時に弾がどの方向に飛んだか、というのを確認するためのものです。
これをソフトウェア開発で考えると、１週間程ソースコードを書いてユーザーに見せて方向性を確認すること、となります。
これは今現在自分もよくやっていることですが、動くものを作って少しずつユーザーに見せていって、お互いの認識のズレ(ギャップ)がないか、というのを確認しています。

プリンシプルオブプログラミングの書評のときにも書いたような・・・。

これをよりユーザーとのコミュニケーションに焦点を当て、活発化したのがアジャイル開発だと思っています。

すべてはドキュメント

達人のプロジェクトの章に出ててきます。

コメントの書き方などの解説から、コメントから仕様書やリファレンスを作成するJavaDoc(RubyにはRDocというのがありますね)の利用によるドキュメントの自動作成など、そういったテクニックを紹介しています。

コメントの書き方については他のコードの書き方の本でも色々紹介されますが、本書では自動化を前提としたコメントを書く、というのにフォーカスを当てています。
この自動化できるようなコメントの書き方の話ですが、非常に重要だと思います。

以前、１００万行以上のパッケージソフトでクラスの構造などが複雑すぎるので、クラス図やリファレンスを自動作成できるDoxygenというツールを使おうと検討していた事がありました。
ですが、結局自動作成はできませんでした。

何故かと言うと、コメントが自動化されるという前提で書かれていなかったため、自動化するためにはすべてのコメントを書き直さなければいけない、という状況になってしまったためです。
100万行以上あると、コメントだけでも十万行はあるかもしれません。それらすべてを直していくよりもコードを読んでクラス図を書いたほうが早い、という結果でした。

こういったことを繰り返さないためにも、開発初期から自動化を検討に入れ、自動化しても問題ないようなコメントにしておくと良いと思います。

読み方

この本を読んで一発で全部理解できるなら、あなたはもう達人プログラマーでしょう。
膨大な質の良い経験をしているので、書かれていることを自分の経験にあてはめ、すぐに理解できたのではないでしょうか。

残念ながら私は達人など雲の上のような、一般的なプログラマーです。
なので、一度で全部は理解しきれませんでした。

そこで、私が取った読み方になりますが、本はまずざっと目を通し、どのようなことが書いてあるかをだいたい掴みます。
そして、改めて最初の達人の哲学の章を読みます。
そうすると、最初読んだときはちょっとピンとこなかった達人の哲学が大分理解出来ると思います。

というより、この本が全体に渡ってこの達人の哲学を実際に運用していくにはどうすれば良いのか、どういうテクニックがあるのか、というのを紹介しているようにも感じられます。
その根源を理解するためにも、達人の哲学をしっかり理解しておけばいいと思います。

そして、この本を開発するときに机の上に置いておき、迷うことがあれば本書の最後にリファレンスがあるので、そこに目を通し、今の環境を「なんとか」できそうなTipがあれば、それを読んで見る・・・というやり方で読んでいくことを繰り返し、本の知識と自分の経験を結びつけていくことが出来ていけば、この本をしっかりと理解していけるようになると思います。