Web開発者が犯す10の最も一般的な間違い：開発者のためのチュートリアル

公開: 2022-03-11

ワールドワイドウェブという用語が1990年に造られて以来、Webアプリケーションの開発は、静的なHTMLページの提供から、完全に動的で複雑なビジネスアプリケーションへと進化してきました。

今日、私たちは何千ものデジタルおよび印刷されたリソースを持っており、あらゆる種類の異なるWebアプリケーションの開発に関する段階的な指示を提供しています。 開発環境は、初期の開発者が定期的に戦った多くの間違いを見つけて修正するのに十分な「スマート」です。 単純な静的HTMLページを高度にインタラクティブなアプリケーションに簡単に変換するさまざまな開発プラットフォームもあります。

これらの開発パターン、プラクティス、およびプラットフォームはすべて共通の基盤を共有しており、Webアプリケーションの性質そのものが原因で同様のWeb開発の問題が発生する傾向があります。

これらのWeb開発のヒントの目的は、Web開発プロセスのさまざまな段階でよくある間違いのいくつかを明らかにし、より優れた開発者になるための手助けをすることです。 検証、セキュリティ、スケーラビリティ、SEOなど、事実上すべてのWeb開発者に共通するいくつかの一般的なトピックに触れました。 もちろん、このガイドで説明した特定の例に縛られることはありません。これらの例は、発生する可能性のある潜在的な問題のアイデアを提供するためにのみリストされているためです。

よくある間違いその1：不完全な入力検証

クライアント側とサーバー側でユーザー入力を検証することは、単に行う必要があります！ 私たちは皆、 「ユーザー入力を信用しない」という賢明なアドバイスを知っていますが、それにもかかわらず、検証に起因する間違いは非常に頻繁に発生します。

この間違いの最も一般的な結果の1つは、毎年OWASPトップ10に入るSQLインジェクションです。

ほとんどのフロントエンド開発フレームワークは、非常に簡単に使用できる、すぐに使用できる検証ルールを提供することを忘れないでください。 さらに、ほとんどの主要なバックエンド開発プラットフォームは、単純な注釈を使用して、送信されたデータが期待されるルールに準拠していることを確認します。 検証の実装には時間がかかる場合がありますが、これは標準のコーディングプラクティスの一部であり、決して脇に置いておく必要はありません。

よくある間違いその2：適切な承認なしの認証

先に進む前に、これら2つの用語が一致していることを確認しましょう。 10の最も一般的なWebセキュリティの脆弱性で述べられているように：

認証：セキュリティ資格情報（パスワード、セキュリティの質問への回答、指紋スキャンなど）を正しく提供しているため、特定のユーザーである（または少なくともそのように見える）ことを確認します。

承認：特定のユーザーが特定のリソースにアクセスできること、または特定のアクションを実行するための権限が付与されていることを確認します。

別の言い方をすれば、認証はエンティティが誰であるかを知っているのに対し、承認は特定のエンティティが何ができるかを知っているということです。

この問題を例を挙げて説明します。

ブラウザは、現在ログに記録されているユーザー情報を次のようなオブジェクトに保持していると考えてください。

 { username:'elvis', role:'singer', token:'123456789' }

パスワードを変更すると、アプリケーションはPOSTを実行します。

 POST /changepassword/:username/:newpassword

/changepasswordメソッドでは、ユーザーがログインしていて、トークンの有効期限が切れていないことを確認します。 次に、 :usernameパラメーターに基づいてユーザープロファイルを検索し、ユーザーのパスワードを変更します。

したがって、ユーザーが正しくログインしていることを確認してから、ユーザーの要求を実行してパスワードを変更しました。 プロセスは大丈夫だと思いますよね？ 残念ながら、答えはノーです！

この時点で、アクションを実行するユーザーとパスワードが変更されたユーザーが同じであることを確認することが重要です。 ブラウザに保存されている情報は改ざんされる可能性があり、上級ユーザーであれば、組み込みのブラウザツール以外を使用せずに、ユーザー名username:'elvis'をusername:'Administrator'に簡単に更新できます。

したがって、この場合、ユーザーがセキュリティ資格情報を提供していることを確認するために、 Authenticationを処理しました。 /changepasswordメソッドはAuthenticatedされたユーザーのみが実行できるという検証を追加することもできます。 ただし、これでもユーザーを悪意のある試みから保護するには十分ではありません。

/changepasswordメソッド内で実際のリクエスターとリクエストの内容を確認し、リクエストの適切なAuthorizationを実装して、ユーザーが自分のデータのみを変更できるようにする必要があります。

AuthenticationとAuthorizationは同じコインの両面です。 それらを別々に扱わないでください。

よくある間違いその3：スケーリングの準備ができていない

今日の高速開発、スタートアップアクセラレーター、優れたアイデアの世界的なリーチの世界では、MVP（最小実行可能製品）をできるだけ早く市場に出すことが多くの企業の共通の目標です。

