私はかなり長い間、Webアプリケーションの開発に携わってきました。 これらは、高負荷のアプリケーション（FacebookやGmailなど）ではありません-もちろん、独自の仕様です。 私のアプリケーションは小さいものでした（1台の物理サーバーに収まる可能性がありました）が、機能的には豊富で、金融、電子商取引です。 私は大規模なチームで働いていませんでしたが、ラック内の機器の組み立てからCSSの編集まで、さまざまなテクノロジーを感じました。

ある時点で、Webアプリケーション開発の分野での私の活動が、マンモスの遠い先祖の狩りを思い出し始めたと思うようになりました（マンモスの場合、解決する必要があるタスクを意味します）。 祖先だけが体力に依存しており、代わりに知性の力を使用しています。 しかし、以前のように、単独で大きな獲物を埋めることは不可能です-すべてのハンターの共同の努力が必要です。

カットの下で、Webアプリケーションの開発における私の観点から最も重要な側面に関するビジョンを収集しようとしました。

適応性

最も重要な側面、私見。 最新のWebアプリケーションは、常に変化し続ける環境に常に適応し、生涯を通じて進化しなければなりません。 また、Webアプリケーションの外部の世界が常に変化するだけでなく、Webアプリケーション自体が外観によって周囲の世界を変えることもあります。 Web開発では、ウォーターフォールモデルはスパイラルモデルに取って代わりました。ウォーターフォールモデルが悪いからではなく、単に変更に追いついていないからです。 「ウォーターフォール」は、それほど動的ではない他のいくつかのアプリケーション（たとえば、 火星探査機用のソフトウェア）でアプリケーションを開発するのに依然として適しています。 Web開発では、顧客の要件に応じて機能するアプリケーションよりも、簡単に変更できるアプリケーションを作成することが非常に重要です。 なぜそう

不確実性

これが前の質問に対する答えです。 顧客自身がアプリケーションの要件を正しく策定できないことがよくあります。 最終結果がどうあるべきかを明確に理解していない状態で開発が行われることがあります。動きの方向についての一般的なビジョンがあり、時には「以前の経験に基づいて」ではなく、それを生み出す決定が行われます。 その後、顧客の美しさに関するアイデアは劇的に変わる可能性があり、あなたのベストプラクティスは劇的に関連性を失います。

練習が完璧になります

アプリケーションの要件の正確性は、アプリケーションの次のバージョンでこれらの要件の実装を実行した後にのみ確認できます。 要件の定式化からその実装の使用までの時間が短いほど、決定の成功をより早く評価できます。

言い換えると、「 生産中のタイピング」戦略は、その使用の結果、特定の有用な機能のセットが成長し、逆に役に立たない、または率直に言って有害な機能のセットが消えた場合に正当化することができます。 もちろん、「タイプミス戦略」は、スパイラル開発モデルと高度に適応性のあるアプリケーションでのみ機能します。 したがって、Webアプリケーションはできるだけ早くalpha-beta-gamma ...操作に移行する必要があり、変更のサイクルはできるだけ短くする必要があります。

未知のパスに...

なぜ人気製品が良いのですか？ 少なくともそれらの主な機能にはエラーが含まれていないという事実によって、そして突然の回帰のすべてが出てきた場合、これはすぐに判明し、すぐに修正されます。 これは、基本的な機能と一般的な製品にのみ適用されます。 何百万人ものユーザーが同じ「機能的な道」を歩き、アスファルトの状態に踏み込んでいます。 しかし、そのような道から少し離れる価値があり、最も人気のある製品であっても泥沼に行き詰まる可能性があります。

何百万人のユーザーがいない製品でトラックを踏みつける方法は？ そのようなユーザーになりましょう。 これは良いディーラーです。ディーラーは自分で売ったものを使うべきではありません。 優れた開発者は、製品を使用するために単に「 必要 」です。 開発者自身だけでなく、家族、友人、知人、友人の知人、知人の友人も同様です。 一般的に、インターネットにアクセスできる人は誰でも、作成されたWebアプリケーションをできるだけ早い段階から使用する必要があります。

