もちろん、主なタスクの1つは、ユーザーが私たちの魔法のクレジットプロファイルをIron Manで記入するのを支援することですが、かなり現実的なタスクがあります。
最近、3000行以上のコードでグローバル
javascript
ファイルをリファクタリングするタスクの優先度が高くなりました。 サイトのほとんどのセクションで、どのコードがまだ要求されているかを理解する必要があります。
まず、重複コードの検索を開始し、価値のあるものを見つけません。つまり、多くの興味深いものを見つけますが、探しているものではありません。機能が現在使用されているかどうかを理解することはできません。それらはサーバー上にありますが、ユーザーがセクションにアクセスできる場合、または非表示のセクションへのリンクが使用されている場合、自動的にチェックされません。 それは起こります、そして、ピーターはマイル計算機で見つけられます 、私はそれを消したくないでしょう:)
私たちが決定した2番目のポイントは、リクエストによって
common
ajax
機能からサーバーにpingを実行することでしたが、愛するユーザーもサーバーもこのようないじめに耐えることができなかったため、Yandex.Metricaに連絡しました。 サイトにはすでにカウンターがあり、各機能の特定のカウンターの統計を補充するための呼び出しを構築し、ページを読み込んだ後、このデータをサーバーに送信します。 もちろん、
ajax
を使用してページをロードした後、使用した関数を送信しますが、アクティブなセクションは多くないため、負荷の低い時間でテストを開始します。 負荷が大きい場合、
n
秒のキューが追加されます。
function setYaParam(functionName) { if (window['yaCounterXxx']) { var param = {}; param[functionName] = { n: 1 ,url: window.location.href || '' }; yaCounterXxx.params(param); } else { yaParams[functionName] = yaParams[functionName] ? yaParams[functionName] + 1 : 1; } }
Y. Metrikaの「コンテンツ」/「訪問設定」セクションでは、合計の使用頻度、統計期間の呼び出しの合計、最後の列のページあたりの平均呼び出し数でソートされた名前自体が表示されます。

1時間の作業の後、最も訪問されたページと機能の95%の使用に関する統計を収集し、追跡を削除して「Reactor and Analysis」シェルフに配置し、1か月の統計の後、残りの低需要機能を必要なサブセクションに投稿します。