そーだいなるらくがき帳

そーだいが自由気侭に更新します。

Javaエンジニアに知ってほしいRDBアンチパターン その3 について話して来た #jjug_ccc

Javaの国内最大カンファレンス、JJUG CCC 2017 springで登壇してきました。
僕の中で先週のオープンセミナー岡山の熱がまだ収まらぬ中の登壇だったのですが、多くの方に聴いていただけて嬉しかったです!
その時の資料がこちら。

RDBアンチパターンについてはPHPカンファレンスYAPC:Kansaiでも話をしましたが、今回は別バージョンです。

soudai1025.blogspot.jp

soudai.hatenablog.com

あのときはWeb系の人向けに話をしましたが、今回はエンタープライズな業務系の人向けです。
業務系は僕の印象では制約だったり、RDBの機能を有効活用してる印象があるのですが、逆に過剰になっていることが多い印象があります。
また論理IDなどデータ量が少なかったり、アプリの改修が少ないから死ななかっただけの設計も多く見られる印象です。
そういう点を今回お伝えしました。
また最後の「監視されないデータベース」については、多くのシステムに言えると思っています。
これはMackerelのポジショントークでしょ?って思われるかもしれませんが例えばpg_monzやPercona Monitoring Plugins for Zabbixでも良いと思います。
まずモニタリング監視しましょう。
PostgreSQLで言えばpg_statsinfoやpg_stats_reporterもあります。
インフラを可視化するというのはテストコードと同じです。

mackerel.io

リファクタリングはダイエットと似ています。
テストコードもモニタリング監視も体重計と同じです。
体重計に乗っただけでは体重は減りません。
テストコードもモニタリング監視もそれだけではアンチパターンから救ってくれるわけではありません。
ですが確実に一歩づつ改善していけば、より良い世界に進んでいけますし、その進捗が見えてきます。
だからこそ、今の現状に不満がある(アンチパターンがある)のであれば、これを機に前に進んで貰えれば嬉しいです。
品質の向上のために必要な初めの一歩ですのでこれを気に考えていただければと思います。