新人Webエンジニアは知った方がいいこと

はじめに

はじめまして。Livesense - 学 Advent Calendar 2017の24日目を担当する@gccjです。
IESHILとIESHIL CONNECTの開発をしている外国人17新卒です。


Webの開発を始めたきっかけは大学院での研究プロジェクトでした。
その時、初めてRailsを知り、Web開発に関する知識全然持っていない私は、ただネット上のあるガイドに従って操作したら、意味わからなく、人生初のWebアプリ（簡単なメモ帳アプリ）が出来上がりました！！！


Railsはすごい！自分はすごい！！（謎の自己満足）


うん！ちょっと待って、
このRubyとは何？
MVCは何？
DHHは何の略（大変失礼いたしました！すみません、本当にすみません！許してください！）？
などなど
知れば知るほど質問が出てくる！


その後、RubyとRailsの勉強はもちろん、Webエンジニアとして身につける必要なスキル・技術とは何にかへの探求及びそれらスキル・技術の勉強も日々頑張り続けています。
もちろん今でも知らないことばっかりですが、一つのことは確実にわかりました！


それは：
Railsは確かにすごい。。。
Rubyも凄い。。。
DHHは神。。。
ですが！
自分は全然すごくないことです！

今日書くのはその謎の自己満足から抜け出した後、ある日にStackExchangeで見ました「What technical details should a programmer of a web application consider before making the site public?」（Web開発者はサイトを公開する前に知っておいたほうがいいスキル・技術）です。
中の答えは自分にとって非常に参考になりましたため、新卒Webエンジニアの立場から、整理して、これからWebエンジニアになる新人プログラマ仲間へ共有いたします。

新人Webエンジニアは知った方がいいこと

インタフェースとユーザー体験

• ウェブブラウザ間基準の違いを気を付けましょう！自分のサイトは多ウェブブラウザの対応はできているのかを確認しましょう。最低限テスト必要のウェブブラウザ：
  • 最新のGeckoエンジン（Firefox）
  • Webkitエンジン（Safari, Chrome及びモバイル端末上のウェブブラウザ）
  • Internet Explorer(テストするためにマイクロソフト社のApplication Compatibility VPC Imagesを使ます)
  • Opera

*browsershotsというツールを利用して、自分のサイトは違うシステムの違うウェブブラウザでの表示状況を確認できます。

• 主流ウェブブラウザ以外を利用しているサイトユーザーのことも配慮する。例えば：ガラケー、スクリーンリーダーや検索エンジンなど。
• Staging環境を整備しよう。新機能をリリースする際に、ユーザーへの悪い影響を最小限にするために、テストやステージング環境の整備、buildの自動化、バージョン管理などはとても大事です。
• 分かりづらいのエラー情報をユーザーに表示させない。
• クローラに収集され、スパムメールが大量殺到する恐れがあるため、ユーザーのメールアドレスをプレーンテキスト形で表示しない。
• 口コミなどのユーザーコンテンツにあるリンクへrel="nofollow"を追加すること。（nofollowについてはこちら：https://support.google.com/webmasters/answer/96569?hl=ja）。
• 悪意利用を防ぐために利用制限をかける。例えば：人の操作であることを確認するために、多くのサイトで見られるCAPTCHA。興味のある方はこちらもぜひ合わせて読んでください。
• プログレッシブエンハンスメント。ウェブ設計の概念である。以下はウィキからの引用です。
  • 基本となるコンテンツはすべてのウェブブラウザからアクセスできる。
  • 基本となる機能性はすべてのウェブブラウザからアクセスできる。
  • 疎なセマンティクスですべてのコンテンツがマークアップされる。
  • 拡張レイアウトは外部リンクされたCSSで提供する。
  • 拡張された振る舞いは外部リンクされた控えめなJavaScriptで提供する。
  • エンドユーザーのウェブブラウザーの好みを尊重する。
• ユーザーの重複提出を防ぐため、Post成功したら、リダイレクトする。
• Webアクセシビリティ。（ウェブアクセシビリティ方針策定ガイドライン）。

安全

