トムが説く、エンジニアがしてはならないこと
2010/3/2
2010年2月9日、日本オラクルは「データベース・アーキテクト・サミット - ask Tom Live -」を開催した。オラクル技術の中枢にいるトム・カイト氏が初来日し、エンジニアに技術解説から心構えなど多岐にわたりアドバイスした。
オラクル技術のカリスマ、トム・カイト
オラクル・コーポレーション サーバー・テクノロジー部門 シニア・テクニカル・アーキテクト 兼エバンジェリスト トム・カイト |
日本ではなじみが薄いかもしれないが、「オラクルのトム・カイト」といえば知る人ぞ知るカリスマ的な存在だ。「エバンジェリスト」と同時にオラクルで希少な「アーキテクト」の肩書きも併せ持つ。オラクル技術の頭脳である。1987年からOracle Databaseを使うようになり、1993年からオラクルに入社。同社「ask Tom」という有名なQ&Aサイトの立役者だ。多くのエンジニアが彼を慕っている。
イベントではカイト氏は「What are we still doing wrong?」と「Top 10 Things about Oracle Database 11g Release 2」の2つのテーマで講演し、最後に参加者からの質問に答えた。冒頭の講演はエンジニアにありがちなよくない習慣を指摘し、役に立つWebページを多数挙げながら、どうすべきかを諭した。本記事ではエンジニアへの教訓を凝縮した冒頭の講演を中心にレポートする。
いつもの失敗パターンから脱却しよう
カイト氏が取り上げたのはベストプラクティスならぬバッドプラクティス、ありがちな失敗パターンである。
●Underestimating Complexity
(複雑さの過小評価)
単純そうに見えて、実は背後にさまざまな問題が絡んでいる場合がある。カイト氏はContrastというブログの記事「THERE ARE NO SMALL CHANGES(小さな変更なんてない)」を挙げ、プログラム変更時の工数を甘く見積もるなと警告した。
例えば「この記入部分(テキストボックス)を『140文字まで』に変えてもらいたい」と文字数制限を持ちかけられたとしよう。それで「なんだ簡単。記入する部分のコードを見つけ、140文字で切っちゃえばいいんだろ?」と思うかもしれない。
とんでもない。
これまでに入力された140文字を超えるデータはどうする? インターフェイスはそのままでいいか? エラーメッセージは何と書くか? 急に仕様を変更してユーザーが納得するか? どのブラウザでも正常に動作する? どういう処理にする?
あらゆる問題が噴出する。これらを後手後手に対処すると問題がこじれてしまう。たとえ小さな変更でも甘く見ることなく、広範囲に目を配らせなければならない。簡単な修正と思えてもすぐにコードに手を出すのではなく、事前によく検討することだ。
●Not knowing how to ask for help
(助けてもらうための質問の仕方を知らない)
「Ask Tom」サイトに限らないが、Q&Aサイトでは質問が下手な人がいる。困っているのは分かるが、質問が的を射てないなら問答が迷走するだけだ。ネットに助けを求めるなら、自分の問題を素早く解決するために効果的な質問の仕方を会得するべきだろう。
ポイントはできるだけ状況や不具合を明確にすること。どういう状況でどんなエラーメッセージが出たのか、問題が起きる状況を特定する。すると読んだ人が何が問題か回答しやすい。そして判断に必要な情報も添付するのも不可欠だ。パフォーマンス上の不具合を質問するなら、サーバのスペックなども明示すべきだ。ただし無関係な情報は出す必要はない。よく考えて取捨選択しよう。
加えて自分の目的を示すのもいい。「○○が使えません」より「こういうことを実現したいのですが、○○が使えません」と質問する方が、「それなら××を使うといいですよ」と読んだ人が別の方策を提案してくれることもある。ただし、何でも聞くのも迷惑だ。カイト氏はいわゆる「教えて君」に言及したブログを例に挙げた。
The Old New Thing
Programming means that sometimes you have to snap two blocks together
http://blogs.msdn.com/oldnewthing/archive/2009/08/04/9856634.aspx
これは筆者の個人的な付け足しだが、アドバイスをもらったら、あとでお礼と成功したかどうか報告することをおすすめする。それは礼儀でもあるし、次に質問したときに回答を得られやすくなるからだ。書き逃げでは相手に悪い印象を与えかねない。
1/3 |
Index | |
トムが説く、エンジニアがしてはならないこと | |
Page 1 オラクル技術のカリスマ、トム・カイト ●複雑さの過小評価 ●助けてもらうための質問の仕方を知らない |
|
Page 2 ●無駄にコードを長くしてしまう ●うまくいっていると思わせがち |
|
Page 3 ●セキュリティは重要な問題 ●データベース管理者と開発者は違いを乗り越えよう ●ベストプラクティスとは |
Database Expert全記事インデックス |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか (2017/7/26)
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった (2017/7/24)
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと (2017/7/21)
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 (2017/7/20)
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
|
|