データベース・アーキテクト・サミットレポート

トムが説く、エンジニアがしてはならないこと

●We write/generate Way too much code
（無駄にコードを長くしてしまう）

　当然のことだがプログラマーはコードを書くのが仕事であり、それで報酬を得ている。だが山ほどコードを書けばいいというものではない。カイト氏は「簡潔で短いコードを書くプログラマほど高く評価され、報酬を得るべきです。なぜならコードが短ければ、バグ（の危険性）が減るからです」と述べた。

　カイト氏は冗長なコードを例に、「もっといい方法があります」とより簡潔なコードに絞り込む方法を示した。サーバのスペックが良ければ無駄な処理が多くてもパフォーマンスに影響がないかもしれないが、ソフトウェアのライセンス料はCPUの数が増えると上がるようになっている。簡潔なコードを書くことができるプログラマはライセンス料を節約することにもつながる。

　「できるプログラマになりたかったら、クエリー操作と同時にアルゴリズムを考えられるようにならなくてはなりません」とカイト氏。与えられたミッション、つまり要件をいかに少ない処理で済ませられるか、そこに頭を使おう。

●We pretend Everything will be alright
（うまくいっていると思わせがち）

　ところで最近カイト氏は気苦労が減ったそうだ。というのも、AskTomの運営を委託することができたからだ。データベースを運営する側としてはトラブルに備えてバックアップには特に気を遣わなくてはならない。カイト氏は2009年10月に携帯向けクラウドサービスで起きたユーザーデータ消失障害を挙げた。深刻な障害の例だ。

　ここまでひどいのはレアだとしても「トラブルは起きるものだ」と、対処を怠らないようにと説いた。その上でエラーに対処するためのノウハウが掲載されているWebページをいくつか例示した。

　以下のWebページではエラーハンドリングのインフラをアプリケーション内にきちんと持つことを提唱している。

　次は例外についてまとめたもの。例外はコードの最上位でキャッチするといいそうだ。またキャッチした場合に、ユーザーや開発者などにどのように伝えるか、待ち時間はどのくらいに設定するかなどもを考慮する必要がある。

　最後にアサーションについて。アサーションはある条件をチェックし、条件が偽になったときに例外を発生させる構文だ。下記のブログでは本番コードにアサーションを入れる是非について書かれている。

　「ここから考えてみよう」とカイト氏は問題提起した。例えば入力データが想定範囲を超えているなど、アプリケーションに致命的な事態が起きるとデータベースは内部エラー（ORA-600）を発し、処理を中断するようになっている。しかし面倒がってそこで処理をExitし、何も起きていないように見せてしまうプログラマもいるという。これはよくない。データベースが内部エラーを出したということは先に進めてはいけない状況になったということだ。それならアプリケーションも同じような対処をするべきだとカイト氏は指摘した。

　いずれにしても、エラーや障害が起きる前からそれが起きることを想定し、コードに何らかの対策を施しておくことが大事だ。

2/3

Index
トムが説く、エンジニアがしてはならないこと
	Page 1 オラクル技術のカリスマ、トム・カイト ●複雑さの過小評価 ●助けてもらうための質問の仕方を知らない
	Page 2 ●無駄にコードを長くしてしまう ●うまくいっていると思わせがち
	Page 3 ●セキュリティは重要な問題 ●データベース管理者と開発者は違いを乗り越えよう ●ベストプラクティスとは

Database Expert全記事インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）