既存コードの甘い匂い (悪意なきチグハグコードの誕生) - jfluteの日記
まえがき 前提として、しっかりとコーディング規約やコーディング手順などが整備されている現場ではあまり関係ないかもしれません。 そういうのを整備して実践していことが難しい現場、スタートアップからインクリメンタル開発を経て、成長していくサービスを長期間作り上げていく事業会社が主なターゲットの話かもしれません。 既存コードに if 文がありました さて、あなたが開発現場に途中から参画しました。すでに A と B という別の人が作った画面があります。 あなたは C を作ります。C は A と B と似ています。 「さあ、作ってください」 と言われました。どうしますか？ ... まあ、普通に考えたら、A と B を参考に作りますよね。ここに甘い匂いがします。 A と B には、とある定型の if 文による制御がありました。C では一見、要らなそうに見えますが複雑でよくわからない。 C でも if 文
論理削除がデータを汚している - jfluteの日記
ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 本来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、本体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