開発者が広範なソーシャルコネクションを持っていない場合、開発者はSeleniumおよび同様の製品に依存する必要があります 。 自動テストシナリオは、少数のユーザーに取って代わることができますが、同時にアプリケーション自体の適応性を大幅に低下させます-アプリケーションの機能だけでなく、この機能をチェックするためのスクリプトも変更する必要があります。

エラー処理

むかしむかし、優れたソフトウェアの兆候の1つは、「 愚か者からの保護 」の存在でした。 キーボードのキーストロークのシーケンスまたはそれらの組み合わせの同時押しは、プログラムの異常終了につながるべきではないと考えられていました。 そのため、開発者は予想されるデータの処理方法だけでなく、予期しないデータの処理が何につながるかについても考えなければなりませんでした。

現在、Webアプリケーションは非常にマルチレベルになっているため、この側面についてはあまり気にすることができません。 SQLインジェクションやCSRF攻撃で得点できるわけではありません。何らかの理由でユーザーがデータベースに保存されたときに、クライアントの必須メールに関する情報が受信されなかった場合、ユーザーフレンドリなエラーメッセージを生成する必要はありません-ランタイムがスローする例外（「 整合性制約違反 」など）だけです。

アプリケーションが予想されるデータで予想される環境で動作する場合、そのようなエラーはありません。 予期しないデータが使用されるか、予期しない環境が発生すると、エラーが発生します。 このような状況では、予期しないデータまたは予期しない環境にできるだけ早く対応し、入力データの検証を追加する（検証はエラー処理ではなくビジネスロジックである）か、予期しない状態の処理を入力して、予想されるデータのカテゴリに変換することがはるかに重要です。

エラーメッセージでプログラムから人に送信される情報は、人間のユーザーではなく、主に人間の開発者を対象とする必要があります。

人間のユーザーの最大のタスクは、スクリーンショットとエラーメッセージを添付して「 データの保存中に発生した何らかのゴミ 」に関する問題を作成することです。 そして、彼を信頼することさえしない方がいいでしょう。Webアプリケーション自体が予期しない状況を報告し、人間の開発者に問題を引き起こす可能性があります。 人間のユーザーは、「 何らかのゴミが発生した、開発者に既に作業していること、どのように修正するかを通知された-電子メールで私たちに連絡する、ご不便をおかけして申し訳ありません 」などのメッセージを見ると感謝します 。

彼は、アプリケーションで正確に何が起こったのかを詳細に説明するよりも、妥当な時間（分、時間、日）後に彼を防ぐエラーの修正についてのメッセージを受け取ること、および要求が現時点で処理できない理由をわかりやすく説明することをはるかに重要です。 もちろん、問題は数週間または数か月間キューに入れられるべきではありません-何らかの理由で開発者が6か月以内に問題にアプローチできなかった場合、そのような問題を安全に捨てることができます-それはもはや関係がないか、後で繰り返されます（すでに繰り返されています）同じトピック（1つではなく）に新しい問題を作成します。

開発者向け

既に述べたように、Webアプリケーションは応答性がなければなりません。 誰も変更する時間がありませんでした-ケージから飛び出しました。 したがって、Webアプリケーションはビジネスオーナーではなくエンドユーザーに焦点を合わせるべきではありません。Webアプリケーションは主に開発者に焦点を当てるべきです（開発者はこれについては不明です-Ctrl + Shift + Iを押してください）。

アプリケーションは、ビジネスオーナーの要求ではなく、開発者が変更したため、エンドユーザーに合わせて調整されます。 開発者がどこで何を変更する必要があるかを早く理解すればするほど、エンドユーザーはビジネスオーナーが望むものをより早く受け取ることができます。 したがって、Web開発の優先事項は、縮小されたコード、美しいコード、または高速なコードではなく、明確なコードである必要があります。

