新規開発でもリファクタリングでも同じことは言えると思うが。

ハードや仕様が変わってもソフトは一切変更しないで済むように、というのは根本的に不可能な命題であり、

元は「仕様やハードに変更があっても、ソフトの変更は極少で済むように、変更されそうな部分を局所化しよう」という目標であったはずで、

目標を極端に設定すると実現不可能なだけではなくて、元の目標も失われる。

今仕事でやろうとしているリファクタリングはとても「何か違うんじゃねーのかな…」感が強いのだけど、それを強く言える程上手く説明できない。

どうも手法先行になってるというか、仕様がとっ散らかってるのに、その仕様の整理無しにソフト開発手法に凝って完璧なソフト目指すのは無理ちゃうんか…。

「幹」みたいなもんが無いんだよな。

「幹」というか「芯」というか、「このシステムのメインの流れはこれ!」というのがあれば、残りは枝葉として付けてやれば見通しの良い構造になるのではないのか。

そういうの無しに「アレもコレも全部大事!」ってやっちゃって、それでそのままコーディングするから、変更重ねるとすぐにスパゲッティ化するのではないのか。

仕様の削減を要求することは無理でも、それならこっちで仕様の洗いだしを完璧にした上で「幹」を浮かび上がらせる必要が、本当はあるのでは。

要するに論点はその「幹」を仕様分析で探すかソフト解析手法で探すかってところだろうかな、多分。


2013年12月10日 シゴト・ジツ トラックバック:0 コメント:0

| むなかた思考TOP |