2006-02-26

近況

サプライズつづき.

サプライズ 3 : UML を書く設計者

私は今のプロジェクトに途中から, 具体的には顧客へのヒアリングがだいたい終わったあたりでプログラマとして参加した. 上司はこれまでに作成された機能仕様書(2/3 くらい確定したもの)と 他のチームのメンバが書いた UML を渡し, "これで作ってね" と宣うた. これが噂の "上流工程" か! 設計と実装を別の人間が担当するケースは 噂に伝え聞いてはいたが, コード量が 1 万行に満たない規模のソフトウェアで それに出会えるとは運がいい. その UML は単一クラス図だけを含んでいた. 静的な設計からそのソフトウェアの動的な側面は自動的に導かれるという立場だろう. クラス図にはおよそ 20 個ある全てのクラスが集約されており, 一覧性を高めている. クラスにはすべてのメソッドと属性が明記されていて曖昧さはない. ノートのような自然言語を用いないところにも 曖昧さを排除しようという強い意思が感じられる. 継承の矢印は上から下へ向かっており, まず具象クラスという具体例を示し そこから共通点を抜き出し汎化するという モデリング・プロセスを読者にわかりやすく示している. 関連の線は幾重にも重なっており, ソフトウェアの持つ本質的な複雑さを不用意に隠蔽しない. 設計者の深慮が伺える.

残念なことにその設計は十分に曖昧であるにも関わらず いくつかの明らかな欠陥を含んでいたため, 仕方なく破棄してざっと作りなおした.

サプライズ 4 : 障害データベースの不在

入社当時, 私のいるチームには一応の主力製品があるにも関わらず 障害データベースがなかった. あるはずのものがない... 障害データベースを眺めて主力製品が抱えている難しさを学ぼうと思っていた私に これは不意打ちだった. バグの一覧は Wiki ページに箇条書きされていた. なかなか agile だ. ただどれも記述が一行で再現方法や問題がよくわからない.

隣のチームが持っていた障害管理システムを間借りすることを提案したが, その後どうなったかは知らない. その製品と無関係な仕事に割り振られた私はとりあえず TRAC を使っている.

サイズライズ 5 : 正しさの確信

屈辱の休日出勤でサプライズ 1 の問題を修正し, 件のエンジニアに報告したところ そのコードが動かなかった事実をなかなか信じてもらえなかった. 問題の箇所を説明し, フレームワークの拡張のうち必要な部分が すっぽり(1000 行くらい)抜けおちていたことを説明して コードを具体的に示したところ, ようやく納得してもらえたようだった. その自信の強さに心打たれる. たとえば, 彼はバージョン管理システムを使わない. 失敗をしないという前提に立てば cvs や svn はまったく意味をもたないのだろう.

私には自信が足りないのかもしれない. 動かすまでもなく自分の書いたコードは正しい; そう思えるようになりたいかといわれるとわからないけれど.

かくして日々の驚きは尽きない.

洋書行

加速する残業に目標ラインすれすれの低空飛行が続く. まったく...

Databse ... は正規化の話で挫折. 以前にも他の本で挫折した記憶あり. 苦手だ... そのうちもっと易しいやつを探して読もう. Ajax ... はたいして面白くないものの適当に読める本というコンセプトには合致. かなり読みとばしている. もっと薄くていい.