コードは、書き込み中、読み取り中だけでなく、デバッグ中およびテスト中もクリアする必要があります。 これは、縮小/難読化/トランスピレーションだけでなく、メソッドの多くのリターンポイント 、 流体インターフェース 、および重要なDOM要素のIDの欠如についても話します。 これらのささいなことはすべて、コードをデバッグおよびテストするというすでに楽しいプロセスを非常に活気づけます。

私は「プログラマー」と「開発者」の概念を分けています。優れたプログラマーはアプリケーションの環境設定に関与すべきではありません。優れたプログラマーはアプリケーションのログを読んで「 それはどこから来たものでもないはずです 。そして、優秀なプログラマーは、彼のために書いたコードの荒野を掘り下げる必要はありません。 これは開発者のすべての作業です。 これが、Webアプリケーションの方向性です。 さらに、それはに向けられるべきです

平凡な開発者

このコードは、原則として、天才-解決される問題の規模を完全に認識し、X線ビジョンを使用して問題の最小のニュアンスを把握する創造的な人によって作成されます。 そして、それは変化します-ニュアンスをつかまないだけでなく、このコードが最初に書かれた理由を常に理解していない人によってさえ。 そして、結局のところ、多くの場合、それは同一人物です。 6か月以上触れていないプロジェクトでコードを変更しようとした人は誰でも、私が言っていることを理解しています。

Webアプリケーションは、コンテキストから外れた開発者だけでなく、タスクの一般的なコンテキストをまったく認識していない開発者によっても変更できるようにする必要があります。 したがって、すべてが平凡な開発者に役立つはずです-コードのコメントでのビジネス関数の説明、変数/関数/クラスの名前の「話す」、IDEファイルを使用したプロジェクトファイルの構造化とコードの構造化（インラインドキュメント、オートコンプリート、階層参照） 、コンテキストに関連するファイルへの相互参照（@deprecatedアノテーションを含む）。

コードが作成されたコンテキストをすばやく復元し、それを新しいコンテキストと比較し、変更されたコードが動作を開始するために必要な変更を理解する必要がある場合、変更されたコードで「dれている」開発者がつかむような小さな「ストロー」のためです新しいコンテキストであり、新しいコンテキストと重複しない古いコンテキストの領域を破壊しませんでした。

そしてもちろん、テスト-天才が自分の機能を検証するためにテストを書くのを面倒なら、最も平凡な開発者でさえそれらを実行し、彼の変更が天才の仕事に影響を与えないことを確認できるでしょう。

モジュール性

アプリケーションをモジュールに分割することは、古くからの原則です。 分解により、単一モジュール（モジュールのグループ）のアプリケーションのコンテキストを制限し、平凡な開発者の生活を楽にし、天才がより複雑なソフトウェアシステムを構築できるようにします。 何らかの方法で複雑なアプリケーションであると主張する各Webアプリケーションは、モジュールで構成されます。 モジュールは、個別の関数またはクロージャー（JSスコープ）、個別のクラス、個別のファイル、特定の構造を持つファイルのグループ、アーカイブにロールインされる同じファイルのグループ、およびアーカイブのグループです。

最新のアプリケーション（Webだけでなく）は、多くのツールが発明されたさまざまな外部依存関係に依存しています-rpm 、 dpkg 、 ant 、 maven 、 PEAR 、 composer 、 npm 、 requirejs 、 browserify 。 おそらくいつかリポジトリがWebモジュールにも表示されます-Webアプリケーションを構築するためのコンポーネント（ プラグイン / 拡張機能であり、 javaやrequirejsの意味ではありません）。 それまでの間、次のWebアプリケーションの作成は、多くの場合、ユーザー認証用の独自のデータ構造の設計から始まります。

