読者です 読者をやめる 読者になる 読者になる

ビューティフルWebコード

美しいWebサイトのコーディングについて説明をしていきます。

URL設計(BaseURL/Baseパスを意識しよう)

URL Web

画面定義に合わせてURLの一覧を作成していく場合

MVCフレームワークを使った開発の場合、一般的に [BaseURL]/コントローラ名/アクション名 といったURL設計をしていきます。 ここで登場した BaseURL について意識すべきことをまとめます。

BaseURL

BaseURLとは BaseURL = URLスキーム+:// + FQDN + / + Baseパス

簡単にいうと、ローカルのapacheなどで開発する場合は、

を指します。website/があったりなかったり。

URLスキームとFQDNはよく意識されるのですが、Baseパスについて考慮漏れがあり、途端に対策に追われることがあります。 このBaseパスについて次に説明します。

Baseパスの問題

開発初期の段階で、Baseパスを意識すること、しないことで、開発に大きな影響を与えます。

クライアントの予算や、意識の違いなどもあるのですが、本番サーバー以外は準備してくれない、というのも珍しくありません。

開発環境や、テスト環境として、独立したサーバーを準備できる場合、Baseパスは無しになりますが別の開発環境と相乗りをする場合、このBaseパスを意識する必要がでてきます。

document_root直下に配置する想定だったのが、テスト環境やお客様の確認用の環境ではdocument_rootの下にたくさんのサイトのフォルダが区切られいて、そのフォルダに配置することを強制されることがあるのです。

html内のcssや、javascriptのURLとして "/"からはじまる絶対パスをハードコーディングしていた場合、途端に破綻します。

/assets/css/main.css

に配置されるはずのファイルが

/[ディレクトリ]/assets/css/main.css

となり、cssなどがNotFound状態になります。

Baseパスが環境によって変わる場合の対策

リソースのURLは相対パスにする。(非推奨)

URLの階層の変化に絶えられないのでオススメしません。

MVCフレームワークでは

/Controller名/Action名

というURL設計をするのが一般的ですが、Action名がindexの場合、indexは省略可能というルールを設けている場合があります。 ※CakePHP/.NET MVC

例として以下のURLを考えます。

/user/index

indexは省略可能なので、

  • /user/index
  • /user/
  • /user

この3つは全てUserControllerのIndexActionにルーティングされてしまいます。

/user/index 、/user/ については同じ階層と認識されますが

/user は一つ上の階層になっています。

つまり、リソースの位置を相対パスにすると、こういう階層の変化に耐えられないのです。 indexは利用しないという独自ルールを設けることもできますが、リリース後の保守などを他のベンダーがすることもあるので、独自ルールは避けたいところです。

フレームワークの機能を利用する

フレームワークによっては、css/javascript/imgなどのリソースは直接に記述せずに、viewに準備されているfunctionを利用して出力することで、BaseUrlが自動的に挿入することができます。

つまり、初期の段階で、これらを開発者に意識させるのです。きちんとリソースのパスががfunction経由で出力されてることをコードレビューなどで拾うのがいいのですが、わざわざコードレビューで拾い切るのも大変なので、全ビューをスキャンして正規表現などで、直接リソースのパスが記述されている箇所を捜索するプログラムを実装しておくのもアリかと思います。

Baseパスを意識しなかった場合の裏技解決案(非推奨)

サイトの相乗りについて、解決策が無いわけではありません。 ポートを分けてポートフォワードをする、localにhostsを書いてdomainを自作して、domainによってdocument_rootを切り替えるなど手はあります。

ただ、お客様の全ての環境にhosts書けますか?とか。hostsを書くなら開発環境、テスト環境にとどめておいて、ステージング、レビュー環境などでは小細工なしで表示させる必要が有ります。

担当しているクライアントのPCにhostsを置かせてもらって動作検証してもらっていたら、いきなり、 開発をまったく知らないクライアントの重役から電話がかかってきて、「俺のPCだと表示されない!大問題だ!」とか、火消しに時間を取られることもあります。

BaseURLは、プロジェクト後半で、後から差し込むと大騒ぎになりますが、初期の段階で一旦ルールを作成しておくと、プロジェクトがスムーズに進むと思います。

実装方針決め(雑談)

その他 Web

 

共通ルールの作成

  • URL設計
  • Cookieの使い方
  • セッションの使い方
  • QueryString(/user?foo=var)
  • HTTP ステータスコード
  • データ入力(Form)
  • 入力値チェック
  • 画面遷移時のデータ引き渡し方法
  • JavaScriptにどこまでやらせるか
  • MVCフレームワークについてModel,View,Controllerにやらせる仕事の範囲
  • エラーハンドリング
  • ログインの分離
  • ログ出力
  • ORM
  • キャッシュのルール(古いJSファイルがキャッシュされているため障害が起こるなど)
  • 他システム連携(外部APIを叩く)

 