ただし、この絶え間ない時間のプレッシャーにより、優れたWeb開発チームでさえ特定の問題を見落とすことがよくあります。 スケーリングは、多くの場合、チームが当然と考えていることの1つです。 MVPのコンセプトは素晴らしいですが、それをやりすぎると、深刻な問題が発生します。 残念ながら、スケーラブルなデータベースとWebサーバーを選択し、独立したスケーラブルなサーバー上のすべてのアプリケーション層を分離するだけでは不十分です。 後でアプリケーションの重要な部分を書き直さないようにする場合は、考慮する必要のある詳細がたくさんあります。これは、Web開発の大きな問題になります。

たとえば、アップロードしたユーザーのプロフィール写真をWebサーバーに直接保存することを選択したとします。 これは完全に有効なソリューションです。ファイルはアプリケーションにすばやくアクセスでき、ファイル処理方法はすべての開発プラットフォームで利用でき、これらのイメージを静的コンテンツとして提供することもできます。これは、アプリケーションの負荷を最小限に抑えることを意味します。

しかし、アプリケーションが大きくなり、ロードバランサーの背後で2つ以上のWebサーバーを使用する必要がある場合はどうなりますか？ データベースストレージ、セッション状態サーバー、およびWebサーバーを適切にスケーリングしたとしても、プロファイルイメージのような単純なものが原因で、アプリケーションのスケーラビリティが失敗します。 したがって、ある種のファイル同期サービス（遅延が発生し、一時的な404エラーが発生します）または別の回避策を実装して、ファイルがWebサーバー全体に確実に分散されるようにする必要があります。

そもそも問題を回避するために必要なことは、共有ファイルの保存場所、データベース、またはその他のリモートストレージソリューションを使用することだけでした。 すべてを実装するには、おそらく数時間の追加作業が必要でしたが、問題を起こすだけの価値はありました。

よくある間違いその4：SEOが間違っているか欠落している

WebサイトでのSEOのベストプラクティスが正しくない、または欠落している根本的な原因は、誤った情報に基づく「SEOスペシャリスト」です。 多くのWeb開発者は、SEOについて十分に知っており、特に複雑ではないと信じていますが、それは真実ではありません。 SEOの習得には、Google、Bing、YahooがWebにインデックスを付ける方法に関するベストプラクティスと絶えず変化するルールの調査にかなりの時間を費やす必要があります。 あなたが絶えず実験し、正確な追跡と分析をしていない限り、あなたはSEOの専門家ではなく、SEOの専門家であると主張するべきではありません。

さらに、SEOは、最後に行われるアクティビティとして延期されることがよくあります。 これには、Web開発の問題が高額になります。 SEOは、優れたコンテンツ、タグ、キーワード、メタデータ、画像の代替タグ、サイトマップなどの設定に関連するだけでなく、重複するコンテンツの排除、クロール可能なサイトアーキテクチャ、効率的な読み込み時間、インテリジェントなバックリンクなども含まれます。

スケーラビリティと同様に、Webアプリケーションの構築を開始した瞬間からSEOについて考える必要があります。そうしないと、SEO実装プロジェクトを完了すると、システム全体を書き直すことになります。

よくある間違いその5：リクエストハンドラでの時間またはプロセッサの消費アクション

この間違いの最も良い例の1つは、ユーザーの操作に基づいて電子メールを送信することです。 開発者は、SMTP呼び出しを行い、ユーザー要求ハンドラーから直接メッセージを送信することが解決策であると考えることがよくあります。

オンラインの本屋を作成し、毎日数百件の注文から始めると予想しているとします。 注文受付プロセスの一環として、ユーザーが注文を投稿するたびに確認メールを送信します。 これは最初は問題なく機能しますが、システムを拡張すると、確認メールを送信する何千ものリクエストが突然届くとどうなりますか？ SMTP接続のタイムアウトが発生するか、クォータを超過するか、ユーザーではなく電子メールを処理するようになったため、アプリケーションの応答時間が大幅に低下します。

時間またはプロセッサを消費するアクションは、HTTPリクエストをできるだけ早くリリースする間、外部プロセスによって処理される必要があります。 この場合、注文を受け取り、通知を送信する外部のメールサービスが必要です。

よくある間違いその6：帯域幅の使用を最適化しない

ほとんどの開発とテストは、ローカルネットワーク環境で行われます。 したがって、それぞれが3MB以上の5つの背景画像をダウンロードする場合、開発環境での1Gbit接続速度の問題を特定できない可能性があります。 ただし、ユーザーがスマートフォンで3G接続を介して15MBのホームページをロードし始めたら、苦情と問題のリストに備える必要があります。

帯域幅の使用を最適化すると、パフォーマンスが大幅に向上する可能性があります。この向上を実現するには、おそらく2、3のトリックが必要です。 多くの優れたWeb開発者がデフォルトで行うことは、次のようなものです。

  1. すべてのJavaScriptの縮小
  2. すべてのCSSの縮小
  3. サーバー側のHTTP圧縮
  4. 画像サイズと解像度の最適化

よくある間違いNo.7​​：さまざまな画面サイズで開発されていない