ただし、Webアプリケーションでサードパーティのモジュールを使用するか、独自のモジュールを作成するかは異なりますが、アプリケーションは完全にモジュールで構成されます。 そして、モジュールの構造をよりよく考えれば、より複雑なアプリケーションをそれらに基づいて構築できます。 多くの場合、非常に複雑なコンポジションを作成するには、非常にシンプルで原始的なルールが必要です。平凡な開発者だけでなく、このコンポジションの作成に何らかの形で参加できるすべての人が理解できます。 たとえば、バイナリシステム。

蟻塚

アリが単一のコミュニティとして共存し、成長を数百、数千回超える構造を構築できるようにするルールです。 人々が1人で構築できるものよりも数千倍複雑なソフトウェアシステムを作成できるようにするルールです。

標準（ ISO 、 RFC ）の形でこれらの規則を発行するか、より正式でないか、または完全に非公式に発行することができます。 それでも、開発者が相互にやり取りし、他のプロジェクト（ ライブラリ 、 フレームワーク ）に基づいてプロジェクトを構築し、あるプロジェクトを別のプロジェクトにリンクできるようにするのは、これらのルールです。 ルールの一般的な理解により、一部（管理者）が他（開発者）によって作成されたアプリケーションをサポートできるようになります。 アプリケーションを使用する場合でも、基本的なルール（だれがIBM Visual AgeでCtrl + Oでファイルを開こうとしたか）の一般的な理解が必要です。

最新のWebアプリケーションは、多くの「アリ」の努力の組み合わせであり、そのほとんどは目立たない（バイナリシステムからブラウザまで）。 私たちユーザーは、特定の開発者、私たちの欲望の実装者の最終的な努力にのみ気付きます。 私たちユーザーは、多くの場合、「そのようなもの」を望み、アプリケーションの基になっているテクノロジースタック全体、2回のクリックで何ができるのか、データ構造が揺らぐことについてはまったく考えません。 私たちは、たとえ今ではなくても、できるだけ早く他の人がしていないことを望んでいます。

そして、ユーザーとして、私たちは実装の詳細に飛び込むことを絶対に嫌がりますが、開発者として、使用されているテクノロジーのスタック全体を理解するだけでなく、エンドユーザーの欲求（またはそのような欲求に関するWebアプリケーションの顧客のプレゼンテーション）への適応を確実にする必要があります。 つまり、「anthill」階層の最上位（エンドユーザーの近く）にいる開発者は、同僚の作業の成果を下位レベルで使用するだけでなく、ユーザーのニーズを伝え（フィードバック）、下位レベルに修正できる必要があります。

専門化、統一、社会化-これらはいつかnix OSのgrepユーティリティに似たWebアプリケーションの認証モジュールを作成できるようになり、Webアプリケーションの作成はLinuxディストリビューションの構築に似てくると期待しています。

下位互換性

そして、この章は、将来登場するMagento 3開発者向けに特別に追加されました。 多くの場合、下位互換性の要件は、プロジェクトに関するすべての決定によって満たされる必要があります。 これは、もし聖杯ではないにしても、かなり「ロイヤル」な要求です。 しかし...後方互換性は適応性の敵です。 したがって、 簡単に 。

まとめ

最新のWebアプリケーション：

• 存在する限り変化します。
• 最終的な開発者が一人であっても、それは多くの人々の努力の組み合わせです。
• さまざまなモジュールから組み立てられ、かなりの量が他のWebアプリケーションで使用されています。
• 特定のルールに従って他のWebアプリケーションと対話します。
• エンドユーザーだけでなく、開発者にとっても非常に友好的である必要があります。
• 以前のバージョンと互換性がある必要はありません（彼らが言うように、依存マネージャが支援します）。

それを読んだ人に感謝します。 著者の現在の意見は、上記と一致しない場合があります。

PSなぜ「象の上の虫眼鏡で」？ コードの荒野に飛び込むと、次の「象」の奇妙な曲がりくねった「奇妙なガラス」を見ます。あなたは自分がどこにいるのか、トランクの付け根や尻尾の付け根にあるのかわかりません。