皆さん、こんにちは
この記事では、WEBサイトの運用/保守をしていくにあたって、どこに原因があるのかという問題発生個所の特定手順についてフォーカスして記載していきます。
ターゲットとしては、「自社/他者のサイトの運用保守チームに入って、依頼者からの不具合報告の対応や、新機能の追加/仕様変更などの対応をする業務に入ったけど、webのことよくわからんor未経験で何が何やら」って人向けです。
いたずらに問題個所を調べる前に。
不具合対応や新機能の実装に当たって、最も重要なのは「どこで問題が生じているか/何を変更すればよいか」という点です。
検索結果がおかしいから、「searchHogeHoge」というクラスを調べてみるか～～～
というようにあてずっぽうで調べてはいけません。
そこそこモダンなフレームワーク(Laravelとか、fuelとか)であれば、おおまかな処理のフローは共通しており、それに乗っ取っていけば自然と問題個所の特定ができるようになります。
まずはwebの基本から見ていきましょう。
そもそも、WEBのURLには何の意味があるのでしょうか。
1000億年前の原始の世界において、
http://website.com/articles/aaaabbbbbb.html
というURLは「website.com」というサイトの「articles」というフォルダの「aaaabbbbbb.html」というファイルを取得(して表示)する。
という意味でした。
しかしながら、これでは毎回毎回同じ画面しか表示することができません。
ウェブの世界が発展していくにつれ、「ユーザーの操作(例えば、検索ボックスに入力した内容)に応じてサイトの表示内容を変えたい」ということを考える人が出てきました。
色々な手段が講じられてきましたが、現在において多くのフレームワークで用いられているのは、
URLに対応したメソッドを呼び出したうえで、そのメソッドの戻り値をブラウザ側に返す(そして、表示する)というものでした。
この「URLに対応した」という点がミソです。まずはこのことを覚えてください。
WEBサイトの設計の基本思想
さて、話を進める前に、一度立ち止まってWEBサイトにおける標準的な設計の基本的なモデルを確認しておきましょう。
それがMVCモデルと言われているものです(ほかにもいろいろな派生がありますが、基本はこれです)。
これは、Model, View, Controlerの3つの頭文字をとったものです。
それぞれの役割を見ていきましょう。
Model(モデル)
モデルは具体的な処理を実施するものです。もしあなたが、複雑な計算式や条件分岐に関する実装を行うのであれば、多くの場合この領域に対してコードを追加することになるでしょう。
「検索結果を受け取って、DBの中身を検索した後、ユーザーの好みに応じた順序に並べ替えたい？」
「ユーザーの最近の閲覧履歴をもとに、おススメの動画を提案したい？」
「ユーザーの利用状況をもとに利用料金を計算したい？」
これらはすべてモデルで行うことです。
View(ビュー)
ビューの役割は、モデルで計算した結果をユーザーに分かりやすく(=見栄えよく)表示することです。
例えば、「2000円, 3000円, 合計5000円」とだけ書くよりも
2000
+3000
=5000
と書いた方が見やすいですよね。このように計算結果や、処理の結果をhtmlの形に加工してユーザーに分かりやすく見せる層がViewになります。
多くのフレームワークでは、モデルの処理結果を簡単にビュー側に組み込みやすいような機能が用意されていますので、具体的な利用方法はご自身が利用されているフレームワークのドキュメントを見てみてください。
Controler(コントローラー)
さて、最後はコントローラーです。
コントローラーの役割は、Viewから受け取った情報を適切なModelに対して割り当てることです。
これは少しわかりにくいと思います。具体的に説明します。
例えば、ユーザーが「うどん」という文字列で検索したとします。
この検索文字列は、どこから飛んできたかというと、当然「ブラウザ側」から飛んできたことになります。
つまり「ユーザーからのクエリはViewから飛んでくる」ということです。
この時、重要な考え方になってくるのですが、「View側は誰にこの仕事を頼めばいいか詳しいことはよくわかっていない」ということです。
例えば、あなたがコンビニの店員だとして宅配便の配送をお客様に依頼されたとしましょう。
その時あなたは「トラックの運転手に電話をかけて、取りに来てもらって、配送ルートを考えて、高速道路の料金を精算して・・・」なんてことをしないですよね。「毎日コンビニにやってくる担当の人に荷物を渡して終わり」のはずです。
Viewの仕事とは、ユーザーに分かりやすい画面を提供することであって、その仕事に専念すべきなのです。
つまり、Viewは後続の処理について具体的に知っている必要は全くなく、「誰に情報を渡せばいいか」ということさえわかって入ればいいということになります。
この「渡す相手」こそがControlerなのです。
流れを簡単におさらいしましょう。
まず、ユーザーはViewを見ます。それをもとに、例えば検索条件を入力したり、自分の会員情報を見ようとしたりするでしょう。
そうしたら、そのクエリはまずControlerに渡されます。クエリを受け取ったControlerは必要なメソッド(=モデル)を呼び出したうえで、その結果をViewに対して渡す
ということです。
結局どうやるの？
少し話がそれてしまいましたね。本題に戻しましょう。
どうやって問題の発生個所を見つけるかということですが、それはURLをベースに見つけるのが一番簡単な方法です。
先ほど「URLに対応したメソッドを呼び出したうえで、そのメソッドの戻り値をブラウザ側に返す」ということを書いたかと思います。
この「対応したメソッド」とは何でしょうか。それはズバリ「MVCモデルにおけるコントローラー」なのです。
例えば、
https://sampleWebhogehoge.com/articles/index
というURLであれば、コントローラー層のarticlesクラスのindexメソッドというように、対応したメソッドが呼び出されるのです。
ですので、皆さんがまず覚えなければならないことは、そのシステムにおいて「コントローラー層に対応するディレクトリはどこか」ということです。
これをまず覚えておけば、そのURLのページを開いたときに呼び出されているメソッドがわかるはずです。
(そのサイトの運用保守をやってる先輩とかに「コントローラー層のディレクトリ構成教えてください」とか言えば教えてくれると思います。)