外部と内部を分けることの弊害 - masayang's diary
COBOL屋の呪縛に、ちょいと補足。 COBOL屋の呪縛ではフラグの話を書いたけど、フラグ以外の属性でプログラムの挙動を制御するのもCOBOL屋さん以来の伝統かも。極端に簡単な例で説明。 user = User.find(id) do_something_for_admin if user.category == 'admin' do_something_for_manager if user.category == 'manager' 継承を使えばif文は不要になる。それだけテストが減る。（この例は簡単すぎてテストの減らしようがないけど...）[*1] class Admin < User def do_something # do_something_for_admin end end class Manager < User def do_something # do_somethi
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
時間データを文字列としてデータベースに記録する仕様だったのでしょう。 - gwaihirのプログラミングとか色々日記
COBOL屋の負の遺産チェックポイントに追加 - プログラマーm-matsuokaの生存記録
