大きな泥だんご
大きな泥だんご。英語で Big ball of mud。
理解可能なアーキテクチャが欠けている ソフトウェアシステム のこと
でたらめに構築され、乱雑で無秩序、ダクトテープで繋ぎ合わされたようなコードのジャングルのこと
無秩序な状態のことです。結局きちんと設計されたソフトウェアなんてほとんどない、特にそれは最近の Agile の流行の中で助長されているのでは？
なんでこんな作りになっちゃってんのか分かんないけど、表面上はとりあえず動いている、という、世のシステムの9割がたが該当する状態のこと。
なんで泥だんごになるの
理解可能なアーキテクチャが欠けている、ということは、理解可能な構造にまで落とし込まずに実装した、ということ。
乱雑で無秩序ということは、既存の構造と乖離した構造を無理やり繋ぎ合わせた、ということ。
極端な話、既存コードの設計が多少イケてなくても、追加コードは既存の設計を真似て作って馴染ませてやった方が、全体としては読解しやすくなる。イケていなくても、それはそれで「規則性」ができるからだ。
無秩序というのはそのとおり「秩序がない」わけで、「こっちのコードはこうなっている」「でもあっちのコードはああなっている」というシステムは読みづらい。イケていない設計でも「全体としてこういうダサい設計をしてるんだな」という秩序が読み取れるほうがマシなのだ。
さて、なぜこんな実装になるのか。人間誰しも、自分が手掛けて作るなら、最初から汚くて最低なものを作ってやろう、とは思わないはず。最初はきっと志高く、ああしようこうしようときっと考えているはずなのだ。それなのになぜ泥だんごが出来上がるのか。このあたりが理由ではないだろうか。
- プロジェクトマネジメントがなされておらず、プログラマに対する圧力のみで開発されているとき
- 恐怖駆動開発。十分な設計、検討がなされないまま、「とにかく動くものを出せ」と要求されているとき。
- メンバ間の情報連携が希薄で、似たような実装、もしくはコピペコードが乱立する。共通化がなされない。
- 予め設計しない
- 恐怖駆動開発の他、アジャイルを誤解している場合とか。
- 特に「共通設計」、たとえば命名規則や URL 設計、DB 設計が欠けていると、「その画面を担当した人が自分ルールの命名規則で URL 設計を行う」といったシーンがあちこちで生まれ、統一感のないシステムができあがる。
- マネージャが先々までのガントチャートを引かない・引けない現場では大抵こうなる。
- コードに対する意識が低い
- 「設計書には手続きが型で書いているのだから、実装で勝手にメソッド化なんてされたら困るよ」という理由で、文字列連結のメソッドをコピペして各所に埋め込み直したことがある。汚いコードが推奨されていたのだ。
- もしくは実装者の手抜きで、どこかから拾ってきたコードを考えなしに使う「コピペ駆動開発」が横行していて、それを監視する人がいない。
- こうした理由でコードに対する意識が低いと、「設計書だけはリッチかもしれないが、改修不可能」なシステムが出来上がる。実際に動いているのは設計書ではなくコードなのに、システム屋がコードを見ていないからだ。
- 予めツギハギによる成長を企んでいるシステム
- 「フェーズ1」「フェーズ2」といった単語が出てくるシステムはそういうこと。当初から増改築を繰り返そうといるのだが、大抵は増改築に対応したアーキテクチャ設計なんてできていない。
- 大抵は、コードを見られないシステム屋が設計しているせいで、コード・フレンドリーな設計になっておらず、強引な結合やコピペ駆動開発をせざるを得ない状況に追い込まれる。
- そもそもフェーズ分けをする時点で各フェーズに十分な検討・設計期間なんて設けられていない。そもそもの要求とスケジュールに無理があるから、契約以前のコンペの時点で、崖に向かって歩いているのだ。
- 顧客要求がすぐ変わる
- 実装中にその機能の削除が決定するなど。
- 法令的にその対応が必須な場合もあるが、いずれにせよ、そのような要求をコロコロと取り入れる環境は、間違いなくまともなシステムなんて生まれない。「仕方ないけど上手くやれ」はできないのだ。「仕方ないのであれば、仕方ないシステムにしかならない」のだ。
どうしたら泥だんごにならないの
- コード・ファーストな設計
- 使用する言語・フレームワークの特性を活かした設計を行う。
- オブジェクト指向が分からない人間に設計をさせない。
- 各画面の詳細な仕様書はともかく、共通設計だけは時間をかけよう。
共通設計 = 共通認識。メンバが何を指針として実装していけばいいかを決めるものだ。
- 中長期的なスケジュールを立てる
- 「機能追加が発生するとしたら、いつ頃・どんな内容か → それは現在開発中のシステムにどうドッキングさせたらいいか」といったことを事前に考える。
- 拡張可能なシステムになるよう最初にアーキテクチャを練る。
- 大抵は事前にいくら考えても思ったようにはいかないものだけど、何も考えていないよりはマシになる。
- 負け戦が確定している案件に携わらない
- プログラマが担当案件を選べたとしたら、「コード・スメル」ならぬ「プロジェクト・スメル」を感じ取った時点で、関わらない方がいい。
- そんなことは到底できないだろうけど。