レスポンシブデザインは、過去数年間で大きなトピックになっています。 さまざまな画面解像度のスマートフォンの拡張により、オンラインコンテンツにアクセスするための多くの新しい方法がもたらされました。これには、多くのWeb開発の問題も伴います。 スマートフォンやタブレットからのウェブサイトへのアクセス数は日々増加しており、この傾向は加速しています。

シームレスなナビゲーションとWebサイトのコンテンツへのアクセスを確保するには、ユーザーがすべてのタイプのデバイスからコンテンツにアクセスできるようにする必要があります。

レスポンシブWebアプリケーションを構築するためのパターンと実践は数多くあります。 各開発プラットフォームには独自のヒントとコツがありますが、プラットフォームに依存しないフレームワークがいくつかあります。 最も人気のあるのはおそらくTwitterBootstrapです。 これは、すべての主要な開発プラットフォームで採用されているオープンソースの無料のHTML、CSS、およびJavaScriptフレームワークです。 アプリケーションを構築するときは、ブートストラップのパターンとプラクティスに従うだけで、問題なくレスポンシブWebアプリケーションを入手できます。

よくある間違いその8：クロスブラウザの非互換性

ほとんどの場合、開発プロセスは大きな時間的プレッシャーにさらされています。 すべてのアプリケーションはできるだけ早くリリースする必要があり、優れたWeb開発者でさえ、設計よりも機能を提供することに集中していることがよくあります。 ほとんどの開発者がChrome、Firefox、IEをインストールしているという事実に関係なく、彼らはこれらの90％のうちの1つだけを使用しています。 開発中に1つのブラウザーを使用するのが一般的な方法であり、アプリケーションが完成に近づくとすぐに、他のブラウザーでテストを開始します。 これは完全に合理的です。この段階で発生する問題をテストして修正する時間がたくさんあると仮定します。

ただし、アプリケーションがブラウザー間のテスト段階に達したときに大幅な時間を節約できるWeb開発のヒントがいくつかあります。

  1. 開発中にすべてのブラウザでテストする必要はありません。 それは時間がかかり、効果がありません。 ただし、ブラウザを頻繁に切り替えることができないという意味ではありません。 数日おきに別のブラウザを使用すると、少なくとも開発段階の早い段階で大きな問題を認識できます。
  2. ブラウザをサポートしないことを正当化するために統計を使用することに注意してください。 新しいソフトウェアの採用やアップグレードに時間がかかる組織はたくさんあります。 そこで働いている何千人ものユーザーはまだあなたのアプリケーションにアクセスする必要があるかもしれません、そして彼らは内部のセキュリティとビジネスポリシーのために最新の無料のブラウザをインストールすることができません。
  3. ブラウザ固有のコードは避けてください。 ほとんどの場合、クロスブラウザ互換のエレガントなソリューションがあります。

よくある間違いその9：移植性を計画していない

仮定はすべての問題の母です！ 移植性に関しては、このことわざはこれまで以上に真実です。 ハードコードされたファイルパス、データベース接続文字列、または特定のライブラリがサーバーで利用可能であるという仮定など、Web開発で問題が発生したことは何回ありますか。 実稼働環境がローカルの開発用コンピューターと一致すると仮定するのは、単に間違っています。

理想的なアプリケーションのセットアップは、メンテナンスフリーである必要があります。

  1. アプリケーションが負荷分散された複数サーバー環境でスケーリングおよび実行できることを確認してください。
  2. シンプルで明確な構成を許可します-おそらく単一の構成ファイルで。
  3. Webサーバーの構成が期待どおりでない場合の例外を処理します。

よくある間違いその10：RESTfulアンチパターン

RESTful APIは、Web開発でその役割を果たしており、今後も存続します。 ほとんどすべてのWebアプリケーションは、内部使用であろうと外部システムとの統合であろうと、ある種のRESTサービスを実装しています。 しかし、期待される慣行に準拠していない、壊れたRESTfulパターンとサービスがまだ見られます。

RESTful APIを作成するときによくある間違いの2つは、次のとおりです。

  1. 間違ったHTTP動詞を使用しています。 たとえば、データの書き込みにGETを使用します。 HTTP GETはべき等で安全になるように設計されています。つまり、同じリソースでGETを何度呼び出しても、応答は常に同じであり、アプリケーションの状態に変化はありません。

  2. 正しいHTTPステータスコードを送信していません。 この間違いの最も良い例は、応答コード200のエラーメッセージを送信することです。

     HTTP 200 OK { message:'there was an error' }

リクエストでエラーが発生していない場合にのみ、HTTP200OKを送信する必要があります。 エラーが発生した場合は、400、401、500、または発生したエラーに適したその他のステータスコードを送信する必要があります。

標準のHTTPステータスコードの詳細な概要は、ここにあります。

要約

Web開発は、Webサイト、Webサービス、または複雑なWebアプリケーションの開発を合法的に含むことができる非常に広い用語です。

このWeb開発ガイドの主なポイントは、認証と承認に常に注意し、スケーラビリティを計画し、急いで何かを想定することは絶対にしないでください。または、Web開発の問題の長いリストに対処する準備をしておく必要があります。