※他にもあるかもしれないので、思い出したら追記します。

 

サイトを構築する際には、クライアントと打ち合わせを重ねていくことと思います。

サイトマップ、画面遷移図が出来上がり、ワイヤーフレームが出来上がり、

ヘッダーフッターなどの共通レイアウトが出来上がります。

デザインやHTMLコーディングはデザイナやそれを得意とする会社が担当することが多いとおもいます。

 

さて、そのデザインや画面遷移図を確認し、DB定義を起こし、実際にサーバーサイド(またはフロントサイド)の実装に入ることが多いのではないでしょうか。

 

本格的な実装に入る際に、決めておくべき事柄があります。

これを決めずにただ開発者を集めて、基本設計を渡して実装させると、

確かにコードの量は増え、たくさんコミットされ、順調に進んでいくように思います。

完成率80%まではあっというまでしょう。

ただし、その後が悲惨です。

ルールも何もない実装は、無駄なコードを生み、バグだらけになります。

終盤にはバグチケットが増え続け、直しても直しても新しいバグが出てきます。

原因がわからないバグに悩まされ、なぜこんなコードになってるんだ、と気が狂いそうになります。

 

修正しようにもどこから手をつけていいかわからず、影響範囲もわからず、

「作り直したほうが早いんじゃないのか」

という状態になります。

 

誰しも経験があるのではないでしょうか。

 

正直、経験の浅いエンジニアが10人集まるより、質のいいエンジニア2人の方が、開発効率が良かったりします。

 

それは、なぜなのか。

質のいいエンジニアはタイピング速度がめちゃくちゃ速いからです。

冗談です。

 

無駄なコードがないのです。

 

きちんとルールを決めるのです。

 

ルールを決めるとコーディングルールを真っ先に連想される方々が多いですが、

コーディングルール(たとえばメンバ変数はアンダーバーで始める)を決めても綺麗な実装になるとは限りません。

もちろんコーディングルールを決めることも大事です(ないよりはいいです)

でも、クラスやメソッドをきちんと設計し、役割を明確化することの方が大事です。

I/Fさえ合っていればなんとでもなります。要するに役割に閉じていて欲しい。

たとえば、DataAccess層なのに、入力値判定をしてエラー画面にリダイレクトさせたり、Cookieから値を読み込んだり、中途半端に共通化しようとして引数にフラグを渡したり、実装した本人も処理を追わないと何をしてるのかわからないコードは害悪です。

経験値が低いエンジニアでも、実装方針が決まっていて、それに従ったコーディングをしていただけると、バグがあってもその画面、そのクラス、そのメソッドに閉じるのでプロジェクトへの被害は少なく、きちんと経験値を積んでいただけるようになります。

 

次回からは、共通ルールについて詳細を書いていこうと思います。

Webサイトの作り方(開発者向け)をまとめていきます

その他 Web

このブログの目的

はじめまして。human-natureと申します。

10年くらいIT系の開発の仕事をしています。

最近はWebサイトの開発、アプリの開発が多いですが、

今の現場はWebがメインになっております。

 

今まで培ったノウハウなどを公開し、

開発、保守といった業務が円滑になるような知恵を

ブログをご覧の開発者のみなさまと共有していきたいと思っております。

 

未経験者の人に開発を教えるということが多かれ少なかれあるのですが、

巷で売られているプログラミング系の技術書は、

道具(言語やフレームワーク)の使い方がメインになっており、

どう使えば幸せになるのかが抜けているのです。

 

例えば、自動車教習所では、車の運転の仕方や、交通ルールを学びますが、

車を使って、どういう幸せな生活を送るのか、という使い方までは教えてくれません。

 

プログラミング入門書を読むと、上の例だと、車の運転の仕方のみについての言及のみで、実装ルールや、綺麗なコーディング、どういうクラス設計、構造設計をするかまでは言及されません。

 

プログラミング入門書を勉強したところで、実際に戦力としてプロジェクト全体を進めるノウハウとしてはほんの10%くらいなのではないのかなと思います。

 

大半は、経験に依存する気がします。センスもあると思いますが、経験がモノを言います。

 

その経験を少しでもお裾分けして、優秀なエンジニアを増やしていきたいと思います。

また、いろいろな意見が頂戴し、自身のスキルアップにもつなげていけたらと思います。

 

真面目すぎる。。。

 

自己紹介

名前:human-nature

生年月日:1981年生まれ

好きなもの:プリン、デカビタC、天ぷらそば、魚料理、綺麗なコード

嫌いなもの:デスマーチ

学歴:某国立大学工学部情報工学科(学部)卒