スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

DevLOVE関西 SQLアンチパターン・レトロスペクティブ関西・リターン 2013/05/11

DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン」に参加しました。
(会場提供いただいた楽天様、和田両氏、運営してくださるメンバーの皆様、ありがとうございました。)

今回は4H枠で深く掘り下げて、比較的長い時間グループダイアログがあり、かつ、大阪に和田卓人さん、和田省二さんを招いてということで、楽しみにしていました。
私がSQLアンチパターンの内容を聞くのは、先月のDevSumi2013 Award&Revival以来、2回目。

中村氏のオープニングの後、和田氏の「SQLアンチパターン - 開発者を待ち受ける25の落とし穴」レクチャー。
その後、グループダイアログで、それぞれの失敗談や、26個目の落とし穴を探しました。
最後に、質問タイム(レクチャーに近いものでしたが)で終了。

せっかくなので、和田卓人さん、和田省二さんに、SQLアンチパターン本にサインをいただきました。
また、懇親会に参加させていただき、少し質問をさせていただきました。

今回の一番大きな気づきとしては、SQLアンチパターンと直接関係ないのですが、結局データベース・リファクタリングをするには「テストを自動化」しないと効率が悪すぎるということです。
ジェイウォークにしても、おそらくは、DBの変更が与える影響が大きすぎてテストが面倒ということに、起因する問題だと思うのですが、それはテストを自動化することで、ある程度解消できるように思います。

実践という意味では、「データベース・リファクタリング」という本を教えてもらったので、これは一度読んでみたいと思いました。

グループダイアログは、参加されている方の意見を伺うことのできる貴重な機会でした。
外部キー回りの話は最も意見が分かれて盛り上がった内容でした。構築途中や、データを何か書き換えるときには外部キー邪魔だけど、実際保守する立場になったら方がよいとか。

26個目のアンチパターンは、名称含め、興味深いものが多数ありました。
私のいたチームで考えたのは、「フィア・オブ・ジ・レガシー」(恐怖の古い構造)というもの。
通常そのシステムが扱う以外のデータ(外部データや移行データ)を一緒の考えで取り扱うと、
えらい目にあったという体験談を、フィア・オブ・ジ・アンノウンにかこつけて名前を付けてみました。もう少し、「らしい」ものが出るかと思いましたが、グループでまとまった結果なので、それはそれでよいのではないかと思います。

@ryerさんの無意識にRDBを使っていないか?という問題意識も、一歩前行っているなぁという感覚。
和田省二さんのリソースとイベントの話も、若干難しい内容だったけれども、確かに本来ならばもう少し考えて設計してもよいところだと納得です。

RDBに関する技術伝承は、真剣に考えないと。
自分の今のプロジェクトも、割といいところまでいっていると思うけれど、過去データの扱いとか、データベース・リファクタリングについては、稚拙さを感じるので、そのためには、やはりどうにかメンバーを育てるしかないというのが、今のアクションプランだなぁ。

来週は、同じくDevLOVE関西のインセプションデッキの会に参加予定です。

コメント

非公開コメント
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。