どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論

恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま

[prograti]

"今のサービスに機能を追加していくという事ではなくて、ゼロベースで機能追加された後のサービスを作るとしたらどう整理するか" / こういう考え方が出来るのは素晴らしいですね

[satosssi]

正直に過去の自分と向き合ってて良いですなぁ

[aktkro]

「恥の多い生涯を送って来ました。」って書き出しが好き。

[turanukimaru]

いやコレ問題はDBじゃねぇというかDBにこだわりすぎじゃねえかな。私ならチケットとか各劇場ごとに発行アルゴリズムを用意して切り替えるようにする。てか集約ルートが不明だな。集約ルートが大事だ子は何とでもなる

[lordnoesis]

「あれば売ってくる」で始まって本当に売れてるの強いな。

[nabinno]

データモデリングやる人は先にERP機能を大方把握しておいた方が良いと思う。販売管理機能は最も負債になりやすい領域ではないだろうか。

[onesplat]

これは確かに恥ずかしい。晒す勇気はすごい。とにかく命名が良くないよねどれもこれも

[rryu]

データ構造の技術的負債の話。お金関連の要件が出てくると破綻しやすくなるというか、ひとつの商品の売値はひとつじゃないというのが最初の罠だよな…

[indication]

DBスペシャリストの試験問題って、結構現実味があったのだなと思った（落ちたけど）

[Eiichiro]

コノ複雑な設計をUIに押し込めてれてる時点ですごい。複数のユースケースがあるのだろうか。 自分なら、ユースケース別にテーブル自体分けたくなりそう。処理系だけ切り離して、再利用できる形にしたうえで。

[pmint]

長い。伝わらない。独自用語も多い。まるで日本語とは別の言語。コードもひどいに違いない。「グルーピングタグ」はおそらくラベルのことだろうけど、この文章から正解を出せる気はしない。

[cl-gaku]

わかりすぎてつらい！

[mkusunok]

設計負債の返済って名目では予算要求しづらいんだよなー。国債のように債務に応じて利払費を積めればいいのに。設計負債は算定が難しい上に、利子の概念がないことが問題なのかな？