プログラム考古学?

なぜこのプログラムはわかりにくいのか?

まともなドキュメントが無い

というのはお約束なのであえて触れないw。

スーパークラスがでかくて複雑怪奇

サブクラスのメソッドはoverwriteすることもなくsuper.foo(x)している。スーパークラスのfoo()はxで処理を分岐させ、さらにsuper.bar(x,y)している。予想通りbar()は巨大なメソッド。これだとサブクラスを追加する都度、スーパークラスも修正しなきゃいけない。その上foo(),bar()には想定外のケースに対応するためと思われる多数のパッチ(if文)が追加されている。実際に処理される場所が遠いところにあるので、見通しが悪い。

メソッド内でプロパティを更新するのがでふぉ

Visual Baiscで言えば、Subでグローバル変数を更新するイメージ。それで処理をコントロールしているからたちが悪い。functionの戻り値を設定するとか、引数で渡すようになっていれば、まだわかりやすいのにね。

ORM風DAOが失敗作

はっきり言って糞。作成日付を見るとプロジェクトのごく初期段階に作成されている。最初から失敗する運命だったんだね。このプロジェクトは。使っていて使いにくい、わかりにくい、やりたいことができない、って感じなかったのかね?自分で作ったんだから、いくらでもリファクタリングできただろうに。あーなるほど。プロジェクトの途中からこの作成者のソースがコミットされなくなっている。つまりいなくなっちゃんたんだ。お気の毒様>残された人w

例外処理の概念が欠けている

エラーが発生したらエラーデータの構造体に必要データをセットして返している。いやfunctionならそれでいいけど、Subの場合どうすんのよ。と思ったら、そもそもエラー処理がない。あのさぁ~、プロパティにセットするとかしてでも、エラー発生を知らせなきゃマズイんじゃない?つーか、自分でExceptionクラスを作って、それをthrowするのがふつーだと思うけど。

テーブル設計がタコ

もしかして失敗作のORMに合わせて設計したのか?正規化がどうこういうレベルじゃなく、テーブルを画面のスクラッチパッドとして使っているようにしか見えない。これはもう奉行所に訴えでてもいいくらいの酷さ。

なんつーか、プログラムを作る資格を持たない人たちがやっつけで作った代物。そりゃ品質を期待するほうが無理だわ。

プログラムは些細なコードの積み重ね。しかしプログラムは些細なものではない。