インデックスや結合の効率について

X氏を観察していると、コーディングとデバッグはやたら速いが、インデックスや結合の効率については理解していないようだ。


コードロジック上でのステップを最小化することにはすごく拘っているが、DB実行のコストの知識がないから、インデックスが効いていないフルスキャンにしてしまったり、大きなトランザクションテーブルなのにネステッドの結合にしてしまったり、JOINとインラインビューを同時に使ってCBOを殺してしまったりしている。


しかしこの現場は設計工程が形だけで、リーダーがCBO観点でのレビューなんかしないから、倍速コーディングが自慢のX氏は無敵状態で誰も逆らえない。


動くプログラムの現物が出てくることがとにかく偉いので、コーディングの手が速い人が一番偉い。オレより遅いヤツは口出しすんなって感じ。




予想ではおそらく、新機能であるこの画面を作った際に追加しているテーブルのインデックスに問題がある。


追加した新規テーブルは、そのテーブルそのものは規模は小さいが、データが重いイメージテーブルと結合する必要があるテーブルなので、イメージテーブル側がフルスキャンにならないように結合順やインデックスの優先順を指定していかないとまずいはずだが、それを意識している気配がない。


しかしチームでコーディング最速エースのX氏に、それだと遅いですよとは言えない。
ものすごくプライドが高くてエースの誇りに満ちているX氏に「遅い」なんて言ったらタダでは済まないだろう。




ひと昔前までは、プロジェクト全体のことを考えたら気まずいことでも提言するべきだろうと考えていたが、リーマンショック以来、仕事が細くなって案件を確保するのが難しくなり、上流の会社や先任の技術者の機嫌を損ねるとあっという間に席が無くなって契約が切れてしまうので、これはまずいよなぁと思っても言わずにスルーすることが増えた。


貧乏になって仕事が細くなればなるほど、上流の会社も下流の作業者も保身に走り、Yesマンばかりになってリスクを避けるので、結果としてはむしろ問題が解決されないまま放置プレイになって次の火種の地雷を埋めて回ることになり、悪循環が続く。


まぁ本当にダメな現場だ。あのハゲの下請け企業なだけに、改善されることはないだろう。
サービスが悪いことで有名なハゲの会社だが、中に入ってみてそりゃ当然だと思った。