WebConsultオンラインコンサルタントでの4年間の作業を通じて、私たちは多くの経験を積んでおり、最初は後でやり直さなければならない多くのことを考慮していなかったことが判明しました。最終的には、多くの時間、お金、神経がかかりました。 この記事、そしておそらく一連の記事は、開発を開始する前に考慮する必要がある側面に専念し、将来の新興企業が最初にWebアプリケーションの有能な基盤を築くようにします。 システムの作成が始まったばかりの4年前、この記事が非常に不足していたため、基本的な間違いを繰り返さないようにするのに役立つことを願っています。 これらのヒントの多くは誰かに明らかなように見えますが、開発者はしばしばそれらを逃します。そのため、簡単なことを思い出させる必要があると考えています。
1.多言語
開発するとき、私たちのプロジェクトが国際的になる日はすぐには来ないと思っていました。 目標は、最初にロシアで始まり、何が起こるかを確認することでした。プロジェクトがうまくいけば、すべてを他の言語にすばやく翻訳できます。 間違っていたため、プロジェクトテンプレートとJSコードに直接縫い付けられた膨大な量のテキストを受け取りました。一部の場所では、アプリケーション自体のロジックはローカライズに実際には貢献しませんでした。
今、私たちはすべてのテキストをjavascriptから（素晴らしいi18nextライブラリのおかげで）を含むlangファイルに転送する作業を始めましたが、最初に考えていたらもっと簡単だったでしょう。 もちろん、ローカライズのためにすべての新しい機能とインターフェイスをすぐに準備します。
2.タイムゾーン
わが国には9つのタイムゾーンしかないことを忘れないでください。そのため、ユーザーがタイムゾーンを選択し、サイト上のすべての日付、統計サンプルなどにすぐに適用できるようにすることをお勧めします。 その後、リメイクするのは難しいでしょう。
3.スケーラビリティについて考える
スタートアップが成功した場合、遅かれ早かれ、1台のサーバーで十分な電力が得られなくなることがあります。 原則として、HTTPサーバーの負荷分散に問題はありません。分散サーバーを配置し、トラフィックを複数の同一のHTTPサーバーに転送します。 データベースのスケーリングの状況はさらに興味深いものです。 もちろん、レプリケーションもありますが、実践で示されているように、c MySQLの場合は非常に信頼できません。 プロジェクトの論理的に独立した部分を別のデータベースサーバーに転送すること（シャーディング）をお勧めしますが、アプリケーション自体を開発する前にこれを検討することをお勧めします。 たとえば、特に重いモジュールを別のデータベースサーバーに移動して、メインのサーバーをロードできます。 最初にすべてを1つのサーバーで実行したい場合でも、そのような必要が生じたときにいくつかのモジュールを別のサーバーに簡単に転送できる可能性を考慮してください。
4.すべてをAPIに出力する
将来、アプリケーションがパブリックAPIを意味する場合は、すぐに考えてください。 理論的にサードパーティの開発者が利用できるはずのモジュールで作業するときは、すぐにそれを操作するためのAPIメソッドを作成します。 アプリケーションの適切なアーキテクチャを使用すると、非常に簡単に実行できますが、後で実行するのははるかに困難です。 最初は考えていなかったからといって、まだ本格的なAPIはありません-現在、この状況を修正するために取り組んでいます。
5.雪崩クエリ-Redis
オンラインコンサルタントのボタンは数千のサイトに配置されており、ボタンの表示回数は1日あたり数千万です。 ボタンを表示するたびにデータベースへのクエリが生成され、訪問者の遷移が保存されます。これは、会話中にコンサルタントがサイト上のクライアントのフルパスを確認できるようにするために必要です。 最初、このデータはMySQLに書き込まれましたが、最終的には完全に間違っていることが判明しました。 まず、データベース負荷の主な原因でした。 第二に、mysqlはテーブルを変更するためのこのようなクレイジーな同時リクエストに非常に否定的に反応し、時には短期間のデータベースロックさえ発生しました-クエリが蓄積し、アプリケーション全体がひどく遅くなり始めました。 第三に、制限の制定後にこのデータを消去するプロセスは、かなりのリソースを消費しました。 MySQLの設定で多くの実験を行い、ほとんど達成しませんでした。 代替を検索するプロセスで、 Redisに切り替えることが決定されました。Redisは、「キー」：「値」形式でデータをメモリに書き込み、読み取り/書き込みの高速化とブロッキングリクエストの欠如を提供し、存続時間を設定することでデータをクリアできます。 このモデルは私たちにぴったりでした。
移行がスムーズだったとは言えません。Redisの設定を深く掘り下げ、一連のスクリプトを書き直し、いくつかのダウンタイムを乗り越えなければなりませんでしたが、それでもデータベースの負荷をほぼ半分に減らすことができました。 繰り返しますが、これについて前もって考えていたなら、もっと簡単だったでしょう。 したがって、このような「なだれ」リクエストを計画している場合は、すぐにそれらをRedisに転送することをお勧めします。いつか、これに感謝します。
Redisに加えて、他の同様の製品がありますが、残念ながら、それらとは連携しませんでした。
6.最小限のユーザーインタラクションとテクニカルサポート
サポートの参加なしに、ユーザーが自分でできない操作の数を減らします。 このような操作の例としては、別の関税への切り替え、契約の締結、請求書の発行、書類の閉鎖などがあります。 理想的には、それら。 サポートは、ユーザーが既に利用可能な操作を支援するものであり、これらの操作をユーザーに提供するものではありません。 サポートスタッフをオフロードすることで、小規模なスタッフで対応し、費用を節約できます。
7.プロジェクトファイルの混乱を避ける
当初、プロジェクトのファイル構造についてよく考えていなかったことを非常に残念に思います。そのため、システムファイルに混乱が生じました。基本的な怠becauseのためにどこか、すべてを考慮していないために。 私たちはゆっくりと物事を整理していますが、これは簡単なことではありません。 当然、これはシステムに影響を与えませんが、開発プロセスに干渉します。 そして一般的に、すべてのファイルが適切な場所にあるとき、それは審美的な喜びを引き起こします。 ライブラリを配置する場所、静的ファイルの配置を整理する方法、プロジェクトファイルを配布する原則について考えてください。
8. JavaScriptテンプレートエンジンを使用する
ほとんどの開発者は知りませんが、javascriptではテンプレートを使用することもできます。これにより、jsコードがよりきれいになるだけでなく、HTMLコードの操作が大幅に簡素化されます。 これらの目的のために、多くの製品があります： Handlebars 、 Swig 、 EJS 、 undercore.js 。 RIA （Rich Internet Application）の開発を計画している場合は、JSアプリケーションの優れたフレームワークであるBackbone.JSにも精通することをお勧めします。
9.最大クリーンジャンクデータ
プロジェクトは原則に従って実行する必要があります。データが古くなったり、保存期間が終了した場合は、削除する必要があります。 テーブル内のデータが多いほど、負荷が大きくなり、システムが遅くなります。 開発時に、不要なデータを削除するcronスクリプトを作成します-これは、データベース内のレコードだけでなく、ユーザーファイルにも適用されます。 たとえば、よくある間違いは、ファイルを含むレコードをデータベースから削除することですが、ファイル自体はリポジトリに残ります。
これには、データベースからメインレコードが削除されたが、他のテーブルのそれに関連するレコードが削除されない場合も含まれます。したがって、データの整合性が侵害されます。 MySQLでは、トリガーと外部キーをこの目的に使用できます。
10.統一された設計-すべて
デザインがどこでも同じであることを確認してください。同じ一般的なスタイルと、形状、芽、スクロールバー、テーブルなどの個々の要素のスタイルを同じにしてください。 設計時には、一種の標準を作成し、それから逸脱しないでください。 第一に、レイアウトが大幅に容易になり、第二に、すべてが統一されているとユーザーにとってより便利になります。 第三に、小さなものであっても、どこにでも一般的なスタイルが保持されている場合、それはただ美しいです。
11.スタイルにはLESSを使用します。
LESSは、通常のCSSを動的なCSSに変換し、ネストされたルール、変数、および関数を使用できるようにするシンプルなツールです。 CSSコードがより視覚的になり、開発プロセスが大幅に簡素化されます。 出力では、特別なlesscユーティリティを使用して、lessコードをコンパイルし、通常のcssファイルを取得します。 彼らがかつてLESSなしで行っていた方法を想像することはできません-必ず試してください。
12.論理的な価格設定
固定料金を使用している場合でも、クライアントが必要に応じて個別にコストを計算する必要がある場合があります。 非常に頻繁にいくつかの表示価格が呼ばれ、その起源は明確ではありません。 最初は、ユーザーが必要な機能のみを入力できるようにすることで罪を犯しました。 したがって、このような関税の費用はおおよそ計算され、クライアントごとに異なりました。 これにより社内で多くの混乱が生じ、すべての価格を論理的に計算することにしました。 個々の関税の柔軟性を低くする必要がありました：今では人々は個々の機能ではなく機能のセットを選択できます-しかし、このようにして混乱を取り除き、価格は顧客と従業員の両方にとって100％透明で理解可能になりました。
13.統計の収集方法をすぐに考えます
アプリケーションにデータの統計情報が必要な場合は、事前にどのようにデータを収集するかを考えることを強くお勧めします。 確かに、統計に関しては、データベースからデータを取得するだけでなく、迅速に実行することも重要です。 サンプリングの便宜上、キーを追加するか、計算されたデータをすぐにどこかで収集する必要がある場合があります。
14.他の顧客に役立つ機能のみを変更します。
標準的な状況：クライアントがやって来て、原則としてあなたの製品に満足しているが、彼は何かを「少しうまくやる」必要がある-さもなければ彼は拒否するだろう。 特に最初は、クライアントの懇願に屈服し、彼のための機会をすべて終える誘惑は非常に大きい。 しかし、急がないでください。 まず、考えてみてください。この機会は他の顧客にとって有益でしょうか？ これが特定のクライアントにのみ焦点を絞って必要なものである場合は、このビジネスをドロップすることをお勧めします。 それ以外の場合は、個々の改善を絶えず作成しているので、出口はほとんどありません。コードは汚れてしまい、新しい機能を開発するときには、小さな個々の改善の多くとの互換性を確認する必要があります。 これは、顧客の声に耳を傾ける必要がないという意味ではありません。大多数の希望に頼り、個々のアイデアに注意することをお勧めします。
15.開発に参加する人について考える
コードを書くときの簡単なルール-常に自問してください：新しい開発者はこれを理解できますか？ 論理的かつ美しくすべてを行い、コメントを軽視しないでください。 多くの場合、プロジェクトは単独で書き始め、それについて考えません。 ただし、最終的に大規模なプロジェクトに依存する場合、新しいプログラマーがチームを補充し、コードを掘り下げなければならない日が必ず来るでしょう。