34
43

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

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

Last updated at Posted at 2017-12-23

はじめに

はじめまして。Livesense - 学 Advent Calendar 2017の24日目を担当する@gccjです。
IESHILIESHIL 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エンジニアは知った方がいいこと

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

  • ウェブブラウザ間基準の違いを気を付けましょう!自分のサイトは多ウェブブラウザの対応はできているのかを確認しましょう。最低限テスト必要のウェブブラウザ:

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

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

安全

パフォーマンス

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

さいごに

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

34
43
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
34
43

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?