デスマーチの作り方

http://itpro.nikkeibp.co.jp/article/COLUMN/20060309/232116/

とりあえず，すべての名詞がクラスになると仮定してクラス名だけのクラス図を作成すると図6[拡大表示]のようになる。

名詞抽出法は初心者の練習用がせいぜいだぞ．実用性はほとんどない．

(1)社長クラス，営業員クラス，事務員クラスは，複数の同じ属性を持っている。このことから，これらのクラスは1つのスーパー・クラス＊を継承＊したクラスとして整理できる＊2。ここでスーパー・クラスを「社員クラス」とする。

OOPの世界ではこれは明らかに継承の誤用となる．「設計者」や「UMLモデラー」が開発の足を引っ張る典型的な失敗パターンがこれだ．*1

＊２
【継承】succession
ここでは，クラスの機能を引き継いで他のクラスを作成するようなクラス間の関係を意味する。

専門用語としての「継承」は，普通は"inheritance"です．和英辞典で調べたんじゃあるまいな．*2

だが，図6のクラス図と比べると，クラスの数は11個から6個と少なくなるなど，整理されていることは誰が見ても明らかだろう。

何がどう明らかだというのだろう．これで納得するのは素人だけだ．

クラス数とシステムのシンプルさとの間には相関関係はほとんどない．むしろクラス数を減らす過程で無理な設計になり開発に支障を来すことの方が多いだろう．今回もそういう典型的な失敗パターンの一つだ*3．

プログラマの視点に立ったときに、保守性を高めるためにデザインパターンを活用して設計をする場合、往々にしてクラス数／メソッド数が増える（ステップ数とは相関しない）。クラスを増やすのに抵抗がある場合（例:クラス試験手順書・成績書を作成しなくてはならない）、納期プレッシャーの元ではそれを避けようとする力が働くことになるかもしれない。
保守性、品質について責務を持って開発の中に入って影響力を行使するような体制が必要です。
http://d.hatena.ne.jp/torutk/20060311#p1

特に今回の事例に関しては最初の候補が名詞抽出法で作られた物なので，比較する事自体が論外だ．*4

*1:「設計者」だとか「プロジェクトリーダー」だとかがこういう図を書き始めたら，そしてそれを「設計書」だと主張し始めたら，それがデスマーチ開始のサインだ．別プロジェクトに逃げるか，さもなくば転職することを考えよう．逃げられそうになく，しかも家族がいる場合は，遺していく家族のための生命保険や遺書の準備も検討すべきだ．準備には時間がかかるので，いざという時になってからでは遅いのだ．

*2:UMLだと用語まで違うのかね．というよりUMLにはOOPにおける継承が存在しないだけかな．あれはOOPとは全くなんの関係もない「21世紀のフローチャート」に過ぎないのだから．

*3:これもデスマーチ開始のサインなので，こういう時は上記と同様な対策をお奨めする．

*4:名詞抽出法で作られた「クラス」群は質が悪く，設計として考慮に値しないことが多い．「O(n!)のソートアルゴリズムと比較して３０％性能向上した」として，その性能向上に何の意味があろう．比較するなら平均以上，ソートアルゴリズムなら最低でもO(n log n)以上のものと比較すべきだ．