【開発哲学5_5】『データベース・リファクタリング データベースの体質改善テクニック』第５章 データベース・リファクタリング戦略
感想
データベース・リファクタリングに必要な手法を概論的にまとめてる章て印象。
ここを見返せば、全体を素早く理解できそう。
小さい変更のほうが行いやすい
なんて、これまで記事にしてきた
『CODECOMPLETE』
や
『リファクタリング』
でも書かれてたことだから、データベースにも通底するねえ。
結局、
後からまとめて直せばいい ＝ バグの原因
てことは変わらないってことだね。
好きな格言
「象をどうやって食べるか。一口ずつだ。」
マジ好き🕺
詳細
見出しとしては、
小さい変更のほうが行いやすい
個々のリファクタリングを一意に識別する
大きな変更を多くの小さな変更に分けて実施する
データベース構成テーブルを作成する
ビューやバッチ同期よりもトリガーを使う
十分な移行期間を設定する
データベース変更管理委員会を簡素化する
他チームとの協議を簡単に行えるようにする
データベースアクセスをカプセル化する
データベース環境の設定を簡単に行えるようにする
SQLを重複させない
データベース資産を変更管理下に置く
政治的駆け引きに注意する
この章で学んだこと
てな感じ。
13項目に書いてることは、
理想だし、こうあるべきなんだけど、
ほとんどの現場でそれができないからこそエンジニアが苦労してるんだ
って声が聞こえてきそう、、、💦
特に、
政治的駆け引きに注意する
なんて。
社内政治なんて関係ないと突っぱねられれば、苦労はないよねええ。
ま、そう言った瞬間から、次に中々仕事が回ってこなかったり、請負先が見つからなかったり苦労することもある。
できないと、
根本的な改善にはならないし、部分的で小手先な改修や運用保守で時間がかかるだけなんだけどね。
どちらを取るかは、個人や組織の状況と判断次第
大半のクライアントが、
実データを見ずに要求と納期だけ固めて、想定外のデータしかないと判明する。
↓
○物理的に無理なのにそこをエンジニアならなんとか出来て当たり前てゆークライアント側のメルヘン
＋
○お金が欲しい受注した開発会社（ベンダー）の経営陣の思惑
＋
○すでに最新の環境で開発したことないレガシーエンジニアから振りかざされる、自分たちの時代は何とかしてきたてゆー職人気質
などが交錯する。
👉政治の始まり
まとめ
💃所詮DBも政治が絡む。てか、DBほど政治が絡むかな🕺
さてと、
これで総論部分の１〜５章は終わりー！
各論の6章以降に入っていきまする〜〜〜