エンジニアがいつも繰り返す失敗とは? 前編 
隠れた「複雑さ」を見落とすな

米オラクルのエンジニアにしてQ&Aサイト「Ask Tom」を主宰するトム・カイトによる、技術者がスキルを向上するためのヒントをお送りしよう。(編集部)
《エンジニアがいつも繰り返す失敗とは?》シリーズをお見逃しなく!
■隠れた「複雑さ」を見落とすな
 私がよく見かける失敗、それは物事に隠れた「複雑さ」を見落としてしまうことである。例として、ユーザーがメッセージ入力できる簡単な HTMLフォームを備えたWebアプリケーションが運用されていたとしよう。そして要求元から「メッセージ入力の最大文字数を140字に制限してほしい」 と依頼が来た。

 一見すると、これはとても簡単な要求だ。例えば、短いJavaScriptコードをHTMLフォームに追加して、140文字以上は受け付けないようにすれば、ものの30秒で実装できる。しかし実は、これは既存のシステムに対して多大な影響を及ぼす変更だ。

 まず、既存のデータはどうなるか?データベースの中には140文字を超えるメッセージがたくさん格納されている。それをユーザーが編集すると きに、140文字を超える部分を勝手に切り捨てていいだろうか。それともエラーメッセージを出すべきか?それはダイアログにすべきか、それともウィンドウ 下のステータス表示で出すべきか?もしユーザーが長い文字列をカット&ペーストしたときに、うるさいエラー音が繰り返し鳴り響いたりしないだろうか?

 こうした問題は、ほかにもたくさん現れる。JavaScriptの動作をオフにしたブラウザでは、エラーチェックが働かない。中には、 HTMLフォームを介さずに長いメッセージを直接サーバーのAPIに送信するユーザーもいるかもしれない。そもそも、サポート対象のブラウザは何だろう か?なぜ「140文字」なのだろうか?

 ――このように、最初は30秒で実装できると思えた要求でも、その背後には思いがけずに巨大な複雑さが潜んでいる。「見かけと同じくらい単純な問題など存在しない」という点を忘れないでほしい。

■「クルマが動きません」では分からない
 もうひとつのよくある失敗は、トラブルの解決方法についての質問の仕方を間違えること。私が運営するサイト「Ask Tom」 には数多くの質問が寄せられるが、例えば「私のOracleデータベースのSGAを2GB以上に設定できません」といった聞き方をよくされる。こうした質 問のことを私は「クルマが動きません」と呼んでいる。つまり、動かないことだけを伝えて、それが「なぜ動かないか」をまったく書いていないのだ。

 クルマのスピードメーターや計器には何が表示されているか。クルマからはどんな音がしているか。ガソリンは満タンか。どの型式のクルマか。どこの道路を運転しているか。そうした事細かな条件について教えてくれないと、質問に答えることができない。

 トラブルの解決方法についてアドバイスを得るには、ちょうどあなたの母親にデータベースの仕組みを教えるような調子でゆっくりわかりやすく質問相手に伝える必要がある。相手はあなたの母親と同じで、あなたしか知らない情報について何も知識を持っていないのである。

TECH_101106-01.jpg

■コードの書きすぎ
 次の失敗は「コードの書きすぎ」。簡単に言えば、コードを書けば書くほどバグも増えるということだ。例えばあるPL/SQLコードでは、新し いIDを生成して、それがテーブル上にすでに存在するかチェックしていた。もしすでに存在していれば、次のIDを生成してそれを試す。それを128回まで 繰り返すというムダの多い実装だ。

 また、他にはこんな質問もあった。「Javaプログラムで-12を12に変換するにはどうすればいいでしょう? 簡単に実装する方法がなく、これを実装するためのコードを一日書いています」

 ――これを見た他のユーザーは冗談で「24回繰り返し処理するループを書き、ループの中で-12に1ずつ加算していくコード」を勧めていた。もちろん、正解は「-1を掛ける」である。

TECH_101106-02.jpg

 正しいやり方さえ知っていれば、100万行のコードを1行で書くことも可能なのである。

 そしてよいSQLエンジニアであるには、「データの集合演算」と「アルゴリズム」の両方の観点からデータベースクエリを考えられる必要がある。正しい結果を得るための集合演算だけを知っていても、処理は非効率になる。

  一方で、データを望みの結果に変換できるアルゴリズムを知っていて、それをコーディングだけでデータベースに無理強いしても、良い結果は得られない。集合 演算とアルゴリズムの両方を同時に考慮すれば、オプティマイザが適切なアルゴリズムを選択できるようなクエリを組み立てることができる。それこそが 「SQLのパワー」を武器にできる唯一の方法だ。



前の記事 <<  最初の記事へ  >> 次の記事

《エンジニアがいつも繰り返す失敗とは?》シリーズをお見逃しなく!