設計方法論についての本を紹介する。
UMLに関する本で一番安かったのでこれを買った。 第１章「小説 UML 物語」は企業小説風である。 昔ならなんだかなあ、の一言で済ませていた。 しかし、今となってはひょっとすると、本当になるかもしれない、と思う。
ソフトウェアには『銀の弾丸』はない。 だから生産性がこれだけ向上しましたといって２倍３倍の数字を見せられると嫌気がさす。 ひょっとしたらこの本にそんなことが書いてあったかもしれない。 しかし、よりよいソフトウェアを作るための工夫ができれば、 それを素直に取りこんでいきたいと思う。
設計を図で行なう方法で、最初になじんだのが PAD である。 流れ図でも、HIPO でもない。 その後まともな図式分析・方法はかじっていなかった。
これを期に、ちょっとばかばかしいことを考えてみた。 図を書くのがめんどうなので、日本語のテキストで どこまでUML表記が可能かを考えてみた。まだ公開しないでおこう。
私は初版と改訂版をもっているが、実際に適用してみたことはない。 本当は一つでも適用できればいいのだが。 ある同僚と試験的に作ってみたソフトがあって、その同僚が無意識的にこのデザインパターンの あるパターンを使っていたことが分かり、その同僚の技術に驚いた。
少しわかりにくい。
リファクタリングという名前が出てくる前から、プログラムの改良について工学的な見地からまとめた本があった。 それがこの本である。今となっては、古くなったり効果のなくなったりした手法もあるが、 それでもこの本で書かれている基本は今でも通用する。 その精神は、たとえばカーニハン・パイクの「プログラム書法（邦訳）」や ハント・トーマスの「達人プログラマー（邦訳）」などに受け継がれている。
原題は"Programing Pearls"。堅苦しい本ではない。 いろいろなトレードオフがあることをこの本で学んだ。
原題は"More Programing Pearls"である。awk などの説明もあり、 プログラムに対しての解析がよくわかる。
通信プログラムについての領域の知識があればよくわかるだろう。 わたしはあいにくその方面の知識を持ち合わせていないため、全く役にたたなかった。
某掲示板で「アナリシスパターン」ということばについての理解度を問う書き込みがなされていた。 私はわからなかったので唯一ある成書としてこれを買った。 通読するのには骨が折れた。なんとかして利用してみたいのだが。
もう二十年も前に訳された本であるが、今でもプログラミングの教科書たりうる本だ。 この本は、エディタを例にとって、小さな部品をうまく組み合わせる方法のあれこれを述べている。 この本で使っている言語は、RATFOR という、理想の FORTRAN である。しかし、構文や関数は C とよく似ている。これは当然のことだ。Kernighan は御存知 K&R 本の作者であるし、 Plauger も C 言語の創成から深いかかわりを持っている方である。
対象は文字列操作、特に対話的行エディタの実装を大きな目標においている。実装の過程で、 単純なプログラムからどれだけ多くの作業ができるかを見せている。UNIX の標準エディタ vi は、 この本で述べられたエディタの発展形である。私はエディタとしては vi より emacs を好むが、vi を好む一派の気持ちもよくわかる。
久しぶりに読み直してみた。序論にはすでに「協調プログラミング」（エゴレスプログラミング）について 言及されているではないか。目を開かされる思いがした。..2000-05-06
エクストリーム・プログラミング(XP)の後で広まりそうな勢いがあるのが、 アジャイルソフトウェア開発である。こちらは XP を含む、より懐の深い方法論である。 とにかく納品をするために必要なことは何か、ここから出発している。 いろいろひっかかる所は多かった。これは役に立つ、ということかもしれない。 たとえば、ドキュメントには、 「次のプログラマがプログラムの適切な理論を構築する際に役立つものを入れるべきである。」 という。何を書けばいいのだろうか、途方に暮れる。しかし、コーバーンは続ける。
熟練した設計者は、以下のものだけで書類作成を始めることも多い。
- メタファ
- 主な各コンポーネントの目的についてのテキスト記述
- 主なコンポーネント間の相互作用の図
私のようなものがこれができるだろうか。できなければいけないのだが。
標題に「再考」とある通り、ソフトウェアパターンについて読み手があやふやな知識しかもっていなければ（私の事だ） そのままでは読みこなせない。また、各章の連関も体系だてられていない。 読み手内部で整理する必要がある。
プログラミングに関する方法論としては、確かに奇矯ともいえるかもしれない。しかし、 プログラマが本来憧れる姿でもある。テストを中心に据えるのは勇気がいるが、これが身に着けば百人力だろう （事実、この本を読んでから、テストコードをプログラムに埋めるようにしている）。 そして、この本の主な主張は奇矯でもなんでもなく、ごくまともなものである。 プロジェクトを行なうチームの組織や進捗管理について、きちんとした解を提示している。 この本もまた、「プログラマの視点から大局を見る」ということの大切さを教えてくれる。
まりんきょ学問所 ＞ コンピュータの部屋 ＞ コンピュータの本 ＞ 設計方法論
