2017/05/26 10:53:04
kazeburo
良い話
2017/05/26 11:07:28
tsutsumi154
老人かな
2017/05/26 11:08:21
ytRino
とりあえず消して様子見れる環境はないのだろうか…
2017/05/26 11:12:10
lesamoureuses
このためにとりあえず放置してしまってあとで面倒なことによくなる “(1)使っていないハズ、でも実はそうではないかもしれない”
2017/05/26 11:14:07
suzan2go
わかる “複数住所が必要になったのはそれだけサービスが発展したということです。 私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。”
2017/05/26 11:17:06
oopsops
素晴らしい “複数住所が必要になったのはそれだけサービスが発展したということです。 私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。”
2017/05/26 11:17:15
naari_3
同じ目的のことを確認不足のままやってしまい、消したことで一部の本番環境が動かなくなったことが最近ありました
2017/05/26 11:17:18
codehex
良い話。
2017/05/26 11:33:45
catatsuy
めっちゃ分かる
2017/05/26 11:46:52
tsucchi1022
いい話だ
2017/05/26 11:59:04
side_tana
いい
2017/05/26 12:22:44
ore_de_work
クックルンの圧迫がすごい あれだけで 1TB食ってる
2017/05/26 12:24:50
anosuteki
> 後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。  というところが良かった
2017/05/26 12:27:17
rjge
“不要とわかっていてもビビリながらの対応” 絶対大丈夫って保証されてても本番DBからテーブル消すのってストレス負荷がすこぶる高い
2017/05/26 12:35:44
ngmy
いい話。
2017/05/26 12:36:05
Agrius_Akita
日々蓄積してる、いまは(人員能力その他の理由で)使ってないけど、宝くじが当たるくらいの幸運が舞い込んで人員が増えれば活用できるはずのデータも削除したい
2017/05/26 12:45:09
golden_eggg
ちょうど同じような対応したばかりでタイムリーな話で共感しか無かった
2017/05/26 12:50:45
bonar
いきなり消さずにリネームするというのがなるほど。
2017/05/26 12:56:55
ZuiUrs
「後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。」
2017/05/26 13:01:58
masaru_b_cl
「データベース・リファクタリング」の話だ。
2017/05/26 13:20:45
Tomato-360
“現状だけを見て「これはおかしい、負債だ」と言うべきではありません。”
2017/05/26 13:21:34
mexxx
「後から入った人間が現状だけを見て「これはおかしい、負債だ」と言うべきではありません」には同意できない。歴史的敬意の尊重と理解は大事だが、むしろ後から入った人間には真っさらな段階で現状を捉えて欲しい。
2017/05/26 13:26:57
naney
そういうのいっぱいあります。あれ masartz 氏いつのまに。
2017/05/26 13:33:51
progrhyme
撤退は段階的に。まずは可逆的に。
2017/05/26 13:41:52
pokemofu
分かる。いらんデータなのにいつまでも残ってるやつとかあるんだよね
2017/05/26 13:43:25
katzchang
掃除好きだよなー。
2017/05/26 13:44:27
sds-page
一月様子を見て大丈夫だと思ってたら年末調整とかの年一処理でいきなり必要になる類の奴
2017/05/26 13:44:42
su_zu_ki_1010
恥ずかしながらリネームするという発想が無かったので目から鱗でした。
2017/05/26 13:48:20
n_231
きちんと掃除せずに放置されてたのは負債だと思うけど・・・
2017/05/26 13:48:43
enicalpha
要らないものを捨てるには下準備と決断が必要
2017/05/26 13:50:32
luccafort
一度リネームするというのが目から鱗が落ちる思いだった。dump取っておいてあとで戻せばいいやでぼくならDropしてしまう、正しい技術的負債の返済の仕方だこれ。あと1ヶ月という期間も良い。
2017/05/26 13:59:41
b_kaxa
“ 歴史的経緯はサービスの発展の証です”
2017/05/26 14:01:54
monday23
保険かけながら対応していていいね。全然使われてないサービスでもビビるので、これだけ流行ってるサービスだとビビリ度も高くなりそう
2017/05/26 14:02:35
t-wada
尊い。一度リネームして安全なことを確認してから削除する慎重さや、 "私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません" という姿勢が良い。
2017/05/26 14:18:25
greencoffeemaker
会計系システムを経験した身としては1ヶ月だと短くて四半期末や年度末に何かおこるのではないかとドキドキしてしまう…。
2017/05/26 14:22:47
onigra
絶対殺すマンだ
2017/05/26 14:23:42
wordi
静的解決できない事の辛み、コンパイル言語なら紐づいたORMクラスのrename時にコンパイルエラー出なかった、で済むのに
2017/05/26 14:25:56
J5a
お掃除とても良い。
2017/05/26 14:26:04
rlans
こーゆー反社会的みたいなこと言われてる会社でエンジニアするモチベーションって何なんだろ。お金と技術以外には興味ないのかな。結構本気で気になるんだけど。
2017/05/26 14:30:27
naopr
べき論でいえばテーブルを1対多にした担当者が古いテーブルを消すところまでやるべきなんだが、忘れちゃうこともあるもんなー。いい話
2017/05/26 14:32:31
takatoshiono
対応内容もすばらしいけどそれをブログ記事にするのがとてもよい
2017/05/26 14:47:47
newmind
テストないのか?
2017/05/26 14:47:54
vivit_jc
いいはなし
2017/05/26 14:51:47
Kiske
いいそうじ
2017/05/26 14:57:35
FromAtom
すごい良い話
2017/05/26 14:59:46
papix
“歴史的経緯はサービスの発展の証です。”
2017/05/26 15:04:23
honeybe
ストレス度高い作業だ
2017/05/26 15:08:18
kurakano
なるほどリネーム
2017/05/26 15:09:41
i43s
rename大事ですよね。rmよりまずmvとかもよくある。
2017/05/26 15:11:05
n314
テーブル単位だと結構分かりやすいけども、列単位だと見逃してることよくある。
2017/05/26 15:22:15
momota10
なるほどまずはrenameか。
2017/05/26 15:31:11
kkobayashi
良い知見の共有ですな
2017/05/26 15:32:37
siroken3
いつもありがとうございます
2017/05/26 15:45:07
ssig33
偉人だ
2017/05/26 15:45:54
cl-gaku
残してると毎回これなんですかって聞かれたり、うっかり参照しちゃったり、ろくな事にならないのになかなか消せないんだよな
2017/05/26 15:46:57
oukayuka
テーブル名の付け方に違和感。ふつうはusers_addressesってusersテーブルとaddressesテーブルのn:n関係性テーブルと思う。
2017/05/26 15:47:13
sky-y
勉強になる。 “今回も実際に消そうと試みて初めて 実は使ってた ことに気づけたため、やってみて良かったと思っています。”
2017/05/26 15:48:32
shinme_chan
「テーブル名_日付8桁」って名前でいつまでもゴミデータが残ってるシステムの管理者さん。見てるー?^^
2017/05/26 15:53:57
kuniku
データベースによっては、rename できなかったり、renameしたことでCDC(change data capture)が動かなくなたり、CDC再設定が必要だったり
2017/05/26 15:55:23
sionsou
怖いよねぇ・・・動くだろうけどたとえばcronだけで使ってるとかユーザー(管理者う含め)には操作させないけど裏側の自動処理で動いてるとかありえるから怖い。
2017/05/26 16:08:21
hiby
>現状だけを見て「これはおかしい、負債だ」と言うべきではありません 結局「なにこれ」→「使ってないよ」→「ゴミじゃん」のプロセスは踏んでるわけで単なる言い方の問題と思うんだよね。性善説。
2017/05/26 16:09:40
Kil
『後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません』そうね。でも、「後から入った人間こそ、現状を見て「これはおかしくないですか?」と言うべき」でもある。
2017/05/26 16:22:56
kaeuta
DBを扱う者としては基本的な所作であり正しい(1か月は逆に早くないかと思ったが)。最後に削除するまできっちりやる事や明らかに削除してもよさそうなテーブル名を付ける事は細かい点だけど重要
2017/05/26 16:26:34
atsushifx
これもリファクタリング。データベースのような複数のシステムにまたがっているリソースのリファクタはかくも難しい。APIやメソッドもそう
2017/05/26 16:40:19
yuzurus
わかる。サーバの終了作業とかもそう。
2017/05/26 16:46:35
i2i
あるあるあるあるwwwwwと思ったけど、弊社の場合来世紀まで持ち越しになりそう。
2017/05/26 16:50:55
kabochatori
なぜフェンスが建てられか分かるまで撤去してはならない的な?
2017/05/26 16:57:05
naratas
“一つの住所で済んでいたのが、複数住所が必要になったのはそれだけサービスが発展したということです。 私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。”
2017/05/26 17:08:49
june29
いきなり消さずにまずはリネームするの、いいな。そして既存コードと先人たちに対する敬意があるのもよい。
2017/05/26 17:18:20
ho4416
いらないものはメルカリで売ろうという話かと思った
2017/05/26 17:23:07
fukken
こういうの、あるあるだなぁ
2017/05/26 17:44:36
bkios
メルカリを反社会的プロダクトとか言ってる馬鹿はなんなんだろ。なにも考えず周りが叩いてるから叩いてる的な脳足りん感があるな…w
2017/05/26 17:47:34
sucelie
ヤバげなものはとりあえずリネームで様子見するよね
2017/05/26 18:04:49
snowcrush
過去と状況が変わったから不要になったもの自体は負債ではないけど、状況が変わった時点で不要なものを残すのは負債だと思うんだよなあ。もちろん記事にあるようなケースはありがちだとは思うんだけど。
2017/05/26 18:08:44
nippondanji
現場の葛藤がよく伝わってくる味わい深い記事。
2017/05/26 18:20:57
hirokidaichi
「絶対に負けられないハズだけど、なかなか勝てずにいるもの」がそこにある!
2017/05/26 18:25:55
ngyuki
要らなさそうなものをとりあえずリネームしたあと忘れ去られて1年後とかに何だこれはとなることまれにある
2017/05/26 18:28:39
tail_y
“「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話”これ、DBに限らず凄い重要な話だ。いらないものの削除量でコードの綺麗さが決まると言っても過言ではない。
2017/05/26 18:35:33
rti7743
要らないファイルを消すときのお約束だよな。とりあえずリネーム。 もちろん、やる前にバックアップがちゃんとあることとかの確認は必須だけど。
2017/05/26 18:40:32
hearthewindsing
"joinした"、"dropしました"の言葉づかいがモゾモゾするんですが、これは業界標準なんでしょうか?
2017/05/26 18:53:08
rryu
気軽に消すと存在すら忘れていた部分から参照されたりしていてある日エラーになるやつだ。
2017/05/26 19:09:31
otihateten3510
1ヶ月かけてやるのお手本っぽい でも切り戻し不可能なケースはできないんだけどね。 / 「負債だ」は言うべき、じゃないとキッカケが生まれない。言った上で相談し柔軟に対応しましょう。
2017/05/26 19:22:43
murasaki11
すでにどこからも呼ばれていないコードからの参照はgrepで出てこなかったのかな
2017/05/26 19:29:27
kappa_no_ojisan
ゆとりの法則
2017/05/26 19:32:37
tick2tack
「動いてるコードをいじるな」な世界で何かを削除するのは難しいが、少しずつでも安全にやる手法が確立されていくといいよな
2017/05/26 19:40:22
hase0831
カッコいい。こういうの大事 “私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません"
2017/05/26 19:44:48
karupanerura
尊い
2017/05/26 19:52:13
h5y1m141
なぜそういう流れで行なったか丁寧にこういう感じで書いてくれてて、参考になる。近いうちにこういうことを少しづつだけど着手するから考え方を真似しよ
2017/05/26 20:03:35
securecat
“歴史的経緯はサービスの発展の証”視点に共感
2017/05/26 20:11:17
dowhile
言うべきでない、といいつつブログネタにはするのね
2017/05/26 20:12:58
mobits
消さなきゃいいじゃん(鼻ホジ) いやマジでここまでして消す意味ってなに?
2017/05/26 20:15:40
kaizokuyobare
なるほど
2017/05/26 20:36:01
Falky
『私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。』確かに…。新参だからこそのフラットな目線!などという無邪気さを盾に、やってしまうことある。反省
2017/05/26 20:37:07
hogetahogeko
RENAME
2017/05/26 20:46:25
jaguarsan
テストとか検証環境はどうしたなんてコメあるけど、そんなの当たり前以前の問題でそれでも不安になるって話だろ
2017/05/26 21:14:06
kno
RENAME TO "no_more_use_users_address"
2017/05/26 21:34:53
wyukawa
参考になる
2017/05/26 21:56:00
teto2645
うちの新人さんは平然と消しちゃいけないテーブルをtruncateしてくれたわ。懐かしい。頭の一部がスッと冷静になる感を思い出した。
2017/05/26 22:12:53
djwdjw
新テーブルを作った時点で旧テーブルへの更新処理もなくなってるのでは?残ってたっていうAPIが旧テーブルを参照し続けてたなら更新されない古いデータを参照してたって事なんじゃ…?それはそれで大丈夫なのか?
2017/05/26 22:21:45
nai_nari
できるなら、年間で置物化して、様子見たいところです。機能的に月次周期以上のスコープがないとしても、データの問題があるので。期またぎ付近でしか発生しないデータとか。
2017/05/26 22:44:50
cross_black777
“歴史的経緯はサービスの発展の証です”
2017/05/26 22:46:03
Pocket7878_dev
なるべくこういうの早めに手を打てるように脳内ウザい部外者を飼ってる。なんでこんなコードごちゃごちゃしてんのバカじゃねと囁いて来てセッセとmvpの時代からの移行を促してくれる
2017/05/26 22:53:25
jnoir
メルカリ社が一部で反社会的って言われてるのは確かだと思う。技術ブログにこの手のコメするのはバカだと思うけど、日本語読めずにプロダクトのフォローしてる人もバカだと思うなぁ。もしかしたら中の人かな。
2017/05/26 23:32:28
braitom
あるよねー。“絶対要らないハズだけど、なかなか削除できずにいるもの はどこの環境にも割とあると思います”
2017/05/26 23:44:23
madridNewyork
個人情報をカジュアルに扱ってる印象
2017/05/26 23:56:28
howtomania
なんだ、領収書とかかと思ったわ
2017/05/27 00:55:52
leiqunni
削除の段階は、リネームして悲鳴が上がらないか→何日か忘れるまでそのまま→問題なければ、バックアップもあるし削除。バックアップがあるからと思わないとなかなか思い切って削除とかはできない。けどkeep it simpleな
2017/05/27 04:21:29
yooks
“歴史的経緯はサービス発展の証"、"後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません”。これは大事な考え方だなあ。肝銘メモ
2017/05/27 07:24:16
uturi
興味深い事例。後から見れば「なんでこんな設計に!」と思うことでも、歴史的経緯があると仕方ない場合も多い。1ヶ月の検証期間を設けたとしても本番データから削除するのは勇気が要りそう。
2017/05/27 09:13:12
JURI510
“複数住所が必要になったのはそれだけサービスが発展したということです。 私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。 ” この考え方は心に留めておこう
2017/05/27 11:08:46
somemo
現状「を」見て「これは現状にあってないのでおかしいと思うのですが、どういう経緯ですか?」というテンプレが広まればいいのではと思った
2017/05/27 11:19:15
gebonasu30km
どこぞで見つけて思わず保存したツボにハマったヌード画像の話かと思った
2017/05/27 11:45:30
qsona
"(2)については、全く問題なく、そうあるべきと考えます" 本当かしら? 少なくともそのチーム直属でないものがDB直で叩くのは相当イレギュラーとしないと辛そう
2017/05/27 12:49:06
garage-kid
473: テーブルへのアクセス状況って統計情報とかからとれなかったっけ?っていう素朴な疑問。
2017/05/27 17:06:35
HolyGrail
“後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。 その上で、今後もまた次の発展していくために、現時点で解消できる課題は対応しておくことに価値がある”
2017/05/27 17:14:33
ono_matope
"歴史的経緯はサービスの発展の証です…私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。" いい…だからこそ負債をガンガン返済していくのが古株の責任よな
2017/05/27 17:20:27
Songmu
ちゃんとしてる
2017/05/28 00:48:40
berlysia
尊い話だ……
2017/05/28 01:43:14
Chisei
本番の drop table は気が気じゃない。
2017/05/28 02:08:59
toritori0318
本当にめちゃくちゃ良い話
2017/05/28 06:18:54
tyru
良い
2017/05/29 15:22:43
masayoshinym
“私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません。”聖人君子案件。
2017/05/29 16:36:58
kadoyau
直でDropせずにAlterする
2017/05/30 08:35:54
KoshianX
削除はホント怖いよねえ。ユーザーは気軽に消しちゃうしシステムファイル削除しちゃったりもするけど、それでバグだと騒がないで欲しい……
2017/05/30 13:17:41
kasei_san
技術的負債をディスるのではなく、サービス発展の証だと捉えて、その上で現状の最善はなにかを追い求める話。