開発の理由 - makotanのブログ

新人の頃から嫌いなもの(順不同)

判定文の多いソースコード
ネストの深いソースコード
テーブルにくっついてるフラグ
テーブルにくっついてる複数個のフラグ
RDBのデータ横持ち
画面設計とDB設計しかない仕様書
業務フローの書けないエンジニア
単なる表示の画面と思ったら画面から絶対に理解できない不可思議な条件式が多い画面
タイミングを間違えてるプログラムのチューニング

これらのかなりの部分を解決or問題にならない程度にするために作ったモノがs2buri。
まぁ・・・この中のいくつかはburiで解決する所じゃないなぁ〜と今でも思う。組織としての問題だよね。
(追記)
まず、判定文と各種フラグと不可思議な条件式に注目！
これが発生する理由を上流に向けてどんどん遡る・・・そうすると、業務の流れを画面で切ってることに気がついた(これに気がつくのに時間がかかった、思いついたからハマチを作った)
業務の流れを画面で切る＝業務の流れをRDBのトランザクションで分断する＝あるデータが業務の何処にあるのかを保持する必要が出てくる＝フラグが増える＝判定式が増える
こういう構図が見えてきた。
「あるデータが業務の何処にあるのかを保持する必要がある」ここまではある意味当然、で、次の「フラグが増える」これが思いっきり間違ってて、業務フローとデータがキッチリと結びついていればデータを保持するテーブルにフラグなんて要らないんじゃないかと・・・
つーことは、業務フロー＋データを管理してくれるプロダクトがS2界隈にあれば良いなぁと思いつつ色々と探してみたら
J2EE必須です、EJB使え！みたいなモノが多くて・・・あの〜ちょこちょこっと動かせないんですけど・・・みたいな(^^;
そうじゃないやつも納得できるスペックのモノはサーバ立ち上げてそれにあわせてコードも書いて・・・POJOじゃないしなぁ〜S2Dao使えないの！？
みたいなのが多くて、そうじゃなければ
フローをグラフィカルに書けます！っていう軽いやつ・・・データとの連係は無理(T.T)
良いのがあったかも！！って思ったらGPLとcommercialのデュアルライセンス(￣□￣;)!!
とまぁこんな感じで帯に短したすきに長し、じゃあ自分で作るかって事で作ったのがぶり２。