デザインリカバリ

実装が先にあってその実装にたいしてなんらかの拡張、変更、修正が必要であるとする。あなたがオリジナルの実装者ならどこになにがあるかすみからすみまで知っているので何が問題なのかというような話であるが、通常は、誰かが書いたコードをなんとかしなければならない。よく知らないコードを変更しなければいけないという状況である。

オープンソースのプロジェクトでよく聞くことは、いわゆる設計文書がほとんどない。あるいは内部実装の詳細について記述した文書がないというようなことをよく聞く。半分愚痴交じりに聞く。Linuxなんかだと最近ではカーネル詳解なんかがあるがPostgreSQLだSambaだApachだとどーなのだろう。

ソフトウェア工学の教科書なんかを読むと、古典的なウォーターフォールモデルでは、
- 要求分析
- 概要設計
- 詳細設計
- 実装
- 単体テスト
- 統合テスト
- 運用
みたいなフェーズにわかれていて、それぞれで詳細な文書なりなんなりを作るという建前なのでそれぞれのフェーズで大量の文書が残っているはづである。それを読めば実装の詳細について理解が深まるのではないだろうか？と思うのは人情である。

ここに今あるバグをともかく早いところ修正しなければいけないという火事場騒ぎのとき、この部分の実装について詳細に記載した文書があればなあなどど切望してもたいていの場合はそんなものはない。

そのそもオープンソースプロジェクトにしろシリコンバレーの大規模ソフトウェア開発の現場にしろ古典的なウォーターフォールモデルなどを採用していないのだから、そんな文書ははじめっから存在しないのである。（今明かされる衝撃の事実）

実装の詳細について解説した文書がほしいというのはないものねだりに等しい。

だけど、このバグを今週中にフィックスしなければいけない。このチームに入って３日目でまだチームメイトの名前すらよく覚えていない。（ありがちな状況である）

入社一日目は人事関係のオリエンテーションだ。年金がどーだとか、健康保険がどーだとか、４０１Kがどーだとか、経費精算の方法がどーだとか。オフィスツアーと称して同僚を紹介されるが、いっぺんに何人も紹介されるので、結局誰の名前も頭に残らない。入社二日目にプロジェクトリーダーにプロジェクトの概要を教えてもらう。開発環境のこととか、ビルドの方法、リグレッションテストの流し方、チェックイン、チェックアウトに関する、ポリシーとプロシージャなどなど。開発環境の話のなかで名前付け規約とかディレクトリ構造とか実装の話、いろいろなコンポーネントの実装についてとかオリエンテーションをうける。

そして３日目である。

プロジェクトリーダーから、OJTとして簡単めな仕事を与えられる。〜のバグを修正しろ。

プログラマとしての実践的な力をつけるためにバグ修正というのは非常に重要である。バグを修正できないプログラマはいない。（当たり前だけど）
http://web.archive.org/web/19990221063624/www.best.com/~yoshioka/d/95/10/i951016.html

10/16/95 デバッグの日々/未来のいつか

Ｂｉｌｌがこのバグちょっとみて〜というメールをフォワードしてきて まいっちゃたな，もう．
バグデータベースで症状の概要を読んで再現の仕方をＢｒｉａｎ に聞く．簡単に問題が再現できて，あ，これはひょっとして楽勝か？ （いつも物事は楽観的に始まり悲観的に終わる）

Ｄｅｂｕに感どころをざっと教えてもらって再度症状を発生させる． 今度はｇｄｂでバックトレースをとって，そのリストをもとに必要なモジュールを 再コンパイルしてｍａｋｅだ．とりあえづ関係しそうな数モジュールを 再コンパイルした．で，あ〜だこ〜だしているうちに，データベースこわして 再構築するはめになって，さらにうよう曲折があり，今にいたる．
今週中になんとかしたいものである．

という感じである。デザインリカバリの話にはたどり着かないうちに終わってしまった。すいません。そのうち続きを書くかもしれない。（こーやって、予告編だけはどんどん増えていく、とほほ）