• ネット上ウェブサイト安全に関する情報は一杯ありますが、OWASP development guideにはウェブサイトの安全に関することほぼ全て書かれています。（OWASPとはOpen Web Application Security Projectの略で、Webアプリケーションのセキュリティに関するオープンソースのコミュニティです。OWASP development guide日本語バージョンはこちら：https://www.lac.co.jp/lacwatch/people/20160324_000328.html ）。
• SQLインジェクションとその対策を理解する。
• どんな時でもユーザーのインプットを信用しない（cookies と hidden form fieldも同じです。これらもユーザーインプットです！ ）。
• レインボー攻撃を防ぐために、saltを使ってパスワードをHash化する。（参考資料：http://www.atmarkit.co.jp/ait/articles/1110/06/news154_2.html）。
• 自分は認証システムを開発しない（超すごい方は無視してください！）。
• クレジットカード情報処理の仕組みを理解する。
• SSL/HTTPSを利用する。
• セッションハイジャックのことを知る。
• クロスサイトスクリプティング（XSS）のことを知る。
• クロスサイトリクエストフォージェリ（XSRF）のことを知る。
• クリックジャッキング(Clickjacking)のことを知る。
• 常にシステムと利用しているソフトを最新にする（この間HighSierraのことを忘れてくださいwww）。
• データベースconnectionは安全であることを確認する。
• 常に最新の攻撃技術と自分のシステムの貧弱性を把握する。
• The Google Browser Security Handbookを読む。
• The Web Application Hacker's Handbook見たいの本を読む。
• 最小権限の原則を考えます。サーバーをnon-root-userにしてみる。
• タブナビング(Tabnabbing)対策としてユーザーコンテンツ内のリンクにrel="noopener noreferrer"とtarget="_blank"を追加する。(参考資料：https://blog.jxck.io/entries/2016-06-12/noopener.html)。

パフォーマンス

• 仕様に応じて、キャッシュ機能を実装する。HTML cachingとHTML5 Manifestを合理的に利用する。
• 画像やSVGなどの最適化。
• gzip/deflateを利用して、ページを圧縮する。
• ウェブブラウザの接続数を減らすために、複数のCSSファイルやJavascriptファイルを一つにコンバインする。重複利用されている資源をgzipで圧縮する。
• Yahoo Exceptional Performanceに載せている資料を勉強する。
• Google page speedなどのツールを利用し、パフォーマンスをテストする。（こちらのサイトもおすすめです。https://www.webpagetest.org/）
• アイコンのような小さいの画像の場合SVGスプライトを利用する。（参考資料：http://program-designer.xyz/svg-sprite/） アクセス数の多いサイトにはページ内容を分割し、分割されたコンテンツを別のドメインに置くこと。（例えば画像サーバー）
• 静的コンテンツ(画像、CSS、JavaScript及びcookiesにアクセスする必要のないウェブコンテンツ)をcookiesを使わない独立のドメインの下におくべき。理由は同一のドメインとそのサブドメインのcookiesはこれらのドメイン・サブドメインにアクセスするたびに送信してしまうから。CDN（Content Delivery Network）を使うのもお勧めです。
• ウェブページのHTTPリクエスト数を最小化にする。
• テンプレートエンジンを使う。
• サイトのルートディレクトリにfavicon.icoを置くこと（例：/favicon.ico）。HTMLの中にfavicon.icoに関する記述があるかどうかと関係なく、ウェブブラウザはfavicon.icoをリクエストする。もしfavicon.icoは存在しなかったら、大量の404エラーが発生する。サーバーのバンドワイズを消耗してしまう。

SEO

• 検索エンジンは好きなURLにする。例えば：example.com/index.php?page=45のかわりにexample.com/pages/45-article-titleを使う。
• 動的なコンテンツページで#を利用する場合、#のかわりに#!を使う。サーバー側も$_REQUEST["_escaped_fragment_"]を処理する必要がある。その理由は、Googleのbotは自動的に#!を$_REQUEST["_escaped_fragment_"]に変換している為です。いわゆる./#!page=1の場合Googleのbotは./#!page=1を./?_escaped_fragments_=page=1に変換する。（備考：通常URL#以後の部分はサーバーに送信されないです。AJAXの内容もGoogleに収集されるために、#!を使う必要がある。Googleは#!を_escaped_fragment_に変換してからサーバーにリクエストする。）またFirefoxとChromiumを利用しているユーザーに対し、history.pushState({"foo":"bar"}, "About", "./?page=1");コマンドを活用できます。このコマンドを使うことでページをリロードせずにURLを変更出来ますから、#のかわりに?を使っても現在の動的なコンテンツページを維持できます。（参考資料：history.pushStateについてはこちら：https://developer.mozilla.org/ja/docs/Web/Guide/DOM/Manipulating_the_browser_history）
• click hereのようなリンクを使わない。
• XML sitemapを生成し、サイトのルートディレクトリに置くこと。
• 同一のページへ大量のリンクが貼られている場合<link rel="canonical" ... />を利用する。
• Google Webmaster Toolsを使う。
• Google Analytics を使う。
• robots.txtとWebクローラーの仕組みを理解する。(参考資料：https://support.google.com/webmasters/answer/1061943?hl=ja)
• リダイレクト（301 Moved Permanentlyを利用する）。例えばwww.example.comをexample.comにリダイレクトする場合、301 Moved Permanentlyを使うことで、Googleのrankは違うドメインで変ってしまうことを防ぎます。

技術

• HTTPのことを知る。GET、POST、sessions、cookies、statelessなどなど
• W3C specificationsに従ってXHTML/HTMLとCSSを書く。
• ウェブブラウザはJavaScriptを処理する仕組みを理解する。
• ウェブブラウザはCSSやJavaScriptなどのリソースをロードする仕組みを理解する。
• JavaScript sandboxの仕組みを理解する。特にiframesを使いたい場合。
• JavaScriptは常に有効されているわけではないこと。
• 301と302の違いを知る。
• 本番環境を支える技術（OS、Apache/Nginx、ファイアウォールなど）を勉強する。
• リセット・スタイルシートを試してみる。
• JavaScriptフレームワークを使う。

Bug fixing

• コードを書く時間は20%、メンテナンスに費した時間は80%なので、コードを書く前に解決したい問題をしっかり考えましょう！
• より良いエラーハンドリングを設計しましょう。
• ユーザーが簡単にフィードバックできる窓口を設置する。
• 他人でも継続開発・メンテナンスできるために、ドキュメントをきちんと用意しましょう。
• バックアップを取る。
• バージョン管理システムを活用する。
• 受け入れテストを忘れないで。
• 問題が発生した場合、速やかに原因を特定できるように、十分なログを取りましょう。
• ログを取る際に、処理済みの例外と未処理の例外を両方取ること。

さいごに

最後まで読んでくださった方へ感謝します。
ありがとうございます！