達人プログラマーを読みました

プログラマのバイブルとして定番の
『達人プログラマー(アンドリュー ハント, デビッド トーマス著)』
を読みました。

全体の感想

読む前は
他の一般的な技術書と比べて少々高価(4300円)で、表紙の固い印象や
ピアソンから出版されていることから、なんとなく敷居が
高いイメージを読む以前は受けていました。

しかし読んでみると、難しい話は少なく、システム開発初心者でも
十分に読むことができ、役に立つ内容だと感じました。
むしろ上級者より、初心者~中級者向けの内容だと思います。

実際にプログラムを書くフェイズだけでなく、要件定義から保守、バージョンアップ
のときにも意識するべき達人の心得が書かれていました。

ソースコードにフォーカスした内容ではなく、達人の問題解決へのアプローチ
に対してページが割かれているため、具体的なソースコードのサンプルの数は少ないです。

そして現在はあまり使われていなかったりするものを
サンプルコードで利用している箇所もありますが、その言語の
優秀なアーキテクチャやスキームを紹介するもので、その言語
独自の表現と、それをjava等の汎用言語へ適用するアイディアが
紹介されています。

『こうするべきだ』とわかっていても、時間や技術的な制約で
全て実践することが難しい、悪い言い方をすればキレイ事も含まれている気もしますが、
一般的に『意識したほうがよい』というものは真似していきたいと思います。

個人的にピックアップしたいところいくつか

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

継続して勉強しないとダメですよ、という内容。
これは自戒のために・・・。

正直、帰ってから本読んで、コード書いて、すぐ疲れちゃうんですよね・・・。
でもやらないとダメですよ。ポートフォリオを充実させましょうね。

という内容です。

8.直交性

本書ではDRY原則と同等に、直交性を維持することに重点を置いて説明されています。

2つ以上のものごとで、一方を変更しても、他方が影響を与えない場合に
このモジュールを直行していると呼ぶ、と紹介されています。

つまりは他のモジュールの依存度が低く、単体で使い回しができる状態を
できるだけ維持していこう、ということだと思います。

学校の授業や入門書でDRY原則を見聞きすることは、僕でもありましたが
直交性(モジュールの独立性)という観点では、ある程度の規模の開発で
ないと意識したことがない方も多いと思います。

直行したモジュールやコンポーネントを組み上げるには、というテーマは
この節だけでなく、本書を通じて、様々な手法が紹介されています。

13. 見積もり

プロジェクトの一部、または全体の機能を開発するときに、どれくらいの時間がかかるか、
という趣旨の見積もりに関して書かれています。

この本を読んでいるときに、丁度僕が作業工数を見積もる
仕事が多かったので、印象に残りました。

バイトで約2年ほど現場でシステム開発をしていたとはいえ、
見積もりは入社してからで、結構戸惑いました。

手順として

  1. 何を聞かれているのかを理解する
  2. システムをモデル化する
  3. モデルをコンポーネントに分割する
  4. パラメータに値を与える
  5. 答えを計算する
  6. 実際にかかった時間との差異を記録していく

24. いつ例外を使用するか

これは、この本を読んだ後でも、僕の中で明確な答えというか、ハッキリしたものは
まだ模索中です。

ただ、スクラッチでWindowsアプリとsastruts(java)のWEBアプリを
同時に開発していて、C#とJavaの例外に対するアプローチの違いを意識する
きっかけになりました。

本書では、例外を

  例外とは予期せぬ事態に備えるためのものであり、通常の流れの一部に組み込むべきではないもの

とあります。
ただ、その後結局、どこで例外を発生させるかは『状況による』と説明しています。
(まぁ紹介されているサンプルコードを見れば納得なんですが)

例外で処理しないものはアプリケーションエラーとして結果をリターンする
アプローチが紹介されています。

最初ここを読んだ時は『使ってるライブラリ(組み込みライブラリでも)が、どんどん
例外を投げてくるケースもあるのに、どうしたらいいの??』と悩みましたが、
(僕の解釈では)ライブラリ開発者でなく、アプリケーション開発者であり、ライブラリのユーザは
この本で紹介されているような例外ハンドリングとエラーを使い分けるべきだ、
ということを説明していると思ってます。
(多分うまく説明できてない気がしますが・・・)

例外を受け取ったからそのまま投げる、とかではなく。ということ・・・。だと思う・・。

27.メタプログラミング

メタプログラミングと聞くと、僕の勝手なイメージで『リフレクションを多用する黒魔術的なもの』
という印象を受けましたが、本書を読んで、スッキリしました。

他の節でもDSLやコードジェネレータ(コードを生成するコード)のことが説明されていて、
僕が個人的に一番関心をもって読むことができた箇所だと思います。

要は、フレキシブルに変更したい箇所は、プログラムと分離された環境に置いて
プログラムでそこを読むようにしましょう。というアプローチの紹介。

これを推し進めたり拡張すると『リフレクションを多用する黒魔術的なもの』が
可能になるのかもしれません。

45. 大きな期待

すごく端的にいうと、『報酬をあげるには』ということに関する説明。
書かれていることは非常にシンプルで、ただひとつ

  ユーザの期待を少しだけ上回る結果を出す

ということ。初期段階のユーザのビジョンは不完全で整合性がない。それでも
ユーザはそこに投資することに思い入れを持っている。
(だから仕事として自分のところにやってくる)

プロトタイピングや曳光弾(本書の他の章で紹介されているプロトタイピングに似たアプローチ)
によって、ユーザの要求の理解度をユーザに伝達することで、コミュニケーションが
活発になる。しかしこれもやり過ぎると、納品時のサプライズがなくなるのでほどほどに。

などなどが書かれています。

余談

前回読んだリファクタリングウェットウェアを参考に、SQ3Rで
本を読んでみました。

すんごい時間も体力も使う・・・。
継続すれば良いに決まってるんだけど、Reciteがすごい面倒・・・。

細かくやりすぎるのも、まとめるて一気に、も大変。

ただ頭には残るかも。

一ヶ月に2冊を目標に、ここから頑張ります・・・が・・・。
結局この本も1ヶ月ちょいかかってしまった・・・。

プログラムによる検証とかが少ない読み物重視の本は1週間くらいで
終われるといいんですけどね・・・